Lecture04- Use Case Diagrams

Computer Engineering Department

Object Oriented Software Modeling and Design g

CE 350Abdel-Karim Al-Tamimi, Ph.D.

[email protected]@yu.edu.jo

http://faculty.yu.edu.jo/altamimi

Al-Tamimi 2011 © 1

OverviewOverview

• Use-case DiagramsUse case Diagrams

Al-Tamimi 2011 © 2

Use-Case DiagramsUse Case Diagrams

Al-Tamimi 2011 © 3

Why We Use Use-case DiagramsWhy We Use Use case Diagrams

Al-Tamimi 2011 © 4


• Answers the main questions about your Answers the main questions about your system:

Who’s your system’s for?– Who s your system s for?

– What must it do?

Why build it in the first place?– Why build it in the first place?

• System users: Actors

• System normal situations: use-cases

Al-Tamimi 2011 © 5


• Stay focus on your client’s goalsStay focus on your client s goals

• A good use case must represent the point of view of the people who will use or of view of the people who will use or interact with the system

A l f • A complete set of use cases = system requirements

Al-Tamimi 2011 © 6

Use-Case DiagramUse Case Diagram

• A use-case model is a diagram or set of diagrams g gthat together with some additional documentation show what the proposed software system is designed to do A use case diagram consists of designed to do. A use-case diagram consists of three main components:– Actors – Use-cases, and their communications– some additional documentation such as use-case

descriptions for elaborating use cases and problem descriptions for elaborating use-cases and problem statements that are initially used for identifying use cases

Al-Tamimi 2011 © 7

Use-Case Diagram: ActorsUse Case Diagram: Actors

• Usually represented Usually represented with a stick figure

• An actor may be:y b– People

– Computer hardware and devices

– External systems

8Al-Tamimi 2011 ©

Use-Case Diagram: ActorsUse Case Diagram: Actors

• An actor represents a role that a user can play, An actor represents a role that a user can play, but NOT a specific user

• Primary actors are those who use the system’s main f nctions deri ing benefits from it directl functions, deriving benefits from it directly. – Primary actors are completely outside the system and drive the

system requirements– Primary actors use the system to achieve an observable user goalPrimary actors use the system to achieve an observable user goal

• Secondary actors play a supporting role to facilitate the primary actors to achieve their goals.– Secondary actors often appear to be more inside the system than Secondary actors often appear to be more inside the system than

outside– Secondary actors are usually not derived directly from the

statement of requirements. Hence, the designer can have more freedom in specifying the roles of these actorsfreedom in specifying the roles of these actors

– Usually found on the right of the system (primary on the left)Al-Tamimi 2011 © 9

Use-Case Diagrams: ActorsUse Case Diagrams: Actors

• Actors are treated like classes and thus can Actors are treated like classes and thus can be generalized

Student

Al-Tamimi 2011 © 1010

MasterStudent BAStudent

Use-Case Diagrams: Actors and lGoals

1 Start by identifying the actors of the 1. Start by identifying the actors of the system

2 See if the actors can be generalized or not2. See if the actors can be generalized or not

3. Define the goals of the system and how h b hi d i h ’ they can be achieved using the systems’

actors

4. Illustrate these goals and actors actions using use-case diagram(s)

Al-Tamimi 2011 © 11

Use-case Diagram: Use-caseUse case Diagram: Use case

• A use case describes a sequence of actions a system f i ld b bl l l performs to yield an observable result or value to a

particular actor • Naming convention = verb + noun (or) verb + noun-

h phrase, – e.g. withdraw cash

• A good use case should:– Describe a sequence of transactions performed by a system that

produces a measurable result (goal) for a particular actor– Describe the behavior expected of a system from a user's

perspectiveperspective– Enable the system analyst to understand and model a system

from a high-level business viewpointRepresent the interfaces that a system makes visible to the


– Represent the interfaces that a system makes visible to the external entities and the interrelationships between the actors and the system

EBP Test for Use-CasesEBP Test for Use Cases

• Elementary Business Process (EBP) is a Elementary Business Process (EBP) is a term from the business process engineering field defined as:engineering field defined as:

• A task performed by one person in one place at one time in response to a place at one time, in response to a business event, which adds a measurable business value and leaves the data in a business value and leaves the data in a consistent state

E A C dit C l O d– E.g. Approve Credit or Cancel Order


Use-Case Diagram: Use-CaseUse Case Diagram: Use Case






Use-Case Diagram: ExampleUse Case Diagram: Example

Use case

System name

Actor Use-case

Association System boundary



• Let us consider a simple hotel informationpsystem for two types of customers:– Tour Group customers and Individual

customerscustomers– Tour Group customers are those who have

made reservations through a tour operator ind hil I di id l t kadvance, while Individual customers make

their reservations directly with the hotel– Both types of customers can book, cancel,o ypes o cus o e s ca boo , ca ce ,

check-in and check-out of a room byphone or via the Internet




Structuring Use-cases with RelationshipsStructuring Use cases with Relationships

• In the process of developing a use case p p gmodel, we may discover that some use cases share common behaviorsTh l i i h • There are also situations where some use cases are very similar but they have some additional behaviors additional behaviors

• For example, Withdraw Money and Deposit Money both require the user to p y qlog-on to an ATM system



Use Case: Withdraw Money Use Case: Deposit Money

Flow of Events:

1. The user inserts an ATM card. The system prompts the user to enter a

Flow of Events:

1. The user inserts an ATM card. The system prompts the user to enter a y p p

password.2. The user enters the password. The system validates the user password.

y p ppassword.2. The user enters the password. The system validates the user password.

....….….

....….….

Common Behavior



Use Case: Withdraw Money

Flow of Events:

1 include (Login Account)

Use Case: Deposit Money

Flow of Events:

1 include (Login Account)1. include (Login Account)....….….

1. include (Login Account)….….…..

Use Case: Login Account

Flow of Events:

1. The user inserts an ATM card. The system prompts the user to enter a

d


password.2. The user enters the password. The system validates the user password.

The <<include>> RelationshipThe <<include>> Relationship

• Include relationships are used when two por more use cases share some common portion in a flow of events Thi i i h d d • This common portion is then grouped and extracted to form an inclusion use case for sharing among two or more use cases sharing among two or more use cases

• Most use cases in the ATM system example, such as Withdraw Money, p , y,Deposit Money or Check Balance, share the inclusion use-case Login Account



Login Account

(Included use case)

Withdraw Money

(Base use case)

(Included use case)



• When to use include When to use include relationship:– The behavior of the

inclusion use case is common to two or more use casesmore use cases

– The result of the behavior that the inclusion use case specifies, not the behavior itself, is ,important to the base use case 25Al-Tamimi 2011 ©

The <<include>> Relationship: ExampleThe <<include>> Relationship: Example


The <<include>> Relationship: ExampleThe <<include>> Relationship: Example


The <<extend>> RelationshipThe <<extend>> Relationship

• In UML modeling you can use an extend In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of (extension) extends the behavior of another use case (base)

• This type of relationship reveals details • This type of relationship reveals details about a system or application that are typically hidden in a use casetypically hidden in a use case



• The extend relationship specifies that the The extend relationship specifies that the incorporation of the extension use case is dependent on what happens when the dependent on what happens when the base use case executes

• The extension use case owns the extend • The extension use case owns the extend relationship. You can specify several extend relationships for a single base use extend relationships for a single base use case



• While the base use case is defined independently While the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own

• The extension use case consists of one or several behavior sequences (segments) that describe additional behavior that can incrementally augment the behavior of the base use-case

h b i d i h b • Each segment can be inserted into the base use case at a different point, called an extension pointpoint



Withdraw MoneyProcess Excess Amount (Extending use case)

Withdraw Money (Base use case)


If conditional guard is true, extending flow is executed


• The extension use case can access and The extension use case can access and modify the attributes of the base use case; however the base use case is not aware of however, the base use case is not aware of the extension use case and, therefore, cannot access or modify the attributes and cannot access or modify the attributes and operations of the extension use case



• You can add extend relationships to a model to show the following situations:situations:– A part of a use case that is

optional system behavior

A bfl i d l – A subflow is executed only under certain conditions

– A set of behavior segments h b i d i that may be inserted in a

base use case

33Al-Tamimi 2011 ©








The Generalization RelationshipThe Generalization Relationship

• A child use-case can inherit the behaviors, ,relationships and communication links of a parent use-case (like Actor generalization)

• In other words it is valid to put the child use-In other words, it is valid to put the child usecase at a place wherever a parent use-case appearsTh l ti hi b t th hild d • The relationship between the child use-case and the parent use-case is the generalization relationship

• For example: suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility BillPay Credit Card Bill and Pay Utility Bill

38


39


40

Use-Case ScopeUse Case Scope

• A use case must be initiated by an actorA use case must be initiated by an actor

• When a use case is considered complete, there are no further inputs or outputs; the there are no further inputs or outputs; the desired functionality has been performed, or an error has occurredor an error has occurred

• After a use case has completed, the system i i h h b is in a state where the use case can be started again, or the system is in an error state

41

Base Use-Case vs. Abstract Use-CaseBase Use Case vs. Abstract Use Case

• Base use case – invoked directly by actor y yto achieve an observable goal

• Abstract use case – invoked by other use d i l l f cases and is not a complete goal from

user’s perspective • e g withdraw cash (concrete use case) vs • e.g. withdraw cash (concrete use case) vs.

login (abstract use case)

42


43


44

Summary of NotationsSummary of Notations

Construct Description Notation

Use-case A sequence of transactions performed by a system that produces a measurable result for a particular actor

Actor A coherent set of roles that users playActor A coherent set of roles that users playwhen interacting with these use cases

SystemBoundary

The boundary between the physical system and the actors who interact with the physical system

45

Summary of NotationsSummary of NotationsConstruct Description Notation

Association The participation of an actor in a use case, i.e. an instance of an actor and instances of a use case communicating with each other

Generalization A taxonomic relationship between l d a general use case and a more

specific use case. The arrow head points to the general use case

E t d A l ti hi b t Extend A relationship between an extension use case and a base use case, specifying how the behavior of the extension use case can be

46

inserted into the behavior defined for the base use case. The arrow head points to the base use case

Summary of NotationsSummary of Notations

Construct Description Notation

Include A relationship between a base use case and an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use behavior defined for the base use case. The arrow head points to theinclusion use case

47

ResourcesResources

• Chapter 3 from “Object-Oriented Chapter 3 from Object Oriented Technology: From diagram to code with Visual Paradigm for UML”Visual Paradigm for UML

• UML 2 for dummies, chapters 8-10

UML ifi i id h • UML 2 certification guide, chapter 2

• Chapter 6 from “Applying UML and Patterns”


Education

Lecture04- Use Case Diagrams