ניתוח ועיצוב מערכות תוכנה אביב 2012 נסיבות שימוש (Use Case Modeling)

Overview A use case captures the intended functionality of the system (or subsystem, class, or interface) you are developing, without having to specify how that functionality is implemented. “A use case is a narrative document that describes the sequence of events of an actor (an external agent) using a system to complete a process.” [Jacobson] “They are stories or cases of using a system. Use case are not exactly requirements or functional specifications, but they illustrate and imply requirements in the stories they tell.” [Larman] “A description of set of sequence of actions, including variants, that a system performs that yield an observable result of value to an actor.” [Booch]

Use Case Description Template Section Purpose Name The name of the use case. Short descriptive phrase Description Several sentences summarizing the use case. Actors The participating actors. Precondition Requirements on the state of the system prior to this use being valid. Postconditions This describes the state of the system following the successful completion of this use. Basic course of action The main path of logic an actor follows through a use case. The path describes how the use case works when everything works as it normally should Alternate courses The path that are the result of an alternate way to work, an exception, or an error condition 3

Finding Actors External objects that produce/consume data: Must serve as sources and destinations for data Must be external to the system Humans Machines External systems Sensors Database Organizational Units Printer

Use Case Diagram Actor: Use Case: Subject Boundary: An actor is a person, organization, or external system that plays a role in one or more interactions with your system. You can use inheritance on actors. Notice the association. Use Case: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. Subject Boundary: Indicates the scope of your subject.  Anything within the box represents functionality that is in scope and anything outside the box is not . Actor Use case subject boundary Online Shopping

Organizing Use Case - Include An include relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base. When to use it? Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition. Another motivation is simply to decompose an overwhelmingly long use case into subunits to improve comprehension. <<Include>> is discussed in [Larman], p. 494 (Section 30.1) <<Extend>> is discussed in [Larman], p. 497 (Section 30.3)

Organizing Use Case - Extend An extend indicate that one use case (extension) extends the behavior of another use case (base). The extend relationship specifies that the incorporation of the extension use case is (optional) dependent on what happens when the base use case executes. Useful when, for some reason, we would not like to change a certain Use Case we need to extend. There can be many extending use cases and many extension points. Larman p.498: Some Use-Case guidelines recommend using Extending Use-Cases and the <<extend>> relationship to model conditional or optional behaviour inserted into the Base Use-Case. This is not inaccurate, but it misses the point that optional and conditional behaviour can simply be recorded as text in the Extensions section of the Base Use-Case.

Include vs. Extend - Comparison Arrow to Base from Extension  Execution is Optional Allows appending to the use case without changing it’s original text. Arrow: from Base to Included  Execution is Mandatory Avoid repetition

דוגמא 1 (מועד ב, סמסטר א, 2008) מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה של נכסי נדל"ן. המשחק מבוצע תוך כדי סימולציה של מהלכים עסקיים אמיתיים, כשהשחקנים קונים ומוכרים נכסים, בונים בתים ומלונות. המנצח במשחק הוא זה שצובר את הרכוש הרב ביותר (סכום ערך הנדל"ן והמזומנים שיש ברשותו). חוקים: הלוח מורכב ממשבצות שמקיפות אותו (לפחות 40 משבצות- תלוי קונפיגורציה). כל שחקן בתורו מטיל קובייה ומתקדם לפי תוצאת הקובייה לכיוון קבוע. אם שחקן נוחת על משבצת שמייצגת שטח (רחוב בעיר מסוימת) שלא שייך לאף שחקן אחר הוא יכול לקנות אותו. אם הוא נוחת על שטח שכבר שייך לשחקן אחר עליו לשלם לו דמי שכירות, בהיקף אשר נקבע ע"י הטלת קובייה. על ידי קניית בתים בתוך השטחים ניתן להעלות את גובה דמי השכירות בשטח בו נמצא הבית. חובה לקנות את כל העיר (כל הרחובות בעיר) לפני קנית בית. לאחר קניית 4 בתים ניתן לבנות מלון המגדיל את סכום השכירות עוד יותר. בכל פעם שחולפים על פני משבצת הפתיחה או נוחתים עליה, זוכים בסכום מסוים של כסף (תלוי קונפיגורציה). אם שחקן נוחת על משבצות "ההפתעה" עליו לקחת קלף הפתעה ולבצע את ההוראות שבו (לזכות או לשלם סכום כסף מסוים לקופת המשחק). ישנה משבצת כלא שתנאי הכניסה והשחרור ממנה מוגדרים בקונפיגורציה של המשחק. במשחק משחקים 2 עד 4 שחקנים אנושיים. במידה וחסרים שחקנים אנושיים, ניתן להגדיר שחקני מחשב. שחקן המחשב יכול לשחק באסטרטגיה חמדנית (בכל הזדמנות שיש לו לקנות נכס כלשהוא, הוא יקנה אותו, אלא אם אין לו כסף) או רנדומאלית (מחליט באופן אקראי אם לקנות נכס נתון). המשחק נגמר כאשר אחד השחקנים מחליט לעצור אותו.

פתרון דוגמא 1 – תרשים UC Who is Gail?

דוגמא 1 (מועד א, סמסטר א, 2008) מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה של נכסי נדל"ן. המשחק מבוצע תוך כדי סימולציה של מהלכים עסקיים אמיתיים, כשהשחקנים קונים ומוכרים נכסים, בונים בתים ומלונות. המנצח במשחק הוא זה שצובר את הרכוש הרב ביותר (סכום ערך הנדל"ן והמזומנים שיש ברשותו). חוקים: הלוח מורכב ממשבצות שמקיפות אותו (לפחות 40 משבצות- תלוי קונפיגורציה). כל שחקן בתורו מטיל קובייה ומתקדם לפי תוצאת הקובייה לכיוון קבוע. אם שחקן נוחת על משבצת שמייצגת שטח (רחוב בעיר מסוימת) שלא שייך לאף שחקן אחר הוא יכול לקנות אותו. אם הוא נוחת על שטח שכבר שייך לשחקן אחר עליו לשלם לו דמי שכירות. על ידי קניית בתים בתוך השטחים ניתן להעלות את גובה דמי השכירות בשטח בו נמצא הבית. חובה לקנות את כל העיר (כל הרחובות בעיר) לפני קנית בית. לאחר קניית 4 בתים ניתן לבנות מלון המגדיל את סכום השכירות עוד יותר. בכל פעם שחולפים על פני משבצת הפתיחה או נוחתים עליה, זוכים בסכום מסוים של כסף (תלוי קונפיגורציה). ביישום זה יש משתמש אחד, תצפיתן, אשר מגדיר את כמות השחקנים שישתתפו במשחק, ועוקב אחרי מהלכי המשחק. המשחק נגמר כאשר אחד השחקנים הווירטואליים או התצפיתן מחליטים לעצור אותו או כאשר מוכרז מנצח.

פתרון דוגמא 2 – תרשים UC Note that Marking an Extension Points region is optional. VP, in it’s current version (we use 8.0), adds it automatically. We leave it up to you to add it or not. If you do choose to add such a region, notice that the extension point does not have to be named after the extension. If readability would benefit from naming it differently – don’t hesitate to do so!

פתרון דוגמא 2 – תיאור UC Use Case UC1: Play Monopoly Game Actor: Observer Pre Condition: Use-case “Set Game Settings” was performed. Post Condition: A winner has been declared or Observer cancels. Main Success Scenario: System displays game trace for next player move. Repeat step 1 until a winner is declared or Observer cancels. Extensions: *a. At any time, System fails: (To support recovery, System logs after each completed move) Observer restarts System. System detects prior failure, reconstructs state, and prompts to continue. Observer chooses to continue (from last completed player turn). Player wishes to start use-case “End Game” Notice how only Extension #4 really receives an Extended Use-Case “End Game”.

דוגמא 3 (בוחן 2010) יש לטפל בקליטת/רישום מאמרים מוגשים מעת לעת לכנס ע"י מחבר/מחברים. (הנח שמאמרים נשלחים בדוא"ל לכתובת של ועדת התכנית ואחד מחבריה מטפל ברישומם במערכת.) עבור כל מאמר שמוגש רושמים את הפרטים הבאים: מספר מזהה ייחודי, שם המאמר, רשימת מילות מפתח ופרטי המחברים; אם יש יותר ממחבר אחד רושמים מי מהם איש הקשר (הדבר רשום בפרטי ההגשה), והמאמר מקבל סטאטוס "הוגש". הטיפול במאמרים שהוגשו לכנס הוא כלהלן: אחד או יותר מחברי ועדת התכנית עובר על מספר מאמרים בסטאטוס "הוגש", לפי בחירתו. עבור כל מאמר כזה ועל סמך מילות המפתח שמתארות אותו, הוא בוחר מספר שופטים מתאימים (ע"פ מילות המפתח שלהם), ובלבד שאף שופט לא קיבל בשלב זה יותר ממכסת המאמרים לשיפוט (נניח שישה). בעקבות בחירת שופט למאמר, המערכת שולחת לו בדוא"ל את פרטי המאמר וכתובת האתר שבו הוא יכול לקרוא את המאמר ולהוריד טופס/דוח שיפוט; כן נאמר לשופט מהו המועד האחרון להגשת דוח השיפוט. עם תום הקצאת המאמר למספר שופטים (שמספרם נתון לשיקול דעת ועדת התכנית) משתנה סטאטוס המאמר ל"נשלח לשיפוט". (אינך נדרש לטפל בבעיות אפשריות של מחסור בשופטים וכדומה.) ניתן להניח ששופט שקיבל מאמר/ים לשיפוט קורא מעת לעת המאמר מבין המאמרים שנשלחו אליו וממלא דוח שיפוט. (אינך נדרש לטפל בתהליך ההתחברות של שופט למערכת שבה מצויים המאמרים ואופן מילוי הטופס/הדוח.) השופט שולח את דוח שיפוט המאמר בדוא"ל לכתובת מתאימה של ועדת התכנית. הנח שחבר ועדת התכנית עובר מעת לעת על הודעות הדוא"ל שהתקבלו ומעביר/מעתיק את דוחות השיפוט למערכת. במערכת נרשם סטאטוס "הוגש דוח" של שופט למאמר. (אינך מתבקש לטפל בנושא זה של הגשת דוח השיפוט למאמר ע"י השופט).

דוגמא 3 (בוחן 2010) (המשך) בכל יום א' בבוקר המערכת עוברת על המאמרים שבסטאטוס "נשלח לשיפוט" ובודקת את מצב השיפוט: אם עדיין יש שופט/שופטים שטרם הגישו דוח והמועד האחרון להגשת הדוח הוא פחות מ-7 ימים מהמועד האחרון שנדרש להגשת הדוח - נשלחת לאותו שופט/שופטים תזכורת מתאימה. אם בעת הבדיקה מתברר שכל השופטים של מאמר כבר שלחו את דוחות השיפוט משתנה סטאטוס המאמר ל"התקבלו כל הדוחות". מעת לעת עוברים חברי ועדת התכנית על מאמרים במערכת בסטאטוס "התקבלו כל הדוחות" (חלקם או כולם), קוראים את דוחות השיפוט ומחליטים אם לקבל או לדחות את המאמרים; לאור החלטתה משתנה סטאטוס המאמר ל"התקבל" או "נדחה" ונשלחת הודעה מתאימה הן למחבר המאמר (באמצעות איש הקשר) והן לשופטי המאמר – בצירוף דוחות השיפוט. (בדרישות של מערכת זו לא נכלל טיפול בתהליך אפשרי של הגשת תיקונים, בבעיות של אי הגשת דוחות שיפוט ועוד דברים שלא תוארו כאן.) לאחר תום תקופת השיפוט, מתכנסים חברי ועדת התכנית ועוברים על כל המאמרים שהתקבלו לכנס. על פי שמות המאמרים, התקצירים ומילות המפתח שלהם הם מחליטים ורושמים אילו מושבים יהיו בכנס ומועדיהם, ואילו מאמרים ייכללו בכל מושב, כולל סדר ההצגה. תהליך זה יכול להתבצע בבת אחת עבור כל המאמרים או במספר סבבים, כאשר בכל פעם יש לאפשר לבצע שינויים בתכנית שיבוץ המושבים והמאמרים. בתום כל התהליך יציינו חברי הועדה במערכת שהתכנית "נסגרה" והמערכת לא תאפשר לבצע עוד שינויים של מושבים ושיבוצי מאמרים.

פתרון דוגמא 3 – תרשים UC

פתרון דוגמא 3 – תיאור UC1 UC1: הגש מאמר לכנס תיאור: מחבר המאמר מגיש מאמר לכנס. שחקנים: ועדת התוכנית. תנאי קדם: אין. תנאי סיום: פרטי המאמר נשמרו במערכת בסטאטוס = "הוגש", פרטי המחברים נשמרו במערכת. תסריט הצלחה עיקרי: מחבר מאמר מבקש להגיש מאמר לכנס. חבר ועדת התוכנית מזין את הפרטים הבאים למערכת: מספר מזהה, שם המאמר, מילות מפתח, תקציר מאמר, פרטי איש קשר. חבר ועדת התוכנית מזין את פרטי המחברים של מאמר למערכת. המערכת שומרת את פרטי המחברים במערכת . המערכת קובעת למאמר סטאטוס "הוגש", ושומרת את פרטיו. הרחבות: 4א. מחבר מאמר קיים כבר במערכת, המערכת לא שומרת את פרטיו שוב. 5א. המאמר כבר הוגש למערכת, המערכת מציגה הודעת שגיאה והמאמר לא נשמר.

פתרון דוגמא 3 – תיאור UC2 UC2: שבץ שופטים למאמר תיאור: חברי ועדת התוכנית בוחרים שופטים לשיפוט מאמרים שהוגשו לכנס. שחקנים: ועדת התוכנית, מערכת דואר אלקטרוני. תנאי קדם: הוגש לפחות מאמר אחד לכנס אשר טרם שובצו לו שופטים. תנאי סיום: שובצו שופטים למאמר, המאמר נשלח לשופטים ונקבע לו סטאטוס "נשלח לשיפוט". תסריט הצלחה עיקרי: חבר ועדת התוכנית מבקש לשבץ שופטים למאמר. המערכת מציגה את רשימת המאמרים שהוגשו ולא שובצו (בסטאטוס "הוגש") לחבר ועדת התוכנית. חבר ועדת התוכנית בוחר מאמר שברצונו לשבץ לו שופטים. המערכת מציגה את פרטי המאמר ופרטי שופטים. חבר ועדת התוכנית בוחר שניים עד ארבעה שופטים מתאימים לפי כישוריהם ותחומי העניין שלהם, מבין רשימת השופטים שהציגה המערכת. חבר ועדת התוכנית מאשר את שיבוץ השופטים. באמצעות מערכת הדואר האלקטרוני נשלחים לכל אחד מהשופטים שנבחרו לשפוט מאמר זה פרטי המאמר והמערכת רושמת לכל אחד מהם את התאריך האחרון להגשת תוצאות השיפוט. המערכת משנה את סטאטוס המאמר ל- "נשלח לשיפוט". הרחבות: אין הערה: ניתן גם לבנות לולאה שמתבצעת עבור כל מאמר שחבר ועדת התוכנית בוחר לשבץ.

פתרון דוגמא 3 – תיאור UC3 UC3: שלח תזכורת לשופטים מאחרים תיאור: שליחת תזכורת לשופטים אשר לא העבירו את דוח השיפוט עד למועד שנקבע להם בכל יום א' בבוקר. שחקנים: המערכת עבור חבר ועדת התוכנית, מערכת דואר אלקטרוני. תנאי קדם: קיימים מאמרים שהוגשו לכנס, שובצו לשופטים ועדיין לא התקבלו דוחות השיפוט שלהם. תנאי סיום: נשלחו תזכורות לשופטים מאחרים ועודכן סטאטוס מאמרים שעבורם הוגשו כל הדוחות. תסריט הצלחה עיקרי: המערכת עוברת על רשימת המאמרים שהוגשו לכנס, שובצו לשופטים וטרם התקבלו דוחות השיפוט שלהם. עבור כל מאמר שעבר התאריך האחרון להגשת דוח השיפוט שלו, המערכת שולחת תזכורת לשופט המאחר. המערכת עוברת על רשימת המאמרים שהוגשו לכנס ושובצו לשופטים. עבור כל מאמר שלו הוגשו כל הדוחות, המערכת מעדכנת את סטאטוס המאמר="התקבלו כל הדוחות". הרחבות: אין

פתרון דוגמא 3 – תיאור UC4 UC4: החלט על קבלת מאמר תיאור: חבר ועדת התוכנית מזין את החלטתו לגבי קבלת או דחיית מאמר לאחר קבלת דוחות השיפוט שחקנים: חבר ועדת התוכנית, מערכת דואר אלקטרוני. תנאי קדם: קיים מאמר שעבורו סטאטוס="התקבלו כל הדוחות". תנאי סיום: הוזנה החלטה על קבלת המאמר במערכת. תסריט הצלחה עיקרי: חבר ועדת התוכנית מבקש להחליט על קבלה/דחייה של מאמר. המערכת מציגה את רשימת המאמרים שעבורם התקבלו כל תוצאות השיפוט שלהם. חבר ועדת התוכנית בוחר מאמר מהרשימה. המערכת מציגה את פרטי המאמר ודוחות השיפוט שלו. חבר ועדת התוכנית מזין שהחליט לקבל את המאמר. המערכת משנה את סטאטוס המאמר ל- "התקבל". מערכת הדואר האלקטרוני שולחת הודעות קבלה עם דוחות השיפוט למחברי המאמר ולשופטי המאמר. הרחבות: 5א. חבר ועדת התוכנית מזין שהחליט לדחות את המאמר. 5א1. המערכת משנה את סטאטוס המאמר ל- "נדחה". 5א2. מערכת הדואר האלקטרוני שולחת הודעות דחייה עם דוחות השיפוט למחברי המאמר ולשופטי המאמר . 5א3. סיום ה-UC.

פתרון דוגמא 3 – תיאור UC5 UC5: קבע מושבים לכנס ושבץ מאמרים למושבים תיאור: חבר ועדת התוכנית מבקש לקבוע את מושבי הכנס ולשבץ לכל מושב מאמרים שהתקבלו לכנס שחקנים: חבר ועדת התוכנית. תנאי קדם: לכל המאמרים שהוגשו לכנס סטאטוס="התקבל"/"נדחה" (כלומר, הוחלט על קבלה/דחייה של כל המאמרים שהוגשו לכנס). תנאי סיום: מושבי הכנס שנקבעו והמאמרים ששובצו להם שמורים במערכת, תוכנית הכנס סגורה. תסריט הצלחה עיקרי: חברי ועדת התוכנית מבקשים לקבוע את מושבי הכנס. כל עוד התוכנית אינה סגורה ומתקבל קלט מחברי ועדת התוכנית לגבי המושבים והשיבוצים, בצע: המערכת מציגה את פרטי המאמרים שהתקבלו לכנס לחברי ועדת התוכנית. חברי ועדת התוכנית עוברים על מאמרים אלו ומחליטים על מושבי הכנס. המערכת שומרת את פרטי המושבים שנקבעו לכנס. חברי ועדת התוכנית מזינים למערכת את השיבוץ של מאמר למושב. המערכת שומרת את שיבוצי המאמרים למושבים. חברי ועדת התוכנית מזינים למערכת כי התוכנית סגורה. הרחבות: אין.