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)
