Use Cases

• The use case structure is a great way to brainstorm

alternatives to the main
• Success Scenario . For each step, ask, How could this
go differently? and in particular,
• What could go wrong? It's usually best to
brainstorm all the extension conditions first, before
you get working out with the consequences .
• You'll probably think of more conditions this way,
which translates to fewer goods that you have to
pick up later.
• A complicated step in a use case can be
another use case . In UML terms, we say that
the first use case includes the second .
 Steps in The Scenarios
• A pre-condition: describes what the System should
ensure is true before the system allows the use case to
begin . This is useful for telling the programmers what
conditions they don't have to check for in their code .
• A guarantee: describes what the system will ensure at
the end of the use case . Success guarantees hold after
a successful scenario ; minimal guarantees hold after
any scenario.
• A trigger: specifies the event that gets the use case
started .
• The customer browses the catalog and adds
desired items to the Shopping basket.
• When the customer wishes to pay, the
customer describes the shipping and credit
card information and confirms the sale .
• The System Checks the authorization and the
credit card and confirms the sale both
immediately and with a follow-up e-mail .
• Included use cases can be useful for a complex
step that would clutter the main Scenario or
for steps that are repeated in several use cases
• Don’t try to break down use cases into sub-
use cases using functional decomposition
Use Case Text
Use Case Diagram
 UML first pass: Use case diagrams
Package Use case
Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

Use case diagrams represent the functionality of the system

from user’s point of view
 Use Case Diagrams
• Used during requirements
elicitation to represent external
behavior

• Actors represent roles, that is, a

Passenger 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
PurchaseTicket
the system and its environment
 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
Passenger
description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates
 Use Case
A use case represents a class of
functionality provided by the system as
an event flow.

A use case consists of:

PurchaseTicket • Unique name
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
 Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the number
Participating actor: Passenger of zones to be traveled.
2. Distributor displays the amount
Entry condition: due.
• Passenger standing in front of 3. Passenger inserts money, of at
ticket distributor. least the amount due.
• Passenger has sufficient 4. Distributor returns change.
money to purchase ticket. 5. Distributor issues ticket.

Exit condition:
• Passenger has ticket.
Anything missing?

Exceptional cases!
 The <<extends>> Relationship
• <<extends>> relationships
represent exceptional or seldom
invoked cases.
Passenger • The exceptional event flows are
factored out of the main event
flow for clarity.
• Use cases representing
PurchaseTicket exceptional flows can extend
more than one use case.
<<extends>> • The direction of a <<extends>>
relationship is to the extended
<<extends>>
use case
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
 The <<includes>> Relationship
• <<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
• <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard
because it is an exception.
PurchaseSingleTicket • The direction of a <<includes>>
<<includes>> relationship is to the using use
<<includes>> case (unlike <<extends>>
relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
 Use Case Diagrams: Summary
• Use case diagrams represent external
behavior
• Use case diagrams are useful as an index into
the use cases
• Use case descriptions provide meat of model,
not the use case diagrams.
• All use cases need to be described for the
model to be useful.
 Use case modeling
• Use cases were developed originally to support
requirements elicitation and now incorporated into
the UML.
• Each use case represents a discrete task that
involves external interaction with a system.
• Actors in a use case may be people or other
systems.
• Represented diagramatically to provide an overview
of the use case and in a more detailed textual form.

Chapter 5 System modeling 18

 Transfer-data use case
• A use case in the MHC-PMS

Chapter 5 System modeling 19

Tabular description of the ‘Transfer data’
use-case
MHC-PMS: Transfer data
Actors Medical receptionist, patient records system (PRS)
Description A receptionist may transfer data from the MHC-PMS to a
general patient record database that is maintained by a
health authority. The information transferred may either
be updated personal information (address, phone
number, etc.) or a summary of the patient’s diagnosis
and treatment.
Data Patient’s personal information, treatment summary
Stimulus User command issued by medical receptionist
Response Confirmation that PRS has been updated
Comments The receptionist must have appropriate security
permissions to access the patient information and the
PRS.

Chapter 5 System modeling 20

Use cases in the MHC-PMS involving the role
‘Medical Receptionist’

Chapter 5 System modeling 21

 Sequence diagrams
• Sequence diagrams are part of the UML and are used to
model the interactions between the actors and the
objects within a system.
• A sequence diagram shows the sequence of interactions
that take place during a particular use case or use case
instance.
• The objects and actors involved are listed along the top of
the diagram, with a dotted line drawn vertically from
these.
• Interactions between objects are indicated by annotated
arrows.
Chapter 5 System modeling 22
 UML sequence diagrams
• sequence diagram: an "interaction diagram"
that models a single scenario executing in the
system
– perhaps 2nd most used UML diagram (behind
class diagram)
• Sequence diagram shows objects and the
messages that are passed between these objects
within the usecase.

23
 Key parts of a sequence diag.
• participant: an object or entity that acts in the
sequence diagram
– sequence diagram starts with an unattached "found
message" arrow

• message: communication between participant

objects

• the axes in a sequence diagram:

– horizontal: which object/participant is acting
– vertical: time (down -> forward in time)
24
Sequence Diagram For Centralized Control
 Sequence Diagram for Distributed Control

By distributing control, more opportunities for using polymorphism

rather than using conditional logic will be created
 Representing objects
• squares with object type, optionally preceded
by object name and colon
– write object's name if it clarifies the diagram
– object's "life line" represented by dashed vert. line

27
 Messages between objects
• message (method call) indicated by horizontal arrow
to other object
– write message name and arguments above arrow

– dashed arrow back indicates return

– different arrowheads for normal / concurrent
(asynchronous) methods

28
 Lifetime of objects
• creation: arrow with
'new' written above it
– notice that an object
created after the start of
the scenario appears
lower than the others

• deletion: an X at bottom
of object's lifeline
– Java doesn't explicitly
delete objects; they fall
out of scope and are
garbage-collected
29
 Indicating method calls
• activation: thick box over object's life line; drawn when object's method is on the
stack
– either that object is running its code, or it is on the stack waiting for another
object's method to finish
– nest to indicate recursion

Activation

Nesting

30
 Indicating selection and loops
• frame: box around part of a sequence diagram to indicate selection or loop
– if -> (opt) [condition]
– if/else -> (alt) [condition], separated by horiz. dashed line
– loop -> (loop) [condition or items to loop over]

opt [balance
<>0] alt [balance
< 100.00]

[balance>= 100.00]

loop [balance
< 0]

31
 linking sequence diagrams
• if one sequence diagram is too large or refers to
another diagram, indicate it with either:
– an unfinished arrow and comment
– a "ref" frame that names the other diagram
– when would this occur in our system?

Customer Info ref

Verify customer credit

Approved?

32
Dependency Key Words
 (De)centralized system control
• What can you say about the control flow of each of
the following systems?
– centralized?
– distributed?

34
Sequence diagram for View patient
information

Chapter 5 System modeling 35

Sequence diagram for Transfer Data

Chapter 5 System modeling 36

 Structural models
• Structural models of software display the organization
of a system in terms of the components that make up
that system and their relationships.
• Structural models may be static models, which show
the structure of the system design, or dynamic
models, which show the organization of the system
when it is executing.
• You create structural models of a system when you are
discussing and designing the system architecture.

Chapter 5 System modeling 37

 Class diagrams
• Class diagrams are used when developing an object-
oriented system model to show the classes in a system and
the associations between these classes.
• An object class can be thought of as a general definition of
one kind of system object.
• An association is a link between classes that indicates that
there is some relationship between these classes.
• When you are developing models during the early stages
of the software engineering process, objects represent
something in the real world, such as a patient, a
prescription, doctor, etc.
Chapter 5 System modeling 38
UML classes and association

Chapter 5 System modeling 39

Classes and associations in the MHC-PMS

Chapter 5 System modeling 40

The Consultation class

Chapter 5 System modeling 41

 Generalization
• Generalization is an everyday technique that we use
to manage complexity.
• Rather than learn the detailed characteristics of
every entity that we experience, we place these
entities in more general classes (animals, cars,
houses, etc.) and learn the characteristics of these
classes.
• This allows us to infer that different members of
these classes have some common characteristics
e.g. squirrels and rats are rodents.
Chapter 5 System modeling 42
 Generalization
• In modeling systems, it is often useful to examine the classes in a
system to see if there is scope for generalization. If changes are
proposed, then you do not have to look at all classes in the system to
see if they are affected by the change.
• In object-oriented languages, such as Java, generalization is
implemented using the class inheritance mechanisms built into the
language.
• In a generalization, the attributes and operations associated with
higher-level classes are also associated with the lower-level classes.
• The lower-level classes are subclasses inherit the attributes and
operations from their superclasses. These lower-level classes then add
more specific attributes and operations.

Chapter 5 System modeling 43

A generalization hierarchy

Chapter 5 System modeling 44

A generalization hierarchy with added
detail

Chapter 5 System modeling 45

 Object class aggregation models
• An aggregation model shows how classes that
are collections are composed of other classes.
• Aggregation models are similar to the part-of
relationship in semantic data models.

Chapter 5 System modeling 46

The aggregation association

Chapter 5 System modeling 47

Properties
• Properties represent structural features of a Class.
Properties are a single concept, but they appear in
two quite distinct notations: attributes and
associations.
Attributes
• The attribute notation describes a property as a line
of text within the class box itself
Associations
• The other way to notate a property is as an
association . Much of the same information that you
can show an attribute appears on an association
Association/Multiplicity
 Notes and Comments

• Notes are comments in the diagrams . Notes

can stand on their own, or they can be linked
with a dashed line to the elements they are
commenting
 Object class identification
• Identifying object classes is often a difficult
part of object oriented design.
• There is no 'magic formula' for object
identification. It relies on the skill, experience
and domain knowledge of system designers.
• Object identification is an iterative process.
You are unlikely to get it right first time.

Chapter 7 Design and implementation 52

 Approaches to identification
• Use a grammatical approach based on a natural language
description of the system (used in Hood OOD method).
• Base the identification on tangible things in the application
domain.
• Use a behavioural approach and identify objects based on
what participates in what behaviour.
• Use a scenario-based analysis. The objects, attributes and
methods in each scenario are identified.

Chapter 7 Design and implementation 53

 Weather station description

A weather station is a package of software controlled instruments

which collects data, performs some data processing and transmits
this data for further processing. The instruments include air and
ground thermometers, an anemometer, a wind vane, a barometer
and a rain gauge. Data is collected periodically.

When a command is issued to transmit the weather data, the

weather station processes and summarises the collected data.
The summarised data is transmitted to the mapping computer
when a request is received.

Chapter 7 Design and implementation 54

 Weather station object classes
• Object class identification in the weather station system may
be based on the tangible hardware and data in
the system:
– Ground thermometer, Anemometer, Barometer
• Application domain objects that are ‘hardware’ objects related to the
instruments in the system.
– Weather station
• The basic interface of the weather station to its environment. It therefore
reflects the interactions identified in the use-case model.
– Weather data
• Encapsulates the summarized data from the instruments.

Chapter 7 Design and implementation 55

Weather station object classes

Chapter 7 Design and implementation 56

 Design models
• Design models show the objects and object
classes and relationships between these
entities.
• Static models describe the static structure of
the system in terms of object classes and
relationships.
• Dynamic models describe the dynamic
interactions between objects.

Chapter 7 Design and implementation 57

 Behavioral models
• Behavioral models are models of the dynamic
behavior of a system as it is executing. They show
what happens or what is supposed to happen when a
system responds to a stimulus from its environment.
• You can think of these stimuli as being of two types:
– Data Some data arrives that has to be processed by the
system.
– Events Some event happens that triggers system
processing. Events may have associated data, although this
is not always the case.

Chapter 5 System modeling 58

 Data-driven modeling
• Many business systems are data-processing systems
that are primarily driven by data. They are
controlled by the data input to the system, with
relatively little external event processing.
• Data-driven models show the sequence of actions
involved in processing input data and generating an
associated output.
• They are particularly useful during the analysis of
requirements as they can be used to show end-to-
end processing in a system.
Chapter 5 System modeling 59
An activity model of the insulin pump’s
operation

Chapter 5 System modeling 60

Order processing

Chapter 5 System modeling 61

 Event-driven modeling
• Real-time systems are often event-driven, with
minimal data processing. For example, a landline
phone switching system responds to events such
as ‘receiver off hook’ bygenerating a dial tone.
• Event-driven modeling shows how a system
responds to external and internal events.
• It is based on the assumption that a system has a
finite number of states and that events (stimuli)
may cause a transition from one state to another.
Chapter 5 System modeling 62
 State machine models
• These model the behaviour of the system in response to
external and internal events.
• They show the system’s responses to stimuli so are often used
for modelling real-time systems.
• State machine models show system states as nodes and
events as arcs between these nodes. When an event occurs,
the system moves from one state to another.
• Statecharts are an integral part of the UML and are used to
represent state machine models.

Chapter 5 System modeling 63

State diagram of a microwave oven

Chapter 5 System modeling 64

 States and stimuli for the microwave oven
(a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows
the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.

Chapter 5 System modeling 65

States and stimuli for the microwave oven
(b)
Stimulus Description
Half power The user has pressed the half-power button.

Full power The user has pressed the full-power button.

Timer The user has pressed one of the timer buttons.

Number The user has pressed a numeric key.

Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.

Chapter 5 System modeling 66

Microwave oven operation

Chapter 5 System modeling 67

Package Diagram
Package Diagram:
• A package is a grouping construct it allows you to take any
construct and group its elements together into higher-level
units.
• Its most common use is to group classes
• In a UML model, each class is a member of a single package
.
• Packages can also be members of other packages, so it
forms hierarchic structure in which top-level packages get
broken down into subpackages with their own subpackages
and so on until the hierarchy bottoms out in classes .
• A package can contain both subpackages and classes .
• In a UML model, each class is a member of a
single package .
• Packages can also be members of other
packages, so it forms hierarchic structure in
which top-level packages get broken down into
subpackages with their own subpackages and so
on until the hierarchy bottoms out in classes .
• A package can contain both subpackages and
classes .
Implementing Package
Package Relationship:

• A relationship between two packages is called a package

dependency.
• Dependencies are not transitive.
• The dependency relationship between packages is consistent
with the associative relationship between classes.
• Ex. If changing the contents of a package, P2, affects the
contents of another package, P1, we can say that P1 has a
Package Dependency on P2.
Package Relationship:
• Package dependency diagram :
 When TO Use a Package
• Extremely useful for large-scale systems to get
picture of the dependencies between major
elements of a system.
• Theses diagrams helps you keep dependencies
under control
Examples:
Use Case Package Diagram:

Use case Diagram  Use case Package Diagram

Use Case Package Diagram:
Use Case Package Diagram:
 Class Package Diagram

class Diagram  class Package Diagram

 Deployment Diagram
• Deployment Diagram shows the physical
layout.
• It reveals which piece of software runs on
what part of hardware.
• Node (hardware) hosts artifacts(software).
• Communication paths between nodes indicate
how things communicate
Deployment Diagram