ניתוח ועיצוב מערכות תוכנה

2012אביב שימוש נסיבות

(Use Case Modeling)

1

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]

2

Use Case Description Template

3

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

Finding ActorsExternal objects that produce/consume data:

Must serve as sources and destinations for dataMust be external to the system

Humans Machines External systems Sensors

Database PrinterOrganizational Units

Use Case DiagramActor:

• 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 .

5

Online Shopping

Actor

Use case

subject boundary

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.

6

Organizing Use Case - ExtendAn 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.

7

Include vs. Extend - Comparison

8

Extend Include

• 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

(2008)מועד ב, סמסטר א, 1דוגמא

מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה שלנכסי נדל"ן. המשחק מבוצע תוך כדי סימולציה של מהלכים עסקיים אמיתיים, כשהשחקנים קונים

ומוכרים נכסים, בונים בתים ומלונות. המנצח במשחק הוא זה שצובר את הרכוש הרב ביותר )סכום ערך הנדל"ן והמזומנים שיש ברשותו(.

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

לקנות אותו. אם הוא נוחת על שטח שכבר שייך לשחקן אחר עליו לשלם לו דמי שכירות, בהיקף אשר נקבע ע"י הטלת

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

קונפיגורציה(. אם שחקן נוחת על משבצות "ההפתעה" עליו לקחת קלף הפתעה ולבצע את ההוראות שבו )לזכות או

לשלם סכום כסף מסוים לקופת המשחק(. .ישנה משבצת כלא שתנאי הכניסה והשחרור ממנה מוגדרים בקונפיגורציה של המשחק

שחקנים אנושיים. במידה וחסרים שחקנים אנושיים, ניתן להגדיר 4 עד 2במשחק משחקים שחקני מחשב. שחקן המחשב יכול לשחק באסטרטגיה חמדנית )בכל הזדמנות שיש לו לקנות נכס כלשהוא, הוא יקנה אותו, אלא אם אין לו כסף( או רנדומאלית )מחליט באופן אקראי אם

לקנות נכס נתון(. המשחק נגמר כאשר אחד השחקנים מחליט לעצור אותו.

9

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

10

(2008 )מועד א, סמסטר א, 1דוגמא מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה

של נכסי נדל"ן. המשחק מבוצע תוך כדי סימולציה של מהלכים עסקיים אמיתיים, כשהשחקנים קונים ומוכרים נכסים, בונים בתים ומלונות. המנצח במשחק הוא זה שצובר את הרכוש הרב

ביותר )סכום ערך הנדל"ן והמזומנים שיש ברשותו(.:חוקים

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

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

קונפיגורציה(. ביישום זה יש משתמש אחד, תצפיתן, אשר מגדיר את כמות השחקנים שישתתפו

במשחק, ועוקב אחרי מהלכי המשחק. המשחק נגמר כאשר אחד השחקנים הווירטואליים או התצפיתן מחליטים לעצור אותו או כאשר מוכרז מנצח.

11

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

12

UC – תיאור 2פתרון דוגמא 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:

1. 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(

1. Observer restarts System.

2. System detects prior failure, reconstructs state, and prompts to continue.

3. Observer chooses to continue )from last completed player turn(.

4. Player wishes to start use-case “End Game”

13

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

ואחד מחבריה מטפל ברישומם ועדת התכנית לכתובת של נשלחים בדוא"ל שמאמרים במערכת.(

רושמים את הפרטים הבאים: מספר מזהה ייחודי, שם המאמר, רשימת מאמר שמוגש עבור כלמילות מפתח ופרטי המחברים; אם יש יותר ממחבר אחד רושמים מי מהם איש הקשר )הדבר

רשום בפרטי ההגשה(, והמאמר מקבל סטאטוס "הוגש". שהוגשו לכנס הוא כלהלן: אחד או יותר מחברי ועדת התכנית עובר על הטיפול במאמרים

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

למאמר, המערכת שולחת לו בדוא"ל את פרטי המאמר וכתובת האתר שבו הוא יכול לקרוא את המאמר ולהוריד טופס/דוח שיפוט; כן נאמר לשופט מהו המועד האחרון להגשת דוח השיפוט.

עם תום הקצאת המאמר למספר שופטים )שמספרם נתון לשיקול דעת ועדת התכנית( משתנה סטאטוס המאמר ל"נשלח לשיפוט". )אינך נדרש לטפל בבעיות אפשריות של מחסור בשופטים

וכדומה.( ניתן להניח ששופט שקיבל מאמר/ים לשיפוט קורא מעת לעת המאמר מבין המאמרים שנשלחו אליו וממלא דוח שיפוט. )אינך נדרש לטפל בתהליך ההתחברות של שופט למערכת

שבה מצויים המאמרים ואופן מילוי הטופס/הדוח.( השופט שולח את דוח שיפוט המאמר בדוא"ל לכתובת מתאימה של ועדת התכנית. הנח שחבר ועדת התכנית עובר מעת לעת על הודעות

הדוא"ל שהתקבלו ומעביר/מעתיק את דוחות השיפוט למערכת. במערכת נרשם סטאטוס "הוגש )אינך מתבקש לטפל בנושא זה של הגשת דוח השיפוט למאמר דוח" של שופט למאמר.

14 ע"י השופט(.

)המשך(( 2010 )בוחן 3דוגמא

בודקת את בכל יום א' בבוקר המערכת עוברת על המאמרים שבסטאטוס "נשלח לשיפוט" ו: אם עדיין יש שופט/שופטים שטרם הגישו דוח והמועד האחרון להגשת הדוח הוא מצב השיפוט

ימים מהמועד האחרון שנדרש להגשת הדוח - נשלחת לאותו שופט/שופטים תזכורת 7פחות מ-מתאימה. אם בעת הבדיקה מתברר שכל השופטים של מאמר כבר שלחו את דוחות השיפוט

משתנה סטאטוס המאמר ל"התקבלו כל הדוחות". "מעת לעת עוברים חברי ועדת התכנית על מאמרים במערכת בסטאטוס "התקבלו כל הדוחות

; מחליטים אם לקבל או לדחות את המאמרים)חלקם או כולם(, קוראים את דוחות השיפוט ולאור החלטתה משתנה סטאטוס המאמר ל"התקבל" או "נדחה" ונשלחת הודעה מתאימה הן

למחבר המאמר )באמצעות איש הקשר( והן לשופטי המאמר – בצירוף דוחות השיפוט. )בדרישות של מערכת זו לא נכלל טיפול בתהליך אפשרי של הגשת תיקונים, בבעיות של אי

הגשת דוחות שיפוט ועוד דברים שלא תוארו כאן.( מתכנסים חברי ועדת התכנית ועוברים על כל המאמרים לאחר תום תקופת השיפוט ,

שהתקבלו לכנס. על פי שמות המאמרים, התקצירים ומילות המפתח שלהם הם מחליטים ורושמים אילו מושבים יהיו בכנס ומועדיהם, ואילו מאמרים ייכללו בכל מושב, כולל סדר ההצגה. תהליך זה יכול להתבצע בבת אחת עבור כל המאמרים או במספר סבבים, כאשר בכל פעם יש

לאפשר לבצע שינויים בתכנית שיבוץ המושבים והמאמרים. בתום כל התהליך יציינו חברי הועדה במערכת שהתכנית "נסגרה" והמערכת לא תאפשר לבצע עוד שינויים של מושבים

ושיבוצי מאמרים.

15

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

16

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

במערכת.:תסריט הצלחה עיקרי

מחבר מאמר מבקש להגיש מאמר לכנס.1.

חבר ועדת התוכנית מזין את הפרטים הבאים למערכת: מספר מזהה, שם המאמר, מילות מפתח, 2.תקציר מאמר, פרטי איש קשר.

חבר ועדת התוכנית מזין את פרטי המחברים של מאמר למערכת.3.

המערכת שומרת את פרטי המחברים במערכת .4.

המערכת קובעת למאמר סטאטוס "הוגש", ושומרת את פרטיו.5. :הרחבות

מחבר מאמר קיים כבר במערכת, המערכת לא שומרת את פרטיו שוב.א. 4

המאמר כבר הוגש למערכת, המערכת מציגה הודעת שגיאה והמאמר לא נשמר.א. 5

17

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

לשיפוט".:תסריט הצלחה עיקרי

חבר ועדת התוכנית מבקש לשבץ שופטים למאמר.1.

המערכת מציגה את רשימת המאמרים שהוגשו ולא שובצו )בסטאטוס "הוגש"( לחבר ועדת התוכנית.2.

חבר ועדת התוכנית בוחר מאמר שברצונו לשבץ לו שופטים.3.

המערכת מציגה את פרטי המאמר ופרטי שופטים.4.

חבר ועדת התוכנית בוחר שניים עד ארבעה שופטים מתאימים לפי כישוריהם ותחומי העניין שלהם, 5.מבין רשימת השופטים שהציגה המערכת.

חבר ועדת התוכנית מאשר את שיבוץ השופטים.6.

באמצעות מערכת הדואר האלקטרוני נשלחים לכל אחד מהשופטים שנבחרו לשפוט מאמר זה פרטי 7.המאמר והמערכת רושמת לכל אחד מהם את התאריך האחרון להגשת תוצאות השיפוט.

המערכת משנה את סטאטוס המאמר ל- "נשלח לשיפוט".8. :איןהרחבותניתן גם לבנות לולאה שמתבצעת עבור כל מאמר שחבר ועדת התוכנית בוחר לשבץ.הערה :

18

UC3 – תיאור 3פתרון דוגמא UC3שלח תזכורת לשופטים מאחרים :שליחת תזכורת לשופטים אשר לא העבירו את דוח השיפוט עד למועד שנקבע להם בכל תיאור :

יום א' בבוקר.:המערכת עבור חבר ועדת התוכנית, מערכת דואר אלקטרוני.שחקנים :קיימים מאמרים שהוגשו לכנס, שובצו לשופטים ועדיין לא התקבלו דוחות השיפוט תנאי קדם

שלהם.:נשלחו תזכורות לשופטים מאחרים ועודכן סטאטוס מאמרים שעבורם הוגשו כל תנאי סיום

הדוחות.:תסריט הצלחה עיקרי

המערכת עוברת על רשימת המאמרים שהוגשו לכנס, שובצו לשופטים וטרם התקבלו דוחות השיפוט 1.שלהם.

עבור כל מאמר שעבר התאריך האחרון להגשת דוח השיפוט שלו, המערכת שולחת תזכורת לשופט 2.המאחר.

המערכת עוברת על רשימת המאמרים שהוגשו לכנס ושובצו לשופטים.3.

עבור כל מאמר שלו הוגשו כל הדוחות, המערכת מעדכנת את סטאטוס המאמר="התקבלו כל 4.הדוחות".

:איןהרחבות

19

UC4 – תיאור 3פתרון דוגמא UC4החלט על קבלת מאמר :חבר ועדת התוכנית מזין את החלטתו לגבי קבלת או דחיית מאמר לאחר קבלת דוחות תיאור :

השיפוט:חבר ועדת התוכנית, מערכת דואר אלקטרוני.שחקנים :קיים מאמר שעבורו סטאטוס="התקבלו כל הדוחות".תנאי קדם :הוזנה החלטה על קבלת המאמר במערכת.תנאי סיום :תסריט הצלחה עיקרי

חבר ועדת התוכנית מבקש להחליט על קבלה/דחייה של מאמר.1.

המערכת מציגה את רשימת המאמרים שעבורם התקבלו כל תוצאות השיפוט שלהם.2.

חבר ועדת התוכנית בוחר מאמר מהרשימה.3.

המערכת מציגה את פרטי המאמר ודוחות השיפוט שלו.4.

חבר ועדת התוכנית מזין שהחליט לקבל את המאמר.5.

המערכת משנה את סטאטוס המאמר ל- "התקבל".6.

מערכת הדואר האלקטרוני שולחת הודעות קבלה עם דוחות השיפוט למחברי המאמר ולשופטי 7.המאמר.

:הרחבותחבר ועדת התוכנית מזין שהחליט לדחות את המאמר.א. 5

המערכת משנה את סטאטוס המאמר ל- "נדחה".. 1א5

מערכת הדואר האלקטרוני שולחת הודעות דחייה עם דוחות השיפוט למחברי המאמר ולשופטי . 2א5המאמר .

.UCסיום ה-. 3א520

UC5 – תיאור 3פתרון דוגמא  UC5קבע מושבים לכנס ושבץ מאמרים למושבים :חבר ועדת התוכנית מבקש לקבוע את מושבי הכנס ולשבץ לכל מושב מאמרים תיאור :

שהתקבלו לכנס:חבר ועדת התוכנית.שחקנים :לכל המאמרים שהוגשו לכנס סטאטוס="התקבל"/"נדחה" )כלומר, הוחלט על תנאי קדם

קבלה/דחייה של כל המאמרים שהוגשו לכנס(.:מושבי הכנס שנקבעו והמאמרים ששובצו להם שמורים במערכת, תוכנית הכנס תנאי סיום

סגורה.:תסריט הצלחה עיקרי

חברי ועדת התוכנית מבקשים לקבוע את מושבי הכנס.1.

כל עוד התוכנית אינה סגורה ומתקבל קלט מחברי ועדת התוכנית לגבי המושבים והשיבוצים, בצע:2.

המערכת מציגה את פרטי המאמרים שהתקבלו לכנס לחברי ועדת התוכנית.1.

חברי ועדת התוכנית עוברים על מאמרים אלו ומחליטים על מושבי הכנס.2.

המערכת שומרת את פרטי המושבים שנקבעו לכנס.3.

חברי ועדת התוכנית מזינים למערכת את השיבוץ של מאמר למושב.4.

המערכת שומרת את שיבוצי המאמרים למושבים.5.

חברי ועדת התוכנית מזינים למערכת כי התוכנית סגורה.3. :אין.הרחבות

21