Unified Modeling Language (UML)

• Created by Grady Booch, Jim Rumbaugh

& Jacobson - 1994
• The Unified Modeling Language is a
visual language for specifying,
constructing and documenting a system
– Visual: diagram
• 3 perspectives of using UML
– Conceptual or informal and incomplete
– Specification or detailed design or blueprint
– Implementation specific or programming
language
Unified Modeling Language (UML)
Categories of Diagrams
• Structural
– Use Cases, Class diagrams, Object diagrams,
Collaboration diagrams
• Behavioral
– Sequence diagrams, State diagrams, Activity
diagrams
• Grouping
– Package diagrams, Component diagrams,
Deployment diagrams
 Use Cases
• Use Cases are text stories to discover and
record requirements
• Use Cases are requirements, primarily
functional or behavior to describe what the
system will do
• They emphasize the user goals and
perspectives
• Owing to their simplicity, Customers can
write (or participate in writing) the Use
Cases
 Use Cases
• Actor: something with behaviour, such as a
person, computer system, or organization
e.g. a cashier.
• Scenario: specific sequence of actions and
interactions between actors and the system
under discussion
e.g. the scenario of successful purchase of items with
cash
• Use case: a collection of related success and
failure scenarios that describe actors using a
system to support a goal.
 Actors
• Primary Actor: has user goals for the SuD
(System under Discussion)
e.g. a cashier.
• Supporting Actor: provides a service (eg.
Information) to the SuD
e.g. a credit card payment authorization
• Offstage Actor: has an interest in the behavior
of the use case (not primary or supportive)
e.g. a Government tax agency
 Use Case formats
• Brief: Terse one paragraph summary

e.g. A customer arrives at a checkout with items to

purchase. The cashier uses the POS system to
record each purchased item, present line-item details
and a running total. The customer enters payment
information and system will validate and record the
sale. System updates the inventory.
 Use Case formats
• Casual: provides more details handling some
failure modes
e.g. Handle returns
Main success scenario: A Customer arrives at a
checkout with items to return. The Cashier uses the
POS system to record each returned item…
Alternate scenarios:
If the credit authorization is reject, inform Customer
and ask for an alternative payment method.
If item identifier not found in the system, notify the
Cashier and suggest manual entry of the identifier
code
 Use Case formats
• Fully Dressed: elaborate. All steps and
variations are written in detail, with preconditions
and postconditions
e.g. - Use case UC1: Process Sale
(Start with verb)
Primary Actor: Cashier
Stakeholders and Interests:
-Cashier: Wants accurate and fast entry, no payment
errors, …
-Salesperson: Wants sales commissions updated.
…..Customer, Manager, Company, Credit agency,
Tax agency…..
Use case UC1: Process Sale contd
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions):
-Sale is saved. Tax correctly calculated.
… Receipt generated, Inventory, Commission updated
Main success scenario (or basic flow): [see next slide]
Extensions (or alternative flows): [see next slide]
Special requirements: Touch screen UI, robust recovery,
Technology and Data Variations List:
-Identifier entered by bar code scanner,…
Open issues: What are the tax law variations? …
Use case UC1: Process Sale contd
• Main success scenario (or basic flow):
– The Customer arrives at a POS checkout with items
to purchase.
– The cashier records the identifier for each item. If
there is more than one of the same item, the Cashier
can enter the quantity as well.
– The system determines the item price and adds the
item information to the running sales transaction. The
description and the price of the current item are
presented.
– On completion of item entry, the Cashier indicates to
the POS system that item entry is complete.
Use case UC1: Process Sale contd
• Main success scenario (or basic flow): contd
– On completion of item entry, the Cashier indicates to
the POS system that item entry is complete.
– The System calculates and presents the sale total.
– The Cashier tells the customer the total.
– The Customer gives a cash payment (“cash
tendered”) possibly greater than the sale total.

• Extensions (or alternative flows):

– If invalid identifier entered. Indicate error.
– If customer didn’t have enough cash, cancel sales
transaction.
 Goals and Scope of a Use Case
• At what level and scope should use cases be
expressed?
– A: Focus on uses cases at the level of elementary
business process (EBP).
• EBP: a task performed by one person in one place at
one time which adds measurable business value and
leaves the data in a consistent state.
– Approve credit order - OK.
– Negotiate a supplier contract - not OK.
• It is usually useful to create separate “sub” use cases
representing subtasks within a base use case.
– e.g. Paying by credit card
 Finding primary actors, goals and
use cases
• Choose the system boundary
• Identify primary actors
– Those that have user goals fulfilled through using
services of the system
• For each actor identify their user goals
– Tabulate findings in the Vision artifact (next slide)
• Define use cases that satisfy user goals: name them
according to their goal
 Vision Artifact
Actor Goal Actor Goal
Cashier Process sales System Add users
Handle returns Administrator Modify users
Cash in Delete users
Cash out Manage security
---- Manage system
tables
----

Manager Start up Sales Activity Analyze sales &

Start down System performance data
 Use Case Diagram
system boundary NextGen POS communication

Process Sale alternate
notation for 
Customer a computer 
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System 

Manage Security

System Manage Users
Administrator use case
. . .
 Domain Model
• Domain Model
– Most important classic model in OO Analysis
(Business Object Model)
– Illustrates meaningful concepts in the problem domain
– Representation of real-world things (Concepts), not
software components
– It is a set of static structure diagrams, containing all
the important players (No operations are defined)
– It may show:
• Concepts
• Associations
• Attributes
 Domain Model
• A Domain Model is
Item a description of
things in the real
world
*
Stocked-in • A Domain Model is
not a description of
1 the software design
Store
Address • A concept is an
Name idea, thing, or
object.
 Domain Model
• Visualization of things in the Domain
– Visual dictionary
– A picture of Business Objects, not of software objects
– Does not contain responsibilities or methods
– Is not a data model
– Why Domain Model

Usecase Domain Design

Model Model Model
 Package Diagrams
• Used to illustrate the Logical Architecture
• Package name placed in the main folder or if
inner members shown on the tab
• Dependency between packages shown by
dashed lines

UI Domain

Swing Web Sales

 Object Model
• Dynamic Object Models
– Interaction Diagrams (Sequence Diagrams and
Communication Diagrams) help design logic, behavior
of code and methods
– Most important since they clarify exact details of what
objects need to exist and how they collaborate via
messages and methods
• Static Object Models
– Design Class Models
– Package Diagrams and Deployment Diagrams
 Sequence Diagrams
Sequence diagrams
• illustrate
:ClassAInstance :ClassBInstance interactions in a
kind of fence
format with a flow
Message1()
sequence
• Set of all operation
Message2()
contracts defines
system behaviour
Message3() • Consumes
horizontal space
 Communication Diagrams
Message1() • Communication
diagrams
:ClassAInstance • illustrate how
objects interact via
Message2() messages
Message3() • compact

:ClassBInstance
• Collaboration
diagrams
• illustrate object
interactions in a
graph or network
format
 Sequence Diagrams
• Lifeline boxes and
vertical lifelines
:Register :Sale • Activation bar for
focus of control
• Messages – time
NewSale()
makeSale() organized
• Reply messages
total()
• Self messages
• Create & destroy

createPayment()
:Payment
clear
destroy()
X
 Loops
• loop – with condition
• opt – optional on
:A :B condition
• alt – alternate on
makeNewSale()
condition
loop enterItem() • par – parallel
[more] descTotal() • region – critical with
only one thread

alt
[x<10]
calculateA()

[else] calculateB()
 Class Diagrams
• Created in design, it is a diagram showing classes, their
innards, and the associations between them
• It is a final version of a conceptual diagram; A class
diagram differs from a Domain Model by showing
software entities rather than realworld concepts
(Class diagrams in Design are referred to as DCD or
Design Class Diagrams)
• Once the interaction diagrams have been completed it is
possible to identify the specification for the software
classes and interfaces
 Design Model Classes
• Innards of a Class
– Class Name
– Attributes Sale
– Methods
date : Date
• The attribute must contain its class isComplete : Boolean
or data type time

• The method must contain the class total() : Currency

or data type of its return variable
Relationships between Classes
• Relationships in a class diagram
– Aggregation
(Whole part relationships)
– Inheritance
(Derived or child classes)
– Association
(Link two classes)
 Aggregation
• Aggregation Sale
expresses
date : Date
container
classes
total() : Currency

Payment

amount : Currency
 Inheritance
• Inheritance Payment
allows reuse
amount : Currency

CreditPayment CashPayment

creditCardNumber : int
amountTendered :
expirationDate : Date
Currency
 Associations
• There can be many kind of associations
• They all link two classes
• Role names are assigned
• Their purpose is to indicate visibility

Register Sale

Date
isComplete:Boolean
1 Captures 1
time
addLineItem(…)
…… makeLineItem(..)
 Influence of Interaction Diagrams
on Class Diagrams
:Register :Sale

makeSale()

• Classes identified in Interaction diagrams are declared

in the class diagrams
• Messages in Interaction Diagrams indicate methods in
nthe Class Diagrams
Register Sale

currentSale 1
makePayment(…)
…… makePayment(..)
 Finding Associations –Common
Associations List
Category
A is a physical/logical part of B
A is physically contained in/on B
A is logically contained in B
A is a description of B
A is a line item of a transaction
or report B
A is known/logged/recorded/
captured in B
A is a member of B
...
Examples
SalesLineItem - Sale
POS - Store
ItemDescription - catalog
ItemDescription - Item
SalesLineItem - Sale
Sale - POS
Cashier - Store
* High-priority associations
 Multiplicity
• Multiplicity defines
POS Stocks Sale how many instances of
1 * a type A can be
associated with one
T instance of a type B, at
* a particular moment in
time
T T
5 • For example, a single
1..*
instance of a Store can
T T be associated with
1..40 3,5,8 “many” (zero or more)
Item instances
 Naming Associations
• Name an association based
on a TypeName-VerbPhrase-
Store
TypeName format
• Association names should
1
start with a capital letter
Contains
• A verb phrase should be
1..* constructed with hyphens
• The default direction to read
POS
an association name is left to
1 right, or top to bottom.
Captures
1..*
Paid-by
Sale CreditCard
1 1
Multiple Associations Between Two
Types
• It is not uncommon to have multiple associations
between two types

• In the example, not every flight is guaranteed to land at

an airport.

Flies-to 0..1
*
Flight Air[port
Flies-from
* 1
 Attributes
• An attribute is a logical data value of an object
• Include the following attributes: those for which the
requirements suggest or imply a need to remember
information.
• For example, a Sales receipt normally includes a date
and time
• The Sale concept would need a date and time attribute

Sale

date
time
 Valid Attribute Types
• Keep attributes simple
• The type of an attribute should not normally be a complex
domain concept, such as Sale or Airport
• Attributes in a Domain Model should preferably be:
o Pure data values: Boolean, Date, Number, String, …
o Simple attributes: color, phone number, zip code,
universal product code (UPC), ...

Cashier Cashier Register

name name uses Number

currentRegister

Invalid – not
simple attribute
 NextGen POS Domain Model
Records­sale­of 

Product
Ledger Product Description
Catalog Contains
1 itemID
1..*
description
1 1
1 price
0..1 Records­
Used­by Describes
accounts­
Sales for * *
LineItem Store
Item
Stocks
quantity 1 name
address
1
* 1..*
1..*
1
Contained­in Logs­ Houses
1 completed 1..*

Sale * Register

dateTime Captured­on id
0..1 1
/ total
1
1 1
Is­for  Works­on
Paid­by

1 1 1

CashPayment Customer Cashier

amountTendered id
 System Behavior and
System Sequence Diagrams (SSDs)
• A sequence diagram is a picture that shows, for a
particular scenario of a use case, the events that
external actors generate, their order, and possible
inter-system events

• All systems are treated as a black box; the diagram

places emphasis on events that cross the system
boundary from actors to systems
 SSD for a Process Sale scenario
system as black box

the name could be "NextGenPOS" but "System" keeps it 
simple

the ":" and underline imply an instance, and are explained in a 
later chapter on sequence diagram notation in the UML

external actor to  Process Sale Scenario
system

: Cashier :System

makeNewSale

a UML loop  loop [ more items ]

interaction  enterItem(itemID, quantity)
frame, with a 
boolean guard 
expression description, total

endSale a message with  
parameters
return value(s) 
associated with the  it is an abstraction 
previous message total with taxes
representing the 
system event of 
an abstraction that  entering the 
ignores presentation  makePayment(amount)
payment data by 
and medium    some mechanism
the return line is  change due, receipt
optional if nothing is 
returned
 Use Case Diagram
system boundary NextGen POS communication

Process Sale alternate
notation for 
Customer a computer 
Payment system actor
Authorization
Service
Handle Returns
«actor»
actor Tax Calculator
Cashier

«actor»
Cash In Accounting
System
Manager
«actor»
«actor» Analyze Activity
HR System
Sales Activity
System 

Manage Security

System Manage Users
Administrator use case
. . .
 SSDs derived from use cases

Process Sale Scenario
: Cashier :System

makeNewSale
Simple cash­only Process Sale scenario:
loop [ more items ]
1. Customer arrives at a POS checkout  enterItem(itemID, quantity)
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier. description, total
4. System records sale line item and 
presents item description, price, and 
running total. 
Cashier repeats steps 3­4 until indicates 
done. endSale
5. System presents total with taxes 
calculated.
6. Cashier tells Customer the total, and  total with taxes
asks for payment.
7. Customer pays and System handles 
payment. makePayment(amount)
...

change due, receipt
 Naming System Events and
Operations
• The set of all required system operations is
determined by identifying the system events
– makeNewSale()
– addLineItem(itemID, quantity)
– endSale()
– makePayment(amount)
 Choosing events and names

:System
: Cashier
better name
enterItem(itemID, quantity)

scan(itemID, quantity)

worse name