UML

Review of Use case diagrams

2

Unified Modeling LanguageThe Unified Modeling Language™ (UML) was developed jointly by Grady Booch, Ivar Jacobson, and Jim Rumbaugh and is promotted by The Object Management Group (OMG).UML provides the application modeling language for:

Business process modeling/ Requirement Analysis with use cases. Static Design with Class modeling and object modeling. Dynamic Design with sequence, collaboration and activity diagrams. Component modeling. Distribution and deployment modeling.

See http://www.agilemodeling.com/essays/umlDiagrams.htm http://www.uml.org/

3

Phases of System Development Requirement Analysis

Functionality users require from the system Use case model

OO Analysis Discovering classes and relationships UML class diagram

OO Design Result of Analysis expanded into technical solution Sequence diagram, state diagram, etc. Results in detailed specs for the coding phase

Implementation (Programming/coding) Models are converted into code

Testing Unit tests, integration tests, system tests and acceptance tests.

4

UML Diagrams

UML includes 9 types of diagrams Use case diagrams

Describe the functional behavior of the system as seen by the user.

Sequence diagrams Describe the dynamic behavior between actors and the

system and between objects of the system. Class diagrams

Describe the static structure of the system: Objects, Attributes, and Associations.

5

UML: Use Case Diagrams

WatchUser WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

SystemSimpleWatch

Use case diagrams represent the functionality of the systemfrom user’s point of view.

6

Use-Case Modeling In use-case modeling, the system is looked upon as a black box whose

boundaries are defined by its functionality to external stimulus.

The actual description of the use-case is usually given in plain text. A popular notation promoted by UML is the stick figure notation. Both visual and text representation are needed for a complete view.

A use-case model represents the use-case view of the system. A use-case view of a system may consist of many use case diagrams.

An use-case diagram shows (the system), the actors, the use-cases and the relationship among them.

7

Components of Use Case Model The components of a use case model are:

Use cases Actors System Modeled Stimulus

Example: Consider a train ticket booking system

System Name

name

Use-case

8

System As a part of the use-case modeling, the boundaries

of the system are developed.

System in the use-case diagram is a box with the name appearing on the top.

Defining a system is an attempt to define the catalog of terms and definitions at an early stage of the development of a business model.

9

Actors An actor is something or someone that interacts with the system.

Actor communicates with the system by sending and receiving messages.

An actor provides the stimulus to activate an use case.

Message sent by an actor may result in more messages to actors and to use cases.

Actors can be ranked: primary and secondary; passive and active.

Actor is a role not an individual instance.

10

Finding Actors The actors of a system can be identified by

answering a number of questions: Who will use the functionality of the system? Who will maintain the system? What devices does the system need to handle? What other system does this system need to interact? Who or what has interest in the results of this system?

11

UML: Use Case DiagramsUsed during requirements elicitation to

represent external behavior

Actors represent roles, that is, a type of user of the system

Use cases represent a sequence of interaction for a type of functionality

The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment

Passenger

PurchaseTicket

12

Actors An actor models an external entity which

communicates with the system: User External system Physical environment

An actor has a unique name and an optional description.

Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS

coordinates

Passenger

13

Use CaseA use case represents a class of

functionality provided by the system as an event flow.

A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements

PurchaseTicket

14

The <<extend>> Relationship

Passenger

PurchaseTicket

TimeOut

<<extend>>

NoChange

<<extend>>OutOfOrder

<<extend>>

Cancel

<<extend>>

<<extend>> relationships represent exceptional or seldom invoked cases.

The exceptional event flows are factored out of the main event flow for clarity.

Use cases representing exceptional flows can extend more than one use case.

The direction of a <<extend>> relationship is to the extended use case

15

Passenger

PurchaseSingleTicket

PurchaseMultiCard

NoChange

<<extend>>

Cancel

<<extend>>

<<include>>

CollectMoney

<<include>>

The <<include>> Relationship An <<include>> relationship

represents behavior that is factored out of the use case.

An <<include>> represents behavior that is factored out for reuse, not because it is an exception.

The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships).

16

Use Case Description ExampleName: Purchase ticket

Participating actor: Passenger

Entry condition: Passenger standing in front of

ticket distributor. Passenger has sufficient

money to purchase ticket.

Exit condition: Passenger has ticket.

Event flow:1. Passenger selects the number

of zones to be traveled.2. Distributor displays the

amount due.3. Passenger inserts money, of

at least the amount due.4. Distributor returns change.5. Distributor issues ticket.Exceptional conditions: Exercise