Unified Modeling

Language
UML
Todays lecture
• Introduction to UML
• Object orientation
• Classes and Objects
• Use cases
• UML diagrams
• Requirement specification
• Analysis

2
 What is UML?
• A general object oriented modeling language UML
2.0
2002
OMT
(Rumbaugh et al.)
UML
1996 1.4

Booch UML UML 1999

0.9 1.1
1997

OOSE
(Jacobson et al.)
Catalysis ROOM etc. 3
UML 2.0 Diagrams
Collaboration diagram
Sequence diagram

4
Model of a System with UML
• Requirements
• Specification of black box behavior and characteristics (Requirement
diagram, Use case diagram)
• Behavior
• Transform inputs to outputs (activity based, Activity diagram)
• Performs operations or changes state in response to receipt of a
signal (state based, State chart diagram)
• Providing services in response to a call (message based, Collaboration
diagram, Sequence diagram)
• Structure
• System/component hierarchy, classification and interconnection
(Class diagram, Component diagram, Deployment diagram)
• Properties 5
• Performance and physical characteristics and their inter-relationships
Why do we need a model?
• Understand the problem
• Basis for discussions with the employer
• Basis for discussions with the potential user
• Find errors and inconsistencies (discuss with fellows)
• Code generation
• Limitations from modeling? (always an excerpt, a particular
view, a limited scope)

6
Fundamental OO concepts
• Classes and class hierarchies
• Instances
• Inheritance
• Abstraction
• Objects
• Attributes
• Methods
• Messages

7
Object in software
• Entities that model some physical or conceptual entity
• A unique identity (dedicated memory)
• A public interface
• Attributes
• Operations/methods
• A hidden (encapsulated) implementation

8
The hierarchical directions
from this to that
Unified
that
Language
Modeling
that
Specialization of
Instance of

that Context for this Part of that

Type for
Generalization of
that
9

that
OO development
Requirements
Requirements spec. Analysis -> OO model
Use case Class diagram, Collaboration
diagram, Sequence diagram,
Statechart

Design model
SW/HW
Class diagram, Collaboration
diagram, Statechart
10
Implementation
Deployment, Component diagram
A class: Circle
• What can you do with a circle?
• What characterizes a circle?
• Other similar objects?

11
A class: Circle
• What can you do with a circle?
• Draw
• Fill it
• What characterizes a circle?
• Radius
• Color
• Other similar objects
• Rectangle
• Ellipse

12
A class in UML

Circle
Attribute Colour : integer Type
Radius : integer
Operation/ Draw (x,y,r:integer)
Method Move (x,y:integer)

13
Class notation
• Analysis • Design

14
Important methods in any
class
• Constructor methods - create an object
• Get methods - retrieve value of a field
• Set methods - modify value of a field
• Finalize methods - clean up after object is deleted
• ToString method - return a string describing the object in
some convenient way
• We will use qualifiers for methods and fields to make them
more useful wrt to security and information hiding

15
 Class
• Template, blueprint, generalised description

Base class,
super class, Graphical object
abstraction,
generalisation

Instantiate object from

class (run time)
Subclass Circle
inherits from MyCircle:Circle
base class, 16
specialisation
Class student
• Exercise
• Define a class student

17
 Class Diagram - Associations
association -- a relationship between instances of the
two classes. There is an association between two
classes if an instance of one class must know about the
other in order to perform its work. In a diagram, an
association is a link connecting two classes.
aggregation -- an association in which one class
belongs to a collection.
generalization -- an inheritance link indicating one
class is a superclass of the other.
Multiplicities Meaning
zero or one instance. The notation n . . m indicates n to m
0..1
instances.
0..* or * no limit on the number of instances (including none). 18
1 exactly one instance

1..* at least one instance

Class example
Vehicle
Multiplicity and
naming on
car associations
Association
4
Wheels
Road ”Is part of”
0..2
Extra lights

19
 Class Diagram - Static
Structure
• Shows the entities in a system and their general
relationships association class

client creditor Financial

Person
0..* 0..* Institution
owner 0..*
generalization
association Mortgage
principal
rate Trust
term
Bank
Company
0..*
residence 0..* {ordered} 20
House 1
UML-Class-Stereotype
• Modeling element - extra classification
• Groups objects
• A class can have at most one stereotype
• Common stereotypes:
• Control
• Exception
• Shoved in class name compartment as enclosed in << >>

<<control>>
Manager

21
Modelling a human
• Exercise

• Head
• Left thumb
• Right thumb
• Skeleton part
• Brain
• Mind
• Heart
• Soul
• Body part 22
Conceptual Objects
• Not all objects necessarily require a physical underpinning
• For example, the “telephone call” object:

Telephone1 Telephone2

Telephone Call
Telephone Call Object

abortCall ()
addParty (t:Telephone)
reportDuration () 23
Classes and Instances
• Design-time specifications for one or more distinct objects
with a common form (structure and behavior)
instance
(run time)
class phone1:Telephone
(design time)
busy = true
offHook()
onHook ()
Telephone ring()
phone2:Telephone
busy : boolean
busy = false
offHook()
onHook () offHook()
ring() onHook () 24
ring()
Exercise
• Draw a class diagram for a person who is using a device for a
service
• Hint: Think about Who, when, where, what is done in what way

25
Exercise
Place Home
-Name : string Office
Person
-Name : string Time
-Address:String
-Name : string
-Id:Interger

Service
Device -Type : string
-Type : string
-Id:Interger

26
Mobile Pc
Object oriented view
Message passing
Draw() MyCircle:Circle

Call() Mobile1:telephone
Pelle:person

27
Why use objects?
• “Easy” to describe problem
• Can be used at any abstraction level
• Architecture, hardware, software …
• Reusable
• Can be used for concurrent system
• Cons???

28
How to find classes?
• Object oriented analysis
• Gather and document requirements on the system and
formulate them in a number of interacting objects as the basis
for further work
• Understanding the problem relatively independent of
implementation
• Be able to ask the right questions, give answers
• What the system should NOT do
• When are we done?

29
Goals of (OO)Analysis
• Understand the problem(s) to solve
• Ask questions about the problem and the system
• Provide a basis for answering questions
• Decide what the system should/ should not do
• Make sure that the system will satisfy the needs of its users
• Define acceptance criteria
• Provide a basis for system development

30
Finding the Objects / Classes
• Checklist approach
• Domain analysis
• Linguistic analysis
• Role plays
• Reuse of analysis models
• Experience

31
Checklists
• People
• Places
• Tangible things
• Roles
• Organisations
• Abstract things
• Events
• Interactions
• …

32
Domain Analysis
• Goals
• Identify common objects/classes in a particular problem domain
• Uncover risks
• Done as the need arises
• Methods
• Study similar systems
• Study literature on the domain
• Talk to domain experts
• Build a generic model of the systems in the domain
• Build an operational model (prototype)

33
Usage of CRC Cards
• Working model is needed as input
• Analysis and "verification" through role-playing
• Work through system functions
• Consider responsibilities and collaborations
• Exploration of alternatives
• Easy to use
• Portable
• Supports team
collaboration

34
Linguistic Analysis
• Initial list of candidates using textual analysis:
• Noun phrases => objects / classes
• Verb phrases => methods
• Adjectives => attributes
• ...
• Review analysis results
• Keep only candidates which are meaningful and useful in the
problem domain
• Document results in class diagrams
• Often criticized, but works well for small documents

35
Linguistic Analysis: Review
Candidates
• Eliminate synonyms
• Discard things that are outside the system
• Discard things that describe implementation details
• Most proper names or keys are instances of classes
• Complex noun phrases can describe hidden objects/ classes
• Check for verbs used as nouns
• Look for being (is a) and having verbs (has a)
• Check for property nouns, mass nouns and units of measure

36
Requirement specification
• SMSme is a wireless device where messages can be displayed.
The colour of the device could be red or gold. When a
message arrives the user is notified either by a sound or by a
vibration. The last message sent or received is always
displayed. A constraint is that the display is limited to 4 lines,
20 characters per line.
• A number of ten messages can be stored and if this limit is
reached the device will show a warning message on the
display. Each device can be given a unique name. This name
will be sent back when a message is acknowledged. The user
communicates with SMSme using buttons.

37
Requirement specification
• SMSme is a wireless device where messages can be displayed.
The colour of the device could be red or gold. When a
message arrives the user is notified either by a sound or by a
vibration. The last message sent or received is always
displayed. A constraint is that the display is limited to 4 lines,
20 characters per line
• A number of ten messages can be stored and if this limit is
reached the device will show a warning message on the
display. Each device can be given a unique name. This name
will be sent back when a message is acknowledged. The user
communicates with SMSme using buttons

38
The GSS Case Study
• Gymnastics Scoring System
• Identify classes and objects
• Get initial sources of requirements
• Problem statement (-> linguistic analysis)
• Initial list of use cases (-> define details)
• Existing system (-> check documents)
• Continuously build and review the initial object model (-> class
diagram)

39
The problem statement

40
Linguistic analysis

41
Resulting key classes

42
More linguistic analysis

43
Improved class definition

44
Class diagram

45
What is a "Good" Class
• A single, well-defined abstraction
• Responsibilities can be described briefly and clearly
• Named by a noun or adjective adequately describing the
abstraction
• Data abstraction or abstract machine
• Cohesive interface
• Represents a set of possible run-time objects
• Has state and behavior

46
 Product development

Many different Models

Prototype

HW SW

Takes a lot
of time 47
Implementation
Class Diagram

48
What is a Use Case?
• Definition:
• "A use case is a sequence of transactions performed by a
system, which yields a measurable result of values for a
particular actor."
• "The main purposes of the use case model are to define what
the system should do, and to allow the software engineers
and the customer to agree on this."

49
Model behaviour -> Use cases
• User demands are important, user-oriented
approach preferrable
• Identify users and others that interacts with the
system -> Actor(s)
• Identify what the systems can do for/to actors ->
Use cases
• Information can be used both in analys,
implementation and test of the system
• Scenario - instance of use case
50
Actors
• An Actor is something or someone that interacts with the
system

University:

Professor

Student
UMU web server
Network support

Umeå kommun 51
Use case - Basics
• A Use case is a behavioural pattern of the system, ”Which
needs has an actor?”
• Dialogue between Actor and System

Read info on the web

Student Print article

Do exercise

52
Actors and classes
• These two symbols have the same meaning

• We may want to model an actor internally as an object, for

example:
• The system may need to store data related to an actor
• An external system may interact with our system by means of an
53
object representing it in our system
Finding use cases and actors?
• What functionality does an actor wish to use? Does the actor
need to read, create, write, change? Must the actor be told
something?
• I/O to the system?
• Who are the primary users of a system? Who takes care of
service? Others who are affected by the system?
• What hardware use/uses the system?

54
Example of Course registration

55
A Single Use Case (top-level)
• Register for courses
• Description:
• This use case is initiated by the student. It provides the capability
to create, review, modify, and delete a course schedule for a
specialized semester
• All required billing information is sent to the Billing System
• Actors
• Student, Billing System.
• Notes:
• A student can register for at most 4 courses each semester.

56
Extends and uses

57
Possible problems with use
cases
• Danger of not building an object oriented system
• Focusing only on the use case
• Danger of mistaking design for requirements
• Inefficient system as it only models how the user thinks the
system should work -> need strong design input
• Danger of missing requirements
• Can miss requirements if solely relying on the use cases that each
actor needs

58
Scenario
• Refinement of Use case
• Many scenarios possible for one use case
• Could be phrased as a cartoon or a story
• Scenario = Use case + starting condition + end resultat
• Example from buying milk
• Kalle brings 2 liter milk along, the cashier checks the two
packages one by one, the price 20kr is shown on a display, Kalle
pays using a Visa card and a pin code.
• Pelle brings 2 liter milk along, the dates have expired for the milk,
cashier manually enters 10 kr, price is shown on the display, Pelle
only has 10 kr, he has forgot his pin code, lost his legitimation
• Note that the interactions above can be represented by messages
59
• Record findings in use case diagram
Sequence Diagram
• Captures dynamic behavior (time-oriented)
• Model message flow of control and data
• Illustrates typical scenarios
• A type of interaction diagram

60
Sequence diagram – The basics

61
Sequence diagram – finding
objects
• The Reservation window sends a makeReservation() message
to a HotelChain. The HotelChain then sends a
makeReservation() message to a Hotel. If the Hotel has
available rooms, then it makes a Reservation and a
Confirmation.
• Each vertical dotted line is a lifeline, representing the time
that an object exists. Each arrow is a message call. An arrow
goes from the sender to the top of the activation bar of the
message on the receiver's lifeline. The activation bar
represents the duration of execution of the message.

62
Sequence diagram – finding
objects
• In our diagram, the Hotel issues a self call to determine if a
room is available. If so, then the Hotel creates a Reservation
and a Confirmation. The asterisk on the self call means
iteration (to make sure there is available room for each day of
the stay in the hotel). The expression in square brackets, [ ], is
a condition.
• The diagram has a clarifying note, which is text inside a dog-
eared rectangle. Notes can be put into any kind of UML
diagram.

63
Collaboration diagram

64
Collaboration Diagram - Basics

65
Collaboration Diagram - Usage
• Captures dynamic behavior (message-oriented)
• Built during analysis and design
• Purpose
• Model flow of control/data (messages)
• Illustrate coordination of object structure and control
• Developed by analysts, designers and implementers
• A type of interaction diagram

66
Statechart diagram
• Graphical notation for class behavior
• Describe all possible states and state changes triggered by
external stimuli
• Good tool to describe complex object life cycles
• Good tool to uncover missing state information and behavior

67
Statechart diagram
“top” state
State
Initial
pseudostate top
Trigger/event
Ready

Transition

go/ctr := 0

Done
Final
Action
state
stop
68
Statechart diagram
• Example
• The lift starts at the ground floor. It can move up or down. If
the lift is idle on one floor a time out occurs after a period of
time and the lift moves to the ground floor.
• The lift can only be stopped or switched off when it is on the
ground floor.

69
Statechart diagram

Start/ Go up/
Ground floor Moving up
Arrived/ Go up/
Arrived/
Arrived/ Ground floor Idle
Go down/

Ground floor Time out/

70
Statechart - Usage
• Captures dynamic behavior (event-oriented)
• Built during analysis and design
• Purpose
• Model object lifecycle
• Model reactive objects (user interfaces, devices, etc.)
• Developed by analysts, designers and implementers

71
Why requirements
specification?
• Determine not only what stakeholders want but what they
need
• Building the right product
• Discover a better product
• Shorten delivery time
• Linking development to management

72
Why requirements
specification?
• Common understanding of the demands on the project
• Functionality (of course)
• Constraints on the system (from users, environment)
• Priorities
• Part of the deal between contractors
• Implementation independent referens
• Input for the (object oriented) work to follow (framework)

73
Why not requirements
specification?
• Not enough time
• Is this project worth investing in?
• Too much effort
• Flexible process
• Education
• Reuse methods and results
• Risk of being too formal
• Choose abstraction level
• Bear necessities
• Boring
• Bear necessities
74
 %
R
eq
ui
re
m
en
ts

0
10
20
30
40
50
60
70
80
90
de
fin
Im itio
U pl n
se em
r
ac en
ce ta
pt tio
an n
ce
te
st
Pr in
oj g
ec
Pr t pl
oj an
ec ni
ti ng
de
nt
i fi
ca
tio
D n
ev
el
op
Pr m
en
oj
ec t
ti
ni
“Requirements”

ti a
Sy tio
st n
em
te
st
in
Failure Stages

Pr Sy
g
The Importance of

oj st
ec em
tr
es de
ou si
rc gn
e
es
tim
at
io
U n
se
Pr rt
oj ra
ec in
in
ts g
ta
ff
tra
in
in
g
Importance
Frequency mentioned

75
Definitions
• The client pays for the development of the product.
(Computer center - traffic department)
• The customer buys the product once it is developed.
(Sometimes the same as…)
• Users will ultimately operate the product. (Police officer)
• Stakeholders are people who have an interest in the product
(system developers, QA people, lawyers etc.)
• Events are happenings that affects the work

76
Process of requirements
specification (typical)
• Establish objectives
• Business goals
• E.g. create or fulfill a need?
• Main problems to be solved (stakeholder goals)
• System constraints
• Understand background
• Existing system
• e.g. current baggage handling
• Organisational and environmental structure
• e.g. who does what and where, regulations
• Application domain
• e.g airport system
77
Process of requirements
specification (typical)
• Organise knowledge
• Stakeholder ident. and prioritisation
• Goal identification and prioritisation
• Domain knowl. filering
• Collect requirements
• Stakeholder requirements
• Organisational and environmental req.
• Domain requirements

78
Process of requirements
specification
• Source requirements
• Identify needs, store in database, identify issues
• Concept of operations specification
• What the system will do (not how) and why
• How the system is to be operated
• Justify that the system is superior to alternatives
• Context diagrams, Functional flow diagram, Time line
charts, N2charts
• Number of system external interfaces
• Unresolved/inconsistent source requirements
• Criteria for validation
79
Process of requirements
specification
• Functional/performance requirements
• Describe what the system does under what conditions
• Define verifications for ensuring that functionality is
followed (demonstrate, test, analyse, inspect)
• System hierarchy, functional block diagrams,
Functional flow diagram, Time line charts, control/data
flow diagrams, requiremens allocation sheet, Quality
function deployment
• Requirements allocation and traceability
• Deployment of spec. tree and specifications
80
Product Purpose
• The product purpose describes the reason for building
the product, it is the highest level customer requirement
• The goal (purpose) of the product, not only solves the
problem, but also provides some advantage. PAM –
Purpose, Advantage, Measurement
• Purpose: To allow on-line update of traffic violation
• Advantage: To reduce road accident by immediately punishing
“heavy” offenders
• Measurement: Accidents attributed to human factor shall be no
more than 15% of the total number of accidents

81
Types of requirement
specifications
• Functional
• Non functional
• Constraints

• Fit criteria, measurable, evaluable, testable, verifiable

82
Functional requirements
• Specify what the system must do
• Actions the product must take
• Derived from main goal of the product
• Not a quality
• Characterized by verbs
• Example: TVRS (traffic violation report system) shall
automatically connect with the policemen, vehicles and offenders
data bases

83
Non-functional requirements
• Properties, or qualities, that the system must
have
• Characterized by adjectives
• Checklist: Look and feel, Usability, Performance
Maintainability and Portability, etc
• Example: The interface between the user and the TVRS
must have a maximum response time of two seconds
• Example: Type and structure of content on a web page

84
Constraints
• Global issues that shape the requirements.
• They refer to any limitations on the way the
product is produced or consumed
• Design solution that must be used, budget in
time and money, project development
constraints, deplayment rules, cultural aspects,
company branding constraints etc.
• Example: TVRS must be a hand-held device
• Example: web page must work in several browsers

85
Constraints
• Quality requirements
• Accurateness, interoperability, compliance, security
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability
• Evolution requirements
• e.g. Scalable web site
86
Fit criteria
• Makes requirements measurable thereby
testable
• Description: TVRS shall register traffic violations
• Fit criteria: the registered traffic violations shall match
information sent by the police officer
• Description:TVRS shall be intuitive and self explanatory
• Fit criteria: a police officer shall be able to use the
product within 10 minutes of encountering it
• The specification must contain a definition of the
terms used in the fit criteria
87
Requirement specification
• Exercise

Problem : requirements for a car!

• Function (what it does):
• Non function (properties):
• Constraints (issues):
• Fit criteria (measurable):

88
Requirement specification
• Function (what it does) : transport 4 persons, at least 120 km/h,
trunk for luggage, roof against rain, door(s), lights, break
• Non function (properties): From road, less than 6 m long 4 m
wide,From user: shorter than 2.50m not wider than 60cm, comfort,
From marketing: looks lika a Porsche, several colours red, white,
• Constraints (issues):
From management: cheap to manufacture aluminium expensive but
does not rust, 100 man years, motor from last years model …, Intel
and Microsoft inside
• Fit criteria (measurable): It should be possible to drive the car
alone for 2 hours

89
Importance of Cultural Models
• Your End-Product Might Work Well In Theory,
But In Practice Wouldn’t Be Used Because Of:
• Differing Expectations
• Specific Desires
• Policies
• Values
• Changes In Approach at Organizational Level

90
Example, Webvan
• Works Well For Håkan
• BUT:
• Some People Want to Pick Out Their Food Directly
• Some People Won’t Plan A Day Ahead
• Some People Might View Shopping As a Social Activity or Out-Of-
House Event

91
Cultural Model Distinctions
• Interview-ee
• Influencers -- That Which Affects Work
• People
• Policies, Organizational Preferences and Values
• Points of Pride, Emotion, Personal Preferences
• Extent of Influence
• Specific Topic of Influence, and Direction
• Breakdowns
92
How Much Is Common?
• Will Find Many Differences and Similarities In
Culture!
• Within a ‘Group’ Within a Company
• Within a Company
• Between Companies Doing Similar Work
• Between Companies Doing Different Work
• Therefore, Need to Include Everyone Who Is
Relevant (don’t just take manager’s viewpoint!)
• Therefore, Can’t ‘Re-Use’ Cultural Model From
Old Project
93
A Good Requirement
Specification
• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable

94
Summary
• Object orientation (OO)
• Objects
• Classes
• UML
• Modeling language
• Uses OO
• 8 different diagrams
• You will use 5 in the lab exercise
• Analysis
• Use cases
• Requirement specification
95