‫ניתוח ועיצוב‬

‫מערכות תוכנה‬

‫תירגול ‪– 4‬המשך ‪UC, GRASP‬‬

‫ו‪activity diagram-‬‬
 What are we going to talk about?
● Contracts & Use cases
● Activity Diagrams
● Interaction Diagrams
○ GRASP
● Exercises
 Use Case Diagram Objects
● Actor: Actor
• An actor is a person, organization, or external
system that plays a role in one or more
interactions with your system.
• You can use generalization 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. Use case
● subject boundary:
○ Indicates the scope of your subject.
○ Anything within the box represents subject
functionality that is in scope and anything boundary
outside the box is not .
Online C2C shopping
 Actor
Actor in a use case diagram is any entity that performs a role in one given system. This could be a person, organization
or an external system and usually drawn like skeleton shown below.

● Give meaningful business relevant names for actors

● Actors model roles (not positions)
● External systems are actors
● Actors don’t interact with other actors
● Place inheriting actors below the parent actor

Generalization of an Actor:

Generalization of an actor means that one actor can inherit the role of another actor. The descendant inherits all the use
cases of the ancestor.
The descendant have one or more use cases that are specific to that role
 Use Case
A use case represents a function or an action within the system. Drawn as an oval and named with the function. Top
level use cases should always provide a complete functions required by an actor.

● Names begin with a verb

● Make the name descriptive

Generalization of a use case

An inheriting use case inherits all traits from its ancestor. This is used to specify general use cases.

child
 System
System is used to define the scope of the use case and drawn as a rectangle. This an optional element
but useful when visualizing large systems.

For example, you can create all the use cases and then use the system object to define the scope covered
by your project. Or you can even use it to show the different areas covered in different releases.
 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.
● The included use case never stands alone.

● 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.
 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.
● There can be many extending use cases and many extension points.
 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.

Post-conditions This describes the state of the system following the successful
completion of this use.
Basic course of The main path of logic an actor follows through a use case. The path
action 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
 Alternative Courses

Happy Sad Bad

What is expected flow An expected failure of An unexpected failure
the flow
Successful order The order failed due The user ordered
from the supplier to insufficient negative number of
inventory products
 Contracts
Contract - a document that describes what an operation
commits to achieve.

A contract is expressed with:

● pre-conditions – Assumptions about the state of the system at the

beginning of the operation.
● post-conditions – State of the system after the operation has finished:

Goal: Create contracts for complex system operations.

Contracts are used to derive interaction diagrams for the operations.

 Contracts
Contract - a document that describes what an operation
commits to achieve.

A contract is expressed with: system

u r i ng a
e d
n the
● pre-conditions – Assumptions about thehstate ap p of system at the
beginning of the operation. at mu st
● post-conditions – State f of
y w h system after the operation has finished:
the
i
n s spec w !
i ti o h o
t complex system operations.
s t condcontracts
Goal:oCreate t nofor
P
ti o n , bu
o p era
Contracts are used to derive interaction diagrams for the operations.
 Interaction Diagrams

● Interaction diagrams show interactions, consisting of a set of objects and their relationships, including the
messages that may be dispatched among them.

● Two tasks that are intertwined in one another:

○ Impose responsibilities – assign operations to classes.
○ Design operations – sequence/collaboration diagrams.
● The design is based on principles (Patterns) for assigning responsibilities – GRASP (General Responsibility
Assignment Software Patterns).

Responsibility assignment:
Determine the class whose objects are responsible for performing
an operation. The operation becomes a method of that class .
Activity Diagrams
 Activity Diagrams

● Activity diagrams describe the workflow behavior of a system.

○ Activity diagrams are used in process modeling and analysis during requirements
engineering.
○ A typical business process which synchronizes several external incoming events can be
represented by activity diagrams.
● They are most useful for understanding workflow analysis of synchronous behaviors
across a process.
Activity Diagrams - Syntax
 GRASP Patterns
● Information Expert
● Creator
● High Cohesion
● Low Coupling
● Controller

● Good quality interaction diagrams express

codified patterns, principles and idioms.
 The Controller Pattern
● The controller pattern provides an advice for selecting a controller for a system event – an operation triggered by an
external actor.
● A controller is a domain layer object responsible for handling a system event. A controller defines a method for a
system operation.
○ Facade controller - Represents the overall system, device, or subsystem.
○ Use case controller - Represents a use case scenario within which the system event occurs.
■ Will usually be called <useCaseName>Handler.

○ Role controller – Represents something that can be involved in the task

 The Controller Pattern
● The controller pattern provides an advice for selecting a controller for a system event – an operation triggered by an
external actor.
● A controller is a domain layer object responsible for handling a system event. A controller defines a method for a
system operation.
A facade
○ controller
Facade controller -isRepresents
a good theoption
overallifsystem,
theredevice,
are only few system events.
or subsystem.
Otherwise
○ – the -fa
Use case controller çade controller
Represents takeswithin
a use case scenario too many
which the system event occurs.
Responsibilities
■ Will usually be called <useCaseName>Handler.

○ Role controller – Represents something that can be involved in the task

 The Creator Pattern
Assign class B the responsibility to create an instance of class A if one of the following holds:

● B aggregates objects of A.
● B contains objects of A.
● B records instances of objects of A.
● B closely uses objects of A.
● B has initializing data that will be passed to A when it is created (B is an Expert with respect to creating A).
 The Expert Pattern

● In this pattern responsibilities are assigned to the information expert the class that has the

information needed to solve the task.

 ‫(מועד ב‪ ,‬סמסטר א‪)2008 ,‬‬ ‫תרגיל ‪1‬‬
‫מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה של נכסי נדל"ן‪.‬‬ ‫●‬
‫המנצח במשחק הוא זה שצובר את הרכוש הרב ביותר (סכום ערך הנדל"ן והמזומנים שיש ברשותו)‪.‬‬

‫חוקים‪:‬‬ ‫●‬
‫הלוח מורכב ממשבצות שמקיפות אותו (לפחות ‪ 40‬משבצות‪ -‬תלוי קונפיגורציה)‪.‬‬ ‫○‬
‫כל שחקן בתורו מטיל קובייה ומתקדם לפי תוצאת הקובייה לכיוון קבוע‪.‬‬ ‫○‬
‫אם שחקן נוחת על משבצת שמייצגת שטח (רחוב בעיר מסוימת) שלא שייך לאף שחקן אחר הוא יכול לקנות אותו‪.‬‬ ‫○‬
‫אם הוא נוחת על שטח שכבר שייך לשחקן אחר עליו לשלם לו דמי שכירות (לפי תוצאה של הטלת קוביה)‪.‬‬ ‫○‬
‫על ידי קניית בתים בתוך השטחים ניתן להעלות את גובה דמי השכירות בשטח בו נמצא הבית‪.‬‬ ‫○‬
‫חובה לקנות את כל העיר (כל הרחובות בעיר) לפני קניית בית‪.‬‬ ‫○‬
‫לאחר קניית ‪ 4‬בתים ניתן לבנות מלון המגדיל את סכום השכירות עוד יותר‪.‬‬ ‫○‬
‫בכל פעם שחולפים על פני משבצת הפתיחה או נוחתים עליה‪ ,‬זוכים בסכום מסוים של כסף (תלוי קונפיגורציה)‪.‬‬ ‫○‬
‫אם שחקן נוחת על משבצות "ההפתעה" עליו לקחת קלף הפתעה ולבצע את ההוראות שבו (לזכות או לשלם סכום כסף מסוים‬ ‫○‬
‫לקופת המשחק)‪.‬‬
‫ישנה משבצת כלא שתנאי הכניסה והשחרור ממנה מוגדרים בקונפיגורציה של המשחק‪.‬‬ ‫○‬
‫במשחק משחקים ‪ 2‬עד ‪ 4‬שחקנים אנושיים‪.‬‬ ‫●‬
‫(מועד ב‪ ,‬סמסטר א‪)2008 ,‬‬ ‫תרגיל ‪1‬‬
‫פירוט לנקודות‪:‬‬
‫שחקן שיכול לזוז‪ ,‬צריך להטיל קוביה‬ ‫●‬
‫אם שטח פנוי – יכול לקנות‬ ‫○‬
‫אם שטח תפוס – שכירות (לפי הטלת קוביה)‬ ‫○‬
‫שחקן יכול להרחיב נכס מתי שהוא רוצה‬ ‫●‬
‫שחקן יכול לבצע החלפות עם שחקנים אחרים מתי שהוא רוצה‬ ‫●‬
‫רק מי שיש לו את כל הרחובות יכול לבנות בית‬ ‫●‬
‫צריך ‪ 4‬בתים בשביל מלון‬ ‫●‬
‫כשחולפים על פני משבצת הפתיחה מקבלים כסף‬ ‫●‬
‫יש משבצת הפתעה עם הוראות מיוחדות‬ ‫●‬
‫יש כלא‬ ‫●‬
 )2008 ,‫ סמסטר א‬,‫(מועד ב‬ 1 ‫תרגיל‬
Monopoly
Enter Player Info Switch Turn
> >
lude
inc
<<
move <<include>> Roll Dice

> >
nd

<<
te
ex

<<extend>>

ext
>
<<

>
d>
>>

>
en

de
nd

ten

d>

clu
te
Purchase Tradable Estate

ex

>
ex

in
<<
<<
<<
Human Player
DrawCard Go to
Go To Gail Pay Rent
Jail

Extend Estate
surprise

Trade

GetGet
Outout
of Gail
of Jail
 ‫(מועד ב‪ ,‬סמסטר א‪)2008 ,‬‬ ‫תרגיל ‪1‬‬
‫מונופול הוא משחק לוח המבוסס על עולם העסקים האמיתי בו מבצעים מהלכי קנייה ומכירה של נכסי נדל"ן‪.‬‬ ‫●‬
‫המנצח במשחק הוא זה שצובר את הרכוש הרב ביותר (סכום ערך הנדל"ן והמזומנים שיש ברשותו)‪.‬‬

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

‫ביישום זה יש משתמש אחד‪ ,‬תצפיתן‪ ,‬אשר מגדיר את כמות השחקנים שישתתפו במשחק‪ ,‬ועוקב אחרי מהלכי‬ ‫○‬
‫המשחק‪ .‬המשחק נגמר כאשר אחד השחקנים הווירטואליים או התצפיתן מחליטים לעצור אותו או כאשר מוכרז‬
‫מנצח‪.‬‬
‫(מועד ב‪ ,‬סמסטר א‪)2008 ,‬‬ ‫תרגיל ‪1‬‬
 UC ‫תיאור‬
● Use Case UC1: Play Monopoly Game
● Actor: Observer
● Pre Condition: The Application initialized properly.
● Post Condition: A winner has been declared or Observer cancels.
● Main Success Scenario:
1. Observer requests new game initialization, enters number of players.
2. Observer starts the game.
3. System displays game trace for next player move.
○ Repeat step 3 until a winner 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).
 ‫‪Exercise 2 - 2010‬‬
‫יש לטפל בקליטת‪/‬רישום מאמרים מוגשים מעת לעת לכנס ע"י מחבר‪/‬מחברים (המאמרים נשלחים במייל לועדה)‪.‬‬ ‫●‬
‫עבור כל מאמר שמוגש רושמים את הפרטים הבאים‪ :‬מספר מזהה ייחודי‪ ,‬שם המאמר‪ ,‬רשימת מילות מפתח ופרטי המחברים‬ ‫●‬
‫אם יש יותר ממחבר אחד רושמים מי מהם איש הקשר (הדבר רשום בפרטי ההגשה)‪ ,‬והמאמר מקבל סטאטוס "הוגש"‪.‬‬ ‫○‬
‫הטיפול במאמרים שהוגשו‪:‬‬ ‫●‬
‫אחד או יותר מחברי ועדת התכנית עובר על מספר מאמרים בסטאטוס "הוגש"‪ ,‬לפי בחירתו‪.‬‬ ‫○‬
‫עבור כל מאמר כזה ועל סמך מילות המפתח שמתארות אותו‪ ,‬הוא בוחר מספר שופטים מתאימים ובלבד שאף שופט לא קיבל בשלב‬ ‫○‬
‫זה יותר ממכסת המאמרים לשיפוט (נניח שישה)‪.‬‬
‫בעקבות בחירת שופט למאמר‪ ,‬המערכת שולחת לו בדוא"ל את פרטי המאמר וכתובת האתר שבו הוא יכול לקרוא את המאמר‬ ‫○‬
‫ולהוריד טופס‪/‬דוח שיפוט‪.‬‬
‫נאמר לשופט מהו המועד האחרון להגשת דוח השיפוט‪.‬‬ ‫○‬
‫עם תום הקצאת המאמר למספר משתנה סטאטוס המאמר ל"נשלח לשיפוט"‪.‬‬ ‫○‬
‫ניתן להניח ששופט שקיבל מאמר‪/‬ים לשיפוט קורא מאמר מבין המאמרים שנשלחו אליו וממלא דוח שיפוט‪.‬‬
‫השופט שולח את דוח שיפוט המאמר בדוא"ל לכתובת מתאימה של ועדת התכנית‪.‬‬ ‫○‬
‫במערכת נרשם סטאטוס "הוגש דוח" של שופט למאמר‪.‬‬ ‫○‬
 ‫‪Exercise 2 - 2010‬‬
‫בכל יום א' בבוקר המערכת עוברת על המאמרים שבסטאטוס "נשלח לשיפוט" ובודקת את מצב השיפוט‪:‬‬ ‫●‬
‫אם עדיין יש שופט‪/‬שופטים שטרם הגישו דוח והמועד האחרון להגשת הדוח הוא פחות מ‪ 7-‬ימים מהמועד האחרון שנדרש להגשת‬ ‫○‬
‫הדוח ‪ -‬נשלחת לאותו שופט‪/‬שופטים תזכורת מתאימה‪.‬‬
‫אם בעת הבדיקה מתברר שכל השופטים של מאמר כבר שלחו את דוחות השיפוט משתנה סטאטוס המאמר ל"התקבלו כל הדוחות"‪.‬‬ ‫○‬
‫עוברים חברי ועדת התכנית על מאמרים במערכת בסטאטוס "התקבלו כל הדוחות"‪ ,‬קוראים את דוחות השיפוט ומחליטים אם לקבל או‬ ‫●‬
‫לדחות את המאמרים‬
‫לאור החלטתה משתנה סטאטוס המאמר ל"התקבל" או "נדחה" ונשלחת הודעה מתאימה הן למחבר המאמר והן לשופטי המאמר – בצירוף‬ ‫●‬
‫דוחות השיפוט‪.‬‬
‫לאחר תום תקופת השיפוט ‪ ,‬מתכנסים חברי ועדת התכנית ועוברים על כל המאמרים שהתקבלו לכנס‪ .‬על פי שמות המאמרים‪ ,‬התקצירים‬ ‫●‬
‫ומילות המפתח שלהם הם מחליטים ורושמים אילו מושבים יהיו בכנס ומועדיהם‪ ,‬ואילו מאמרים ייכללו בכל מושב‪ ,‬כולל סדר ההצגה‪ .‬תהליך‬
‫זה יכול להתבצע בבת אחת עבור כל המאמרים או במספר סבבים‪ ,‬כאשר בכל פעם יש לאפשר לבצע שינויים בתכנית שיבוץ המושבים‬
‫והמאמרים‪.‬‬
‫בתום כל התהליך יציינו חברי הועדה במערכת שהתכנית "נסגרה" והמערכת לא תאפשר לבצע עוד שינויים של מושבים ושיבוצי מאמרים‪.‬‬ ‫●‬
 ‫‪Exercise 2 - 2010‬‬
‫סיכום בנקודות‪:‬‬
‫מאמרים מוגשים לועדה בדוא"ל‪ ,‬הם מזינים אותם למערכת‬ ‫●‬
‫עבור כל מאמר מזינים פרטים‬ ‫●‬
‫חברי הועדה בוחרים שופטים למאמרים‪ ,‬לשופטים נשלחת הודעה בהתאם‬ ‫●‬
‫חברי הועדה מקבלים את דוחות השיפוט במייל ומזינים למע'‬ ‫●‬
‫המע' שולחת תזכורות לשופטים מאחרים‬ ‫●‬
‫חברי הועדה מחליטים על קבלה‪/‬אי קבלה ונשלחת הודעה מתאימה לשופטים ולכותבי המאמר‬ ‫●‬
‫חברי הועדה קובעים את המושבים בכנס‬ ‫●‬
 ‫תיאור ‪UC‬‬
‫‪ :UC1‬הגש מאמר לכנס‬ ‫●‬
‫תיאור‪ :‬מחבר המאמר מגיש מאמר לכנס‪.‬‬ ‫●‬
‫שחקנים‪ :‬ועדת התוכנית‪.‬‬ ‫●‬
‫תנאי קדם‪ :‬אין‪.‬‬ ‫●‬
‫תנאי סיום‪ :‬פרטי המאמר נשמרו במערכת בסטאטוס = "הוגש"‪ ,‬פרטי המחברים נשמרו במערכת‪.‬‬ ‫●‬
‫תסריט הצלחה עיקרי‪:‬‬ ‫●‬
‫מחבר מאמר מבקש להגיש מאמר לכנס‪.‬‬ ‫‪.1‬‬
‫חבר ועדת התוכנית מזין את הפרטים הבאים למערכת‪ :‬מספר מזהה‪ ,‬שם המאמר‪ ,‬מילות מפתח‪ ,‬תקציר מאמר‪ ,‬פרטי‬ ‫‪.2‬‬
‫איש קשר‪.‬‬
‫חבר ועדת התוכנית מזין את פרטי המחברים של מאמר למערכת‪.‬‬ ‫‪.3‬‬
‫המערכת שומרת את פרטי המחברים במערכת ‪.‬‬ ‫‪.4‬‬
‫המערכת קובעת למאמר סטאטוס "הוגש"‪ ,‬ושומרת את פרטיו‪.‬‬ ‫‪.5‬‬
‫הרחבות‪:‬‬ ‫●‬
‫‪4‬א‪ .‬מחבר מאמר קיים כבר במערכת‪ ,‬המערכת לא שומרת את פרטיו שוב‪.‬‬
‫‪5‬א‪ .‬המאמר כבר הוגש למערכת‪ ,‬המערכת מציגה הודעת שגיאה והמאמר לא נשמר‪.‬‬
 ‫תיאור ‪UC‬‬
‫‪ :UC2‬שבץ שופטים למאמר‬ ‫●‬
‫תיאור ‪ :‬חברי ועדת התוכנית בוחרים שופטים לשיפוט מאמרים שהוגשו לכנס‪.‬‬ ‫●‬
‫שחקנים‪ :‬ועדת התוכנית‪ ,‬מערכת דואר אלקטרוני‪.‬‬ ‫●‬
‫תנאי קדם‪ :‬הוגש לפחות מאמר אחד לכנס אשר טרם שובצו לו שופטים‪.‬‬ ‫●‬
‫תנאי סיום‪ :‬שובצו שופטים למאמר‪ ,‬המאמר נשלח לשופטים ונקבע לו סטאטוס "נשלח לשיפוט"‪.‬‬ ‫●‬
‫תסריט הצלחה עיקרי‪:‬‬ ‫●‬
‫חבר ועדת התוכנית מבקש לשבץ שופטים למאמר‪.‬‬ ‫‪.1‬‬
‫המערכת מציגה את רשימת המאמרים שהוגשו ולא שובצו (בסטאטוס "הוגש") לחבר ועדת התוכנית‪.‬‬ ‫‪.2‬‬
‫חבר ועדת התוכנית בוחר מאמר שברצונו לשבץ לו שופטים‪.‬‬ ‫‪.3‬‬
‫המערכת מציגה את פרטי המאמר ופרטי שופטים‪.‬‬ ‫‪.4‬‬
‫חבר ועדת התוכנית בוחר שניים עד ארבעה שופטים מתאימים לפי כישוריהם ותחומי העניין שלהם‪ ,‬מבין רשימת השופטים שהציגה‬ ‫‪.5‬‬
‫המערכת‪.‬‬
‫חבר ועדת התוכנית מאשר את שיבוץ השופטים‪.‬‬ ‫‪.6‬‬
‫באמצעות מערכת הדואר האלקטרוני נשלחים לכל אחד מהשופטים שנבחרו לשפוט מאמר זה פרטי המאמר והמערכת רושמת לכל‬ ‫‪.7‬‬
‫אחד מהם את התאריך האחרון להגשת תוצאות השיפוט‪.‬‬
‫המערכת משנה את סטאטוס המאמר ל‪" -‬נשלח לשיפוט"‪.‬‬ ‫‪.8‬‬
‫הרחבות‪ :‬אין‬ ‫●‬
Exercise 3 – Activity Diagrams