Chapter 3

Modeling with Unified

Modeling Language
A Deeper View of UML

Learning Outcome

Describe

fundamental notations of UML

and its basic semantics

Construct UML diagrams.

UML Diagrams:
Outline of this Class

Use case diagrams

 Describe the functional behavior of the system as seen by the
user
Interaction diagrams
 Describe the dynamic behavior between objects of the system
Activity diagrams
 Describe the dynamic behavior of a system, in particular the
workflow.
Class diagrams
 Describe the static structure of the system: Objects, attributes,
associations
Statechart /State Machine diagrams
 Describe the dynamic behavior of an individual object

Another view on UML

Diagrams
Used to show the static structure
of elements in the system (e.g.,
architectural organization, physical
elements of the system)

To express the dynamic behavioral

semantics of a problem or its
implementation

Another view on UML

Diagrams

Use Case Diagrams

Use Case Modeling

A use case model presents the required
interactions between the system and its
users

Consists of a diagram showing which users
participate in which use cases as well as a
narrative of the expected response of the
system as each use case unfolds

Use Case Diagram

A use case is a set of scenarios that
describing an interaction between a user
and a system.

displays the relationship among two main
components actors and use cases

allows us to make a first cut at defining the
system requirements, and will help us in
presenting these requirements back to the
users of the system

Use Case Diagram

Used during requirements elicitation and analysis to represent
behavior visible from an external point of view
An actor represents a role, a user or another system that will
interact with the system you are modeling

A use case represents a class of functionality provided by the

system or action the user might perform in order to complete
a task
Use case model: The set of all use cases that completely
describe the functionality of the system.

Use Case

DoHomework

A use case represents a class of

functionality provided by the
system
Use cases can be described
textually, with a focus on the event
flow between actor and system
The textual use case description
consists of 6 parts:







Unique name
Participating actors
Entry conditions
Exit conditions
Flow of events
Special requirements.

Actor

An actor is a model for an external

entity which interacts with the
system:




Student

An actor has a unique name and an

optional description
Optional
Examples:
Description


Name

EndUser, Administrator
External system (Another system)
Physical environment (e.g. Weather)

Student: A studying person

Teaching Assistant: Member of
teaching staff who supports the
instructor.
Random Number generator

Use Case Diagram: An Example

Classifier

Use Case

Actor.

System boundary

Use case diagrams represent the functionality of the system

from users point of view

Use Case Diagram: Online

HR System

condition

13

When to use Use Case

Diagram?
They are helpful in exposing requirements
and planning the project.

During the initial stage of a project most use
cases should be defined, but as the project
continues more might become visible.

14

Uses Cases can be related

Extend Relationship


To represent seldom invoked use cases or

exceptional functionality

Include Relationship


To represent functional behavior common

to more than one use case.

What Is a Relationship?

An association between an actor and a use

case

Depicts a usage relationship

Relationship does not indicate data flow

16

What Is an <<include>>
Relationship?

A connection between two use cases

<<include>> relationship is used to include
behavior that is factored out of the use case for
reuse
<<include>> behavior used to share helpful
behavior among use cases
The direction of a <<include>> relationship is
from the base use case to the using (supplier)
use case
Base use case cannot run independently
17

The <<include>> Relationship

DoHomework

Student
HoldExercise

GiveLecture
<<include>>
<<include>>

<<extend>>

AskQuestion
<<extend>>

NoAnswer

<<include>> relationship
represents common
functionality needed in more
than one use case
The direction of a
<<include>> relationship
is to the using use case
(unlike the direction of the
<<extend>> relationship).

<<extend>>

WrongAnswer SillyQuestion

19

What Is an <<extend>>
Relationship?

<<extend>> relationship is used to extend a use case

by exceptional, optional or seldom invoked cases.
Extension points may be defined in the base use case.
Condition must be specified when the extending use
case will be inserted
The direction of a <<extend>> relationship is from the
extending (supplier) use case to the extended (base) use
case
Base use case can run independently

20

The <<extend>> Relationship

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

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

Student

DoHomework

<<extend>>

Party
<<extend>>
<<extend>>

<<extend>>

Sleep

FetchLostSheet
DrinkCoffee

22

Include vs. Extend

Use <<extend>> if you want to model an

extension to, or a variation of, a complete
use case that exists in its own right

Use <<include>> if you want to factor the

common behavior among two or more use
cases into a single generalized use case

23

Use Case Narratives

textual use case description

presenting the sequence of internal actions by which
the system responds to the actions of an actor
first, describing the expected system response when
all goes well, then, may be modified later to describe
exceptions and how errors in a system input are
handled
Flow of events expanded use case narrative,
shows in sequence of actions of an actor and the
corresponding responses of the system
24

Textual Use Case

Description Example
1. Name: DoHomework
2. Participating actor: Student
3. Entry condition:

Student received exercise
sheet

Student is in good health
4. Exit condition:

Student delivered solution

Student

5. Flow of events:

DoHomework

1. Student fetches the exercise

sheet
2. Student reads through the
assignments
3. Student processes the
assignments and types the
solution in his Computer.
4. Student prints out the solution
5. Student delivers the solution
in the following exercise

6. Special requirements:
None.

Use Case Diagram An

Example

University Registration System

Identify business events system behavior

Event list for the university registration system

1. Department submits class schedule
2. Time to produce university class schedule
3. Student registers for classes
4. Time to produce class roster

27

University Registration System

Identify the actors



Who supplies the system with inputs or receive

outputs from the system

Identify the system Inputs and Outputs

Event

Input

Actor (provide
input)

Department submits
class schedule

Department Class
schedule

Department

Time to produce class

schedule

Student registers for

classes

Time to produce class

roster

Registration request

Student

Output

Actor (receive output)

University
class
schedule

Student Department
Lecturer

Student class
list

Student

Class roster

Lecturer

28

University Registration System:

Events and Use Cases

Each event corresponds to one or more use cases

The role of the use case is to respond to the event by
providing services to users of the system
Each use case may be viewed as a requirement for a
process which will eventually be turned into a piece of
software
Events

Use Cases

1.

Department submits class schedule

Submit Department
Class Schedule

2.

Time to produce university class schedule

Produce University
Class Schedule

3.

Student registers for classes

Register for Classes

4.

Time to produce class roster

Produce Class Roster

29

University Registration System:

Use Case Diagram
REGISTRATION SYSTEM

Submit Department
Class Schedule

Department

Produce University
Class Schedule

Lecturer
Register for
Classes

Student

Produce
Class Roster

30

Flow of Events
an example
Use Case:
Actors:
1.
2.
3.
4.
5.
6.

Register for Classes

Student

This use case begins when a Student desires to register for

classes
The student provides the students identifier and a list of the
code, course number, and section number for each section desired
Adds the student to the section if there are seats available
On completion of entry of the section requests, the student indicates
that the request is complete
Produces a student class list for the student
The student receives the student class list

Alternative Flow of Events

Invalid department code and course number entered. Indicate error.

Return to Step 2

Invalid section number entered. Indicate error. Return to Step 2

No seats remaining. Inform the student. Return to Step 2

31

Flow of Events an
example
Use Case:
Actors:
1.
2.

3.
4.

Submit Department Class Schedule

Department

This use case begins when a department submits its schedule for
a term
The department provides the department code, course number,
section number, maximum number of seats, meeting time, meeting
place and instructor identifier for each section in the schedule
Records the section schedule information
On completion of entry of the schedule, the department indicates
that the schedule is complete

Alternative Flow of Events

Invalid department code and course number entered. Indicate error.

Return to Step 2

Invalid meeting place entered. Indicate error. Return to Step 2

Invalid meeting time entered. Indicate error. Return to Step 2

Invalid instructor identifier entered. Indicate error. Return to Step 2

32

Flow of Events an
example
Use Case:
Actors:
1.
2.

Produce Class Roster

Lecturer

This use case begins when it is time to produce the class rosters for
a term
Produces and displays the class rosters

33

Interaction Diagrams

34

UML Dynamic Modeling

In all systems, events happen dynamically,

e.g.:
Objects are created and destroyed
 Objects send messages to one another
 External events trigger operations on certain
objects


Objects have states that would be difficult to

capture in a static model
35

UML Dynamic Modeling

(cont.)

Behavior diagrams (dynamic):



Interaction diagrams
Sequence diagrams
Collaboration diagrams

Statechart diagrams
 Activity diagrams


36

Model interactions between objects/classes

Assist in understanding how a use case
actually works

Verify that a use case description can be
supported by the existing classes

Identify methods/operations and assign them
to classes

37

When to use Interaction

Diagrams?

Interaction diagrams are used when you want to

model the behavior of several objects in a use
case. They demonstrate how the objects
collaborate for the behavior.
Interaction diagrams do not give a in depth
representation of the behavior. If you want to see
what a specific object is doing for several use
cases use a state diagram. To see a particular
behavior over many use cases or threads use an
activity diagrams.
38

Interaction Diagrams:
Sequence Diagram

Describing the behavior of a system by viewing

the interaction between the system and its
environment
Shows the objects participating in the
interaction by their life lines and the messages
they exchange
Shows an interaction arranged in a time
sequence
focuses on the message interchange between
lifelines (objects)
39

Elements of a sequence diagram

Objects: represented by boxes at top of

diagram.


Syntax: [objectName]:[className]

Include object (instance) names when objects are referred to

in messages or when several objects of the same type exist
in the diagram

Lifeline: the time during which an object exists




represents the lifetime of the participant (or

object)
represents an individual participant in the
interaction
40

Elements of a sequence diagram

Messages



means by which objects communicate with

each other
define a particular communication between
lifelines of an interaction

Activation or execution specification:




the time period during which an object

performs an operation
specifies a behavior or interaction within the
lifeline
41

Sequence diagram: Basic Notation

Lifeline

Activation

Message

Sequence diagrams represent the behavior of a system

as messages (interactions) between different objects.

Interaction Diagrams:
Communication Diagrams
Also known as collaboration diagrams

Represents a collaboration, which is a set of
objects related in a particular context, and
interaction, which is a set of messages
exchanged among the objects within the
collaboration to achieve a desired outcome

sequences of messages are shown by
numbering

43

Communication Diagrams
1: insert ATM card
3: enter PIN code
7: enter amount

:ATMMachine
:Client
2: request PIN
6: request amount
10: dispense cash
11: print receipt

4: verify PIN code

8: process transaction

5: valid PIN code

9: transaction successful

:SavingAccount

44

UML Communication diagram: An

Example

45

Sequence Vs Communication

Sequence Diagram:
 Dynamic behavior of a set of objects arranged in
time sequence, new objects added to the right
 Good for real-time specifications and complex
scenarios
 easier to read
Communication Diagram :
 Shows the relationship among objects.
 Does not show time
 Objects are arranged in a graph or network format
Both are used to examine the behavior of objects within
a single use case
46

Drawing Interaction
Diagram use case driven

47

Step 1: Identifying Classes/Objects

Noun phrase approach read through the
requirements or use cases looking for noun
phrases

Some classes are implicit or taken from
general knowledge

Carefully choose and define class names

48

Use Case: Withdraw saving

A customer wants to draw money from his bank account.
He enters his card into an ATM (automated teller machine).
The ATM machine prompts Enter PIN. The customer
enters his PIN. The ATM (internally) retrieves the bank
account number from the card. The ATM encrypts the PIN
and the account number and sends it over to the bank. The
bank verifies the encrypted account and PIN number. If the
PIN number is correct, the ATM displays, Enter Amount.
Draws money from the bank account and pays out the
amount.

49

Use Case: Withdraw saving

Use Case:
Actors:

Withdraw Saving
Bank Client

Flow of Events:
1. Bank client insert ATM card into ATM machine
2. ATM machine request PIN code
3. Bank client enter PIN code
4. Verify PIN code entered with saving account
5. ATM machine request amount if the PIN is valid
6. Bank client enter the required amount
7. Process the transaction in the client account
8. ATM machine dispense cash
9. ATM machine print receipt when the transaction completed
Alternative Flow of Events

Invalid PIN code entered. Indicate error message. Return step 3.

50

Step 1: Identifying Classes

noun phrase approach (example)

Use Case: Withdraw Saving

Bank Client
 ATM Card
 ATM Machine
 Savings Account
 Cash
 Message


51

Step 2
 Set of the lifeline for each object
 Lay out of messages from the top to the
bottom of the diagram based on the order
in which they sent
 Add the execution occurrence to each
objects lifeline
 Validate the sequence diagram

52

ATMMachine

Client

SavingAccount

Insert ATM card

Request PIN
Enter PIN code
Verify PIN code
PIN valid
Request amount
Enter amount
Process transaction
Transaction successful
Dispense cash
Print receipt

53

:OrderForm

:Customer

:Order

:Customer
addOrderForCustomer()
addOrder()
add()

Stereotypes Classes

Classes can be classified into three stereotypes:

entity, boundary, or control
Entity class objects that hold most of the data of an
application
Boundary class used by actors to interact with the
system (e.g., forms, dialog boxes, menus, screens),
also can serve to establish communication with
another system
Control class coordinates the tasks and captures
the main application logic in a use case. Act as
controller and as enforcer of business rules and
policies
55

Stereotypes Classes (cont.)

Mostly corresponds to
conceptual data model
classes

Encapsulates connections
between actors and use
cases

Mostly performs behaviors

associated with inner
workings of use cases

56

Typically, actors
interact with boundary
classes, which in turn
interact with control
classes, which in turn
interact with entity
classes.

57

58

UML Diagrams:
Outline of this Class


Use case diagrams

 Describe the functional behavior of the system as seen by the
user
Interaction diagrams
 Describe the dynamic behavior between objects of the system
Activity diagrams
 Describe the dynamic behavior of a system, in particular the
workflow.
Class diagrams
 Describe the static structure of the system: Objects, attributes,
associations
Statechart /State Machine diagrams
 Describe the dynamic behavior of an individual object

Summary
Use Case diagrams represent
external behavior (and internal
functionality)

Use Cases consist of diagrams and
textual description (of behavior,
actors, entry conditions, etc.)

Use Cases are needed to discuss the
systems functionality with users

Summary
UML interaction diagrams represent
behavior in terms of interactions

Useful to find missing objects

Time consuming to build but worth the
investment

Complement the class diagrams
(which represent structure)

References
Bruegge and Dutoit (2010)

Bennett, McRobb and Farmer (2010)

George, Batra, Valacich and Hoffer
(2007)