UML basics

Corso
di
Laurea
Magistrale
in
Ingegneria
Informa4ca


Lecturer: Valentina Presutti

Academic Year: 2009/2010
Courtesy of Paolo Ciancarini
The soul never thinks 
without an image

Aristotle, De Anima
 Agenda


•  Modeling notations
•  UML 1.* and UML 2.*
•  Models and Views
•  Basic diagrams
•  Structures, behaviors, interactions
•  Case study
 Modeling - a foundation of all engineering disciplines


Models
improve
communica4on

and
understanding
about:

•  why
the
system
is
needed;

Requirements
•  what
its
func4onality
should
be;

Functional •  how
it
should
be
implemented

requirements

Non-functional Design
requirements Functional
design

Expresses needs
Implementation
design Implementation

hardware

software
Fulfils needs
User Owner
 A
modeling
engineering
spiral


has needs

Model Domain
Domain
models

Deploy Develop

Manufacture System
System
models

quality =
satisfaction of needs
 Visual
documenta4on


•  Software models are artifacts like…

Mechanical designs Electrical schemata Blueprints

Visual modeling a business process

Sales Places Order

Representative Customer

Fulfill Order

Item Business Process

via

Ships the Item

 UML: a modeling language

•  A modeling language allows the specification,

the visualization and the documentation of a
software development process
•  The models are artifacts which clients and
developers use to communicate
•  The most used modeling languages are
standard (eg. UML is a standard by OMG)
•  UML 1.* is a modeling language
•  UML 2.0 is also a programming language
 Unified Modeling Language

An industrial standard (OMG) notation to:

•  Model a business, its roles and processes
•  Write the requirements of a software system
•  Describe its software architecture
•  State the structure and behavior of a software
artifact
•  Document a software application
•  Generate automatically an implementation
 OMG
•  Object Management Group
•  Consortium of industries and interested
universities
•  Produces specifications of reference
architectures, eg. CORBA
•  UML has been adopted by OMG as
standard de facto
 Roots of UML

At the beginning of the ’90 there was a convergence:

  Booch method (Grady Booch) ’94 – join Rational Software

Corporation
  OMT (Jim Rumbaugh)

  Fusion/OOSE (Ivar Jacobson) ’95 – joins Rational

 The “tre amigos”

  Booch: analysis by objects

  Rumbaugh: Object Modeling Technique (OMT)
  Jacobson: process Objectory
  In 1994-95 they define for Rational both UML and UP

The three amigos:

Grady Booch, Jim Rumbaugh, Ivar Jacobson
 UML evolution
Approved OMG 2005
UML 2.0

Standard ISO/IEC 19501

IBM buys Rational, 2003 UML 1.5
3 Amigos books:
OMG, 2001; ISO, 2005 -- User Guide
UML 1.4
-- Reference Manual
OMG, jan ´97 -- Process Book
UML 1.1
public Beta version OOPSLA ´96
comments
WWW - June ´96 UML 0.9 on Web

OOPSLA ´95 Unified Method 0.8 Draft

other methods Booch OMT OOSE/Objectory

 UML History
•  OO languages appear, since mid 70’s to late 80’s
•  Between ’89 and ’94, OO methods increased from 10 to 50
•  Unification of ideas began in mid 90’s. pre-UML
•  1994 Rumbaugh joins Booch at Rational
–  1995 v0.8 draft Unified Method
•  1995 Jacobson joins Rational (Three Amigos)
–  1996 June: UML v0.9 published

–  1997 Jan: UML 1.0 offered to OMG

–  1997 Jul: UML 1.1 OMG standard
UML 1.x
•  Maintenance through OMG RTF
–  1998 June: UML 1.2
–  1999 Sept: UML 1.3
–  2001 Sept: UML 1.4

•  2003 Feb: IBM buys Rational

–  2003 March: UML 1.5
–  2004: UML 1.4.2 becomes the standard ISO/IEC 19501
UML 2.0
–  2005: UML 2.0
–  2007 Nov: UML 2.1.2
 Main UML specification documents
•  Superstructure: defines the UML elements
(diagrams, etc)
•  Infrastructure: defines the UML metamodel
•  OCL (Object Constraint Language): formal
language for writing constraints and formulas
•  XMI (XML Metadata Interchange): DTD for UML
models
•  UML Diagram Interchange: XMI + graphic info
 Canonical diagrams (vers 1.5)

•  Use case
•  Class (Object diagrams are class diagrams without classes )
•  Behavior
–  Statecharts
–  Activity
–  Interaction
•  Sequence
•  Collaboration
•  Implementation
–  Components
–  Deployment
 Canonical
diagrams
(Superstructure,
vers.
2.0)


Version 2.0 includes 13 canonical diagrams

•  Structure
1.  Class
2.  Composite structure
3.  Component
4.  Deployment
5.  Object
6.  Package
•  Behavior
1.  Activity
2.  Statecharts
3.  Usecase
•  Interaction
1.  Communication
2.  Interaction Overview
3.  Sequence
4.  Timing
 Structure and behavior
•  UML focusses on two aspects of object
oriented design: structure and behavior
•  It aims at visualizing both

Tour Eiffel (1889) G. Balla: Dinamismo di cane al guinzaglio (1912)

 Discuss
•  Which ways do you know to pictorially
describe “behaviors” - or actions?
Flowchart
 Discuss
•  Are structures and behaviors all we
need for software design?
 Example
•  The structure of a chess program could be
stand-alone, client-server, agent based
etc.
•  Its behavior should be coherent with the
rules of chess
•  What is its goal? To play and win a chess
game against an opponent
•  This is its function
 Example
•  The very same chess program, with
identical structure and behavior, could be
used with a different function?
•  For instance, could it be used to learn to
play chess?
•  Or to write a chess book, like a chess
game editor?
•  Or to play a game of loser’s chess (where
the winner if he who is checkmated)?
 Function
•  A software system is designed with
some functional requirements in mind
•  UML has a specific diagram for this:
Use Cases

Use Cases Interaction Diagrams Class Diagrams

Interactions between a User Behavior of core business Basic business elements Design time
and the system. elements in process. and their relationships.

Process Description State Diagrams Deployment Diagrams

Overview of process goals, Life cycle of core system
Actual structure of the final system
Run time
participants and collaboration. elements in process.

Function Behavior Structure

Modeling Requirements in UML
•  Use case diagram
–  Describes the main user stakeholders
–  Describes the externally observable behavior
of system functions, usually to define system
requirements
–  Describes interactions between the system
and external entities, including users and
other systems
 Use Case: elements
association system
boundary

use case

actor Register

Student
Check
Grades
<<include>>

Validate User
 Elements of a Use Case Diagram
•  Actor:
–  Represents a role played by external entities
(humans, systems) that interact with the system
•  Use case:
–  Describes what the system does (i.e., functionality)
–  Scenario: sequence of interactions between the
actors and the system
•  Relationships:
–  Association between actors and use cases
–  Extension (or generalization) among actors
–  Dependency among use cases: include and extend
 Example

Register
User User

<<include>>
Check Grades
Validate User
Student
Student Faculty Get Roster
<<include>>

<<extend>>
Faculty
Enter Grades
 Use Case Scenarios
Use Case: Check Grades
Description: View the grades of a specific year and semester
Actors: Student
Precondition: The student is already registered
Main scenario:
User System
1. The system carries out “Validate User”, e.g.,
for user “miner” with password “allAs”.
2. The system prompts for the year and semester.
3. The user enters the year and
semester, e.g., Fall 2007.
4. The system displays the grades of the courses
taken in the given semester, i.e., Fall 2007.
Alternative:
The student enters “All” for the year and semester, and the system displays
grades of all courses taken so far.
Exceptional:
The “Validate User” use case fails; the system repeats the validation use case.
 Exercise
•  Draw a use case diagram and a related
scenario for the following situation:

•  A user can borrow a book from a library; a

user can give back a book to the library
Structure
diagrams
 Object-Oriented Modeling
•  Use object-orientation as a basis of modeling
•  Models a system as a set of objects that interact with
each others
•  No semantic gap, seamless development process

Conceptual/computational world
Real world
Abstraction

Interpretation
Data-oriented Object-oriented
 Key Ideas of OO Modeling
•  Abstraction
–  Mechanisms to hide minor details so to focus on major details
•  Encapsulation
–  Modularity: principle of separation of functional concerns
–  Information-hiding: principle of separation of design decisions
•  Relationships
–  Association: relationship between objects or classes
–  Inheritance: relationship between classes, useful to represent
generalizations or specializations of objects
•  Object-oriented language model
= object (class) + inheritance + message send
 The basic building blocks of UML
Water

Fresh water
have
Rivers
Oceans
have

have have
live in Salt water

Fish have
Crocodiles
Penguins

–  Elements: domain modeling concepts

–  Relationships: connection between model elements
that adds semantic information to a model
–  Diagrams: collections of entities and relationships
representing some “perspective” on a model
 Basic building blocks - Things

  UML 1.x
  Structural — nouns/static of UML models (irrespective of time)

Main
  Behavioral — verbs/dynamic parts of UML models.

  Grouping — organizational parts of UML models.

  Annotational — explanatory parts of UML models.
 Structural elements - 7 Kinds (Classifiers)
  Nouns in the requirements
  Conceptual or physical elements

Active Class Component Interface Node

(replaceable part, (collection of externally
Class (processes/threads)
visible ops)
(computational
realizes interfaces) resource at run-time,
Student
Event Mngr processing power
std_id thread w. memory)

grade time Course.cpp

changeLevel() Start IGrade
setGrade() suspend() <<interface>>
getGrade() IGrade WebServer
stop()
setGrade()
getGrade()

Register Manage Course

for Courses Registration

Use Case Collaboration

(a system service (chain of responsibility
- sequence of shared by a web of interacting objects,
Interactions w. actor) structural and behavioral)
 Rela4onships


Student attends University

1. Associations
Structural relationship that describes a set of links, a link being a connection between
objects. Variants: aggregation and composition

Student Person
2. Generalization
a specialized element (the child) is more specific than the generalized element

3. Realization Student IGrade

one element guarantees to carry out what is expected by the other element.
(e.g, interfaces and classes/components; use cases and collaborations)

Jonh:Student <<instanceOf>>
Student
4. Dependency
a change to one thing (independent) may affect the semantics of the other thing (dependent)
(direction, label are optional)
 Class
•  Defines the structure of the states and the
behaviors shared by all the instances
•  Defines a template for creating instances
–  Names and types of all fields
–  Names, signatures, and implementations of all
methods
 Class diagram
•  Most common diagram in OO modeling
•  Describes the static structure of a system
•  Consists of:
–  Nodes representing classes
–  Links representing of relationships among
classes
•  Inheritance
•  Association, including aggregation and
composition
•  Dependency
 Notation for classes
•  The UML notation for classes is a rectangular
box with as many as three compartments

ClassName The top compartment show the class name

field1
The middle compartment contains the
……
declarations of the fields, or attributes, of
fieldn
the class
method1
… The bottom compartment contains the
declarations of the methods of the class
methodn
 Example
A point defined by classes at three different abstraction levels

Point

x
Point
y
Move

Point
- x: int
- y: int
+ move(dx: int, dy: int): void
 Example

Document

Pages[]
Document
nPages
display

Point
- Pages: array of Page
- nPages: int
+ display(k:int, p:Page): void
 Field and Method Declarations

•  Field declarations Visibility Notation

–  birthday: Date public +
–  +duration: int = 100
–  -students[1..MAX_SIZE]: Student
protected #
•  Method declarations package ~
–  +move(dx: int, dy: int): void
–  +getSize(): int private -
Visibility
 Exercise
Draw a class diagram for the following Java code

class Person {
private String name;
private Date birthday;
public String getName() {
// …
}
public Date getBirthday() {
// …
}
}
 Objects vs. Classes
Interpretation in the Representation in the
Real World Model
Object An object represents An object has an identity, a
anything in the real world state, and a behavior.
that can be distinctly
identified.

Class A class represents a set of A class defines the structure

objects with similar of states and behaviors that
characteristics and are shared by all of its
behavior. These objects are instances.
called instances of the
class.
Object = Identity + State + Behavior
•  Identity
–  Distinguishes an object from all other objects.
•  State
–  Consists of a set of attributes (or fields), which have
names, types, and values
•  Behavior
–  Defined by the set of operations (or methods) that may
operate on the object
–  Each method has a name, a type, and a value, where
•  The type consists of the return type and the list of parameter types of
the method, often called signature.
•  The value is the implementation of the method often expressed as a
sequence of statements, in languages like Java and C++
 Notation for Objects
•  Object: Rectangular box with one or two compartments
•  Object name: object name/role name:class name.

objectName: Classname The top compartment shows the

name of the object and its class.
field1 = value1
…… The bottom compartment contains
fieldn = valuen a list of the fields and their values.

p1:Point :Point P2/origin:Point

x = 10 x = 30 x = 20
y = 20 y = 30 y = 30
 Association
•  General binary relationship between classes or
objects
•  Represented as a line between boxes

Student Course

:John :SwEng
 Association
•  An association line may have an optional label
consisting of a name and a direction
•  The direction arrow indicates the direction of
association with respect to the name

enroll
Student Course

An arrow may be attached to the end of path

to indicate that navigation is supported in that direction
 Association
•  An association line may have an optional role
name and an optional multiplicity specification
•  The multiplicity specifies an integer interval, e.g.,
–  l..u closed (inclusive) range of integers
–  i singleton range
–  0..* entire nonnegative integer, i.e., 0, 1, 2, …

0..* 1
Student Faculty
advisee advisor
 Association example
•  A Student can take up to five Courses
•  Every Student has to be enrolled in at least one course
•  Up to 300 students can enroll in a course
•  A class should have at least 10 students

Student Course
10..300 takes 1..5

54
Association Example
- Multiplicity
•  A teacher teaches 1 to 3 courses
•  Each course is taught by only one teacher
•  A student can take between 1 to 5 courses
•  A course can have 10 to 300 students

1 teaches 1..3
Teacher Course
1..5

takes
Students
10..300
55
 Net data structures
• How we can represent a net of objects from the
same class?
• A class with an association to itself with both
ends of the association marked with 0..*

a1:A
0..*
A

b1:A d1:A f1:A

0..*

c1:A e1:A g1:A

 Hierarchic data structures
• How we can represent a hierarchy of objects from
the same class?
• A class with an association to itself with one end
of the association marked with 0..* (children) and
the other as 0..1 (parent)

a1:A
0..*
A

b1:A d1:A f1:A

0..1

c1:A e1:A g1:A

 Exercise
Explain the meaning of this diagram

6..* enroll 0..*

Student Course
advisee 0..* 1..*
teach

1
1
Teacher
advisor
 Aggregation
•  An aggregation is a special form of association
representing has-a or part-whole relationship
•  It distinguishes the whole (aggregate class) from its parts
(component class)
•  WARNING: an aggregation does not bind the parts’ lifetime
to the whole (they can exist separately)

Whole Part

Course Students
 Hierarchic file system
•  A directory can contain any number of
elements (either a file or a directory)
•  Any element is part of exactly one directory

*
Element

Directory File
 Non-hierarchic file system
•  A directory can contain any number of
elements (either a file or a directory)
•  An element can be part of many directories

*
Element

Directory File
 Composition
•  A composition is a stronger form of aggregation
•  It implies exclusive ownership of the component
class by the aggregate class
•  The lifetime of the parts is entirely included in the
lifetime of the whole (a part can not exist without
its whole)

Whole Part

Apartment Room
 Example

University

1..*
1 1..* 1 0..*
College Department Student

1 1
chair-of member-of

1 1..*
Faculty
 Exercise
Imagine some possible aggregation or
composition relationships among the
following classes and draw a corresponding
class diagram
–  Employee
–  Manager
–  Office
–  Department
 Dependency
•  Relationship between the entities such that the
proper operation of one entity depends on the
presence of the other entity, and changes in one
entity would affect the other entity
•  The common form of dependency is the use
relation among classes

<<use>>
Class1 Class2

<<use>>
Program Compiler
 Example

Registrar CourseSchedule

+ addCourse(s: CourseSchedule, c: Course): void

+ removeCourse(s: CourseSchedule, c: Course): void
Course
+ findCourse(title: String): Course
+ enroll(c: Course, s: Student): void
+ drop(c: Course, s: Student): void
Student

Dependencies are often omitted from the diagram unless they

convey some significant information
 Inheritance
•  Important relationship in OO modeling
•  Defines a relationship among classes or
interfaces
•  Three kinds of inheritance
–  extension relation between two classes (subclass and
superclass)
–  extension relation between two interfaces
(subinterface and superinterface)
–  implementation relation between a class and an
interface
 Inheritance in UML
•  An extension relation is called specialization and
generalization
•  An implementation relation is called realization

Superclass Superinterface Interface

Subclass Subinterface Class

extension of extension of implementation

classes interfaces of interfaces
 Class and superclass
Point

x
y

Point Move

Colored Point Colored Point

…
color
…
SetColor
 Notation for Interfaces

<<interface>>
Drawable
interface Drawable {
void draw(Graphics g);
+ draw(g: Graphics): void
}
 Interfaces
•  A class and an interface
differ: a class can have
an actual instance of its
type (but can also have
zero instances),
whereas an interface
must have at least one
class to implement it
•  Example: both the
Professor and Student
classes implement the
Person interface
 Example

Student
{abstract}

Graduate
No-degree Undergraduate
{abstract}

Master PhD
 Exercise

•  Draw a class diagram showing possible

inheritance relationships among classes
Person, Employee, and Manager
•  Draw a class diagram showing possible
inheritance relationships among classes
Person, Student, Professor, and Assistant
Real example: DOM
Real example: Facebook
 Strange examples

1 1
A A

1 1

A A
Behavior
diagrams

Duchamp: Nude descending a staircase

 Modeling Behavior
•  Statechart
diagram

–  Depicts
the
flow
of
control
inside
an
object
using
states

and
transi-ons
(finite
state
machines)

•  Ac4vity
diagram

–  Describes
the
control
flow
among
objects
by
ac4ons

organized
in
workflows
(Petri
Nets)

•  Sequence
diagram

–  Depicts
objects’
interac4on
by
highligh4ng
the
-me


INTERACTION
ordering
of
method
invoca4ons

•  Communica4on
(collabora4on)
diagram

–  Depicts
the
message
flows
among
objects

 Behavioral elements
  Verbs in the requirements
  Dynamic parts of UML models: “behavior over time”
  Usually connected to structural elements

Two primary kinds of behavioral elements:

  Interaction
a set of objects exchanging messages, to accomplish a specific purpose.

harry: Student
ask-for-an-A paul: Professor
name = “Harry White” name = “Paul Smith”

  State Machine
specifies the sequence of states an object goes through during its lifetime in
response to events

received-an-A/buy-beer
inStudy inParty
sober/turn-on-PC
 State diagram
•  Graph: net of states (nodes) and transitions (arrows)
•  Graph representing a finite state machine
•  Useful for modeling a reactive (event-driven) system
•  Animation by “token game”

push switch

Off On

push switch
State diagram: elements

Initial State Final State

Transition

Idle Running

State
Example: Unix process

end
fork Pre-empted
Running

Ready scheduled
Sys call

Sys return
Waiting
 State
•  Situation in the life of an object (or system)
during which it:
–  Satisfies some condition,
–  Performs some activity, or
–  Waits for some events
•  Set of values of properties that affect the
behavior of the object (or system)
–  Determines the response to an event,
–  Thus, different states may produce different
responses to the same event
 Elements of a state diagram
StateName State1 State3
[condition]

activity do/action do/action1 do/action3

event

transition
State2

do/action2

Superstate

Start Dial

entry/starttone digit(n) [number.isValid()]

entry/number.
exit/stoptone append(n)

digit(n)
 Transition
•  Relationship between two states indicating that a
system (or object) in the first state will:
–  Perform certain actions and
–  Enter the second state when a specified event occurs
or a specified condition is satisfied
•  A transition consists of:
–  Source and target states
–  Optional event, guard condition, and action

Event [Condition] / Action

Source Target
 Definition
•  Event
–  An occurrence of a stimulus that can trigger a state
transition
–  Instantaneous and no duration
•  Action
–  An executable atomic computation that results in a
change in state of the model or the return of a value
 Example

dial digit(n)
[incomplete]

connected Ringing

Dialing Connecting
dial digit(n)
[valid] / connect
dial digit(n)
[invalid] busy
Busy

Invalid
 Example

recovery success

recovery failure

anomaly Recovery
Normal
Identification
temperature
pressure
recovery
failure
recovery
Pressure Temperature
success Recovery Recovery
recovery
failure
recovery success
 Composite states

Recovery
anomaly

Normal Recovery
Identification
recovery
success
pressure temperature

Pressure Temperature
recovery Recovery Recovery
failure
 Composite state
•  Used to simplify diagrams
•  Inside, looks like a statechart
•  May have composite transitions
•  May have transitions from substates
•  Sequential and parallel
Composites and transitions

Transition to/from composite state

Active

Idle
Validating

Selecting Processing
Maintenance

Printing

Transition from substate

Including composite states

Dial Number

Include / Dialing

Dialing

[number.isValid()]

Start digit(n) Partial Dialing

entry / start dial tone entry / number.append(n)

exit / end dial tone

digit(n)
 Parallel composition
•  Concurrency (multiple threads of control)
•  Synchronization

Superstate

substate1 substate2

substate3 substate4
 Example

Incomplete

Mod1 Mod2

Project Passed

fail
Midterm Final Failed
 History pseudo state
•  A history pseudostate represents the most recent active
substate of its containing state
•  There are two kinds of this pseudostate: shallow or deep
(See the Superstructure sect 15.3.8 pag 541 for their definition)
 Consistency
among diagrams Student
practices
enrolls * FirstName *
LastName
Age
Role 0..*
1
DegreeProgram Sport

Enrolls a differenr
program

Student

Changes role
Finishes education
program Studies

Changes carreer
Graduated Sporty
 Exercise: Cellular Phone
•  Draw a statechart describing the operation of a cellular
phone. Assume that the phone has keys for:
–  power on and off
–  keypad locking and unlocking
–  0-9, #, and *
–  talk (or send) and end
Model the following operations:
–  power on/off
–  keypad locking/unlocking
–  making calls (e.g., dialing, connecting, talking),
–  receiving calls (e.g., ringing, talking)
 Activity diagram: elements
A special kind of state diagram that shows the flow from activity to activity

initial

Initialize course activity

Add student

fork/spawn

Notify Registrar Notify Billing

synchronization
[else]

[ count < 10 ]
guard
Close course final
Example
Example
Example
Example:
business
plan
 Activity partition
•  Partitions divide the nodes and edges to constrain and show a view of the contained
nodes
•  Partitions can share contents; they often correspond to organizational units in a
business model
 Swimlanes
in an
activity diagram
showing a
workflow
 State vs activity diagrams
•  Both diagrams describe behaviors, by
state changes and actions, respectively
•  In UML1 they are equivalent (in AD states
are actions)
•  In UML2 they differ: ActivityD are based on
Petri Nets, StateD on Harel automata
•  Also their typical usage is different: SD are
single context, AD multiple context
 State vs activity diagrams

e2e4 e7e5 g1f3 b8c6

White

Pe2e4 Cg1f3

Pe7e5 Cb8c6
Black
 Exercise

Which is the
maximum
degree of
parallelism in
this activity
diagram?
 Behavior
diagrams:
interaction
Balla: Dynamism of a Dog on a Leash, 1912
 Modeling Interaction
•  Statechart
diagram

–  Depicts
the
flow
of
control
inside
an
object
using
states

and
transi-ons
(finite
state
machines)

•  Ac4vity
diagram

–  Describes
the
control
flow
among
objects
by
ac4ons

organized
in
workflows
(Petri
Nets)

•  Sequence
diagram

–  Depicts
objects’
interac4on
by
highligh4ng
the
-me


INTERACTION
ordering
of
method
invoca4ons

•  Communica4on
(collabora4on)
diagram

–  Depicts
the
message
flows
among
objects

 Interaction diagrams
•  A use case diagram presents an outside view of
the system
•  The inside behavioral view of a system is
shown by interaction diagrams

•  Interaction diagrams describe how use cases

are realized in terms of interacting objects
•  Two types of interaction diagrams
–  Sequence diagrams
–  Collaboration (Communication) diagrams
 Sequence diagram
•  A sequence diagram describes a
sequence of method calls among objects
•  There are several types of method calls
 Sequence diagram
A SD highlights the objects involved in an activity
and the time ordering of method calls among them

http://www.agilemodeling.com/artifacts/sequenceDiagram.htm
Example
 Sequence diagram: elements

object

lifetime
activation message
bar
Sequence diagram: flow

: Customer : Order : Payment : Product : Supplier

place an order

process

validate
Sequence of message sending

if ( payment ok )
if ( not in stock )
deliver
back order

get address

mail to address
Using a SD for workflow
 Consistency among diagrams
We can derive the dependencies shown in a class diagram
from the interactions defined in a sequence diagram
 Exercise
Draw a sequence diagram showing how a customer interacts
with a travel agency, a station and a train to reach some
destination

Draw a sequence diagram to show how a user prints a document

on a printer, and a counter keeps a count of printed pages
Communication (collaboration) diagram

•  Communication diagrams show the

message flow between objects in an
application
•  They also imply the basic associations
(relationships) between classes
•  Communication diagrams are drawn in the
same way as sequence diagrams (and
can be semantically equivalent to them)
 Communication diagram
object
: Order 1.1 : ok := validate() : Payment

link
1.2 [ok] : deliver(c)

1 : place an order(c)
c : Customer 1.2.2 : get address() p : Product

message 1.2.1 [not in stock] : back order(p)

: Supplier
 Communication diagram
Collaboration
: Order 1.1 : ok := validate() : Payment

1.2 [ok] : deliver(c)

1 : place an order(c)
c : Customer 1.2.2 : get address() p : Product

1.2.1 [not in stock] : back order(p)

: Supplier
 Sequence and
communication
diagrams

•  These two
diagrams are
equivalent
 Exercise
•  Draw a communication diagram showing
how a customer interacts with a travel
agency, a station and a train to reach
some destination

•  Draw a communication diagram to show

how a user prints a document on a printer,
and a counter keeps a count of printed
pages
Basic diagrams we have seen
 Other diagrams
Diagrams we have seen in this lecture:
•  Use case, class, object, statechart, activity,
interaction (sequence and collaboration)
We could add (using UML 1.*):
•  Component, Deployment
We could add (using UML 2.*):
•  Composite structure, Package, Interaction
Overview, Timing
Usage survey
 Main diagrams
The main diagrams that are used in most
views are :
•  Use case diagram
•  Class diagram
•  Sequence diagram
•  Activity diagram
 Discuss
•  Which diagrams are most useful in each
lifecycle phase?
 Diagrams in lifecycle

... Requirements ... Design ... Implementation

Use Case

Class diagram

Sequence diagram

Activity diagrams and Statecharts

 Conclusions
•  UML is a notation still evolving, defined by a
metamodel
•  It offers several diagram types, in order to
describe different views on a model
•  Basic diagrams are: use cases, classes,
behaviors (statechart+activity), interactions
(sequence+communication)
•  Several tools available
•  Needs a process to be used consistently and
effectively
 Summary
•  UML includes a number of diagram-based
notations to model software systems
using an object oriented approach
•  UML is not a process (it needs a process,
like for instance the RUP)
•  It is not proprietary: it is an OMG (Object
Management Group) and ISO standard
 Exercise

•  Draw,
on
some
game‐playing
domain:

–  A
class
diagram

–  An
object
diagram

–  A
statechart

–  A
sequence
diagram

–  A
communica4on
diagram

–  An
ac4vity
diagram

 Questions
•  What is a software model?
•  Which are the UML canonical diagrams?
•  What is a use case?
•  What is a class diagram?
•  How do we describe a tree-like data structure in
a class diagram?
•  What is an interaction diagram?
•  What is the difference between statecharts and
activity diagrams?
 Readings
•  On use cases
www.ibm.com/developerworks/rational/library/5383.html

•  On class diagrams
www.ibm.com/developerworks/rational/library/content/
RationalEdge/sep04/bell/index.html

•  On sequence diagrams
www.ibm.com/developerworks/rational/library/3101.html
 UML Specification Documents
•  OMG, UML Specification v. 1.5, 2003
•  OMG, Meta Object Facility 2.0, 2006
•  OMG, UML Superstructure 2.1.2, 2007
•  OMG, UML Infrastructure 2.1.2, 2007
•  Rumbaugh, Jacobson, Booch, The UML Reference
Manual, Addison Wesley, 1999 and 2004 (2nd ed)
 References on using UML
•  Ambler, The Elements of UML 2.0 Style, Cambridge
University Press, 2005
•  Booch, Rumbaugh, Jacobson, The UML User Guide,
Addison Wesley, 1998 and 2005 (2ed)
•  Fowler, UML Distilled, 3ed, Addison Wesley, 2003
•  Pilone and Pitman, UML 2.0 in a Nutshell, OReilly, 2005
 Useful sites
•  www.uml.org Documents defining the standard
•  www.omg.org
•  www.agilemodeling.com/essays/umlDiagrams.htm
•  softwarestencils.com/uml Images reusable in a graphic editor
•  www-306.ibm.com/software/awdtools/rmc/library
•  www.cs.gordon.edu/courses/cs211/ATMExample
•  opensource.objectsbydesign.com
•  www.cragsystems.co.uk/ITMUML/index.htm Online courseware
•  www.eclipse.org/modeling/mdt/uml2/docs/articles/Getting_Started_with_UML2/article.html
 Tools
•  Eclipse + several plugins, like Omondo
•  www-01.ibm.com/software/rational/ Rational Rose
•  jazz.net New IBM platform
•  argouml.tigris.org Argo or Poseidon
•  www.borland.com/us/products/together/index.html Borland Together

•  www.visual-paradigm.com Visual Paradigm suite

•  www.magicdraw.com/
•  www.tabletuml.com
•  abstratt.com/
•  www.umlgraph.org
•  code.google.com/p/raf-uml
•  metauml.sourceforge.net Beautiful UML diagrams in LaTeX
Questions?