Welcome to




 1
Source & Credit
This presentation is adopted from:
◦ ftp://ftp.ifs.uni-linz.ac.at/pub/wieland/uml.ppt
◦ © Hitz, Kappel, Retschitzegger; Information
Systems Group (IFS),
http://www.ifs.uni-linz.ac.at/
◦ @ Johannes Kepler Universitat Linz,
Germany,

2
UML - Outline
 Introduction

}
 Requirements Specification
 Analysis UML Syntax
and Semantics
 Design

 Pitfalls
and Workarounds
 Roadmap to UML 2.0
 References

3
Motivation for Analysis and Design
Why do we model?

“When it comes down to it,

the real point of software development is cutting code”
“Diagrams are, after all, just pretty pictures”

“No user is going to thank you for pretty pictures; what a user
wants is software that executes”

[M. Fowler, “UML Distilled”, Addison Wesley, 1997]

4
Motivation for Analysis and Design
The Model as an Abstraction of the Reality

 We are not able to comprehend a complex system in its

entirety - a single model is not enough
◦ different perspectives are required, which in turn require
different models being independent from each other
◦ each model must exist on different levels of granularity

 Good models are necessary ...

◦ for making complex systems more understandable
◦ for visualizing the essential aspects of a system
◦ for communication among project members and with the customer
◦ for ensuring architectural soundness

5
 What is the UML?
Goals
 Provide users with an expressive modeling language
◦ for the specification, construction, visualization and documentation of the artifacts of a
software system
◦ for the construction of different kinds of models
◦ for the exchange of models

 Provide users with ready-to-use core concepts

◦ however, extensibility and specialization mechanisms are available

 Providea formal basis for understanding the modeling

language
◦ metamodel in terms of a UML class diagram
◦ “Semantics” is part of the official UML documentation
 Support higher-level development concepts
◦ such as collaborations, patterns, and components

 Integrate best practices

6
 What is the UML not?
 Itis the explicit intention of the UML developers
not to prescribe
◦ a certain process
◦ a certain modeling tool
◦ any modeling guidelines
◦ a certain programming language

 Dedicated Goal: Openness!

7
 History of UML Industrialization
June `99 UML 1.3

OMG accepts the UML as the official Standardization

industrial standard for software modeling
notations on 17th Nov. ‘97 UML 1.1

Public Submission to OMG, Sept ‘97 UML 1.0

Feedback
Submission to OMG, Jan ‘97
Beta Version OOPSLA ‘96 UML 0.9 Unification

WWW-June ‘96 Unified Method 0.8

OOPSLA ‘95
Booch’93 OMT-2 Fragmentation
“Method Wars”
Various Methods Booch’91 OMT-1 OOSE

8
 Diagrams of UML
(1) Use Case Diagram
(2) Class Diagram
Interaction
(3) Sequence Diagram
Diagrams
Behavior (4) Collaboration Diagram
Diagrams
(5) Statechart Diagram

(6) Activity Diagram

Implementation (7) Component Diagram

Diagrams
(8) Deployment Diagram

9
 Views supported by UML
Use Case View
 Use Case Diagram
 Statechart Diagram Pr
i ew Interaction Diagrams  oce
V 

ig
n  Activity Diagram Cla ss/
s
e ram ram s

Sta ss D on
C
D
l/ iag iag ram

c
a
c s D rt D iag Int tech iagra urr
i
g s

e a
Ac ract rt D m
en
a cy
Lo la ch n D ram
C te tio g r tiv
ity
ion iag
ram Vi e
a D
 St erac Dia Dia iag
gra ram
w
 Int tivity m s
 Ac
 System Component / Impl. View
Deployment View  Component Diagram
 Deployment Diagram  Statechart Diagram
 Statechart Diagram  Interaction Diagrams
 Interaction Diagrams  Activity Diagram
 Activity Diagram [after Booch et al., 1999]

10
 Ongoing Example
Calendar Manager “CALENDARIUM” (1/2)
 Multi-user calendar manager on Internet basis
 Visualization
◦ views on a yearly, monthly, weekly and daily basis
◦ insert/update of appointments in each view
◦ highlighting of days with appointments (in year view only)
 Appointments
◦ single appointments; appointment series
◦ possibility to define different kinds of appointments
(private, business, etc.)
◦ management of a to-do list
◦ appointments are relocatable or fixed

11
 Ongoing Example
Calendar Manager “CALENDARIUM” (2/2)
 Communication
◦ timely notification of all persons involved in a appointment
◦ advance notice of appointments
◦ management of access rights
◦ coordination of joint appointments
◦ search capability for possible appointments with n
participants
 Definition of named groups of persons
 Export of appointments within a certain time frame
◦ printer, spread sheet, HTML
 Variousvisualization parameters may be
configured by the user

12
Outline
 Introduction

}
 Requirements Specification
 Analysis UML-Syntax
and -Semantics
 Design

 Pitfalls
and Workarounds
 Roadmap to UML 2.0
 References

13
 Phase 1: Requirements Specification
 Goal is the description of the required system
functionality from the user‘s point of view
◦ Description of the use cases (“use case driven”)
◦ conceptual model of the Universe of Discourse to which
the application belongs
◦ defines how the system should communicate with its
environment, represented by actors

 Communication medium between user and

developer

14
Use Case Model
System, Actor and Use Case

Functional decomposition of the system into

use cases and actors interacting with them
◦ use cases represent the requirements of the
customers

Results of constructing the use case model:

◦ global use case diagram
◦ a detailed textual description for each use case

15
Use Case Diagram
CALENDARIUM

CALENDARIUM
query
appointment
export
appointments
delete
appointment
change
User
appointment
insert
appointment

16
Actor (1/2)
 Actors interact with the system
◦ by using the system, i.e., by initiating the execution of use cases
◦ by being used by the system, i.e., by providing functionality for
realizing use cases
◦ each actor is required to communicate with at least one use case
◦ the communication relationship is undirected
 Actors represent roles
◦ concrete users are allowed to
adopt/play/discard more
than one role at a time
◦ actors are located outside the
system boundaries «actor»
User

User

17
Actor (2/2)
 Classification
◦ human: e.g. novice/trained user; system administrator
◦ non-human: e.g., fax, e-mail
◦ primary: ultimate user of the system
◦ secondary: ensures the correct functionality of the system
◦ active: initiates use cases
◦ passive: corresponding use case is initiated by the system
 Questions for identifying actors:
◦ Who uses the essential use cases?
◦ Who needs system support in order to fulfil the daily tasks?
◦ Who is responsible for system administration?
◦ What are the external devices/software systems the system has to
communicate with?
◦ Who is interested in the results of the system?

18
Use Case
 Use cases represent the functionality expected by the system
under development
 Identification of use cases can be done by collecting user
requirements and by analyzing the problem description

Short Description:

»An appointment can be inserted for one or more

participants by an authorized user, who does not need
insert to be one of the participants. All participants must be
appointment notified of this new appointment. New appointments
must be visualized immediately in all open calendars of
the respective participants.«

Note

19
Relationships Between Use Cases (1/4)
«include» -Relationship
◦ the behavior of B is included into A
◦ the included use case B is necessary to ensure
the functionality of the base use case A
◦ formerly called «uses» -relationship
«include»
A B

base use case; included use case;

needs B is self-contained

20
Relationships Between Use Cases (2/4)
«extend» -Relationship
◦ the behavior of B may be incorporated into A
◦ the extending use case B may be (but need not
be) activated by the base use case A
◦ extension points specify the location where the
extending use case extends the base use case
«extend»
A B

base use case; extending use case;

is self-contained; is self-contained
controls, if B is executed or not
21
Relationships Between Use Cases (3/4)
«extend»
od if y a c c ess rights) configure
(M
configure program
cc e s s righ ts selected] access rights
[A
extension points
«extend
Modify access rights (Modify »
pa configure
Modify parameters [Parame rameters)
ters sele parameters
cted]

◦ the condition under which the extending use case is

incorporated has to be specified
◦ more than one extension point can be specified for each
use case
◦ the names of extension points have to be unique
◦ the names of extension points need not be equal with the
names of the extending use cases

22
Relationships Between Use Cases (4/4)
 Generalization Relationship
◦ Similar to the generalization relationship between classes
◦ B inherits the behavior of A and is allowed to override and extend
it
◦ B inherits all relationships of A
◦ Modeling of abstract use cases is also possible ({abstract})

A B

base use case; sub use case;

is self-contained needs A (gets base functionality from A);
controls, what is executed from A
and what gets changed
23
Use Case Diagram
CALENDARIUM (refined, 1/2)
CALENDARIUM
query
entry export
entries delete
entry
change
User insert entry
entry «include»
«include»
«include» update
configure calendar
Program notify
«actor»
participants
«extend» Fax-System
configure
configure parameters «actor»
access rights E-Mail-System
administer
users
administer
Administrator
entry types

24
Use Case Diagram
CALENDARIUM (refined, 2/2)

insert
entry
{abstract}

User
insert insert
appointment to-do entry

Analogous for query/export/delete/change entry

25
Excursion (1/4)
Semantics of the «include»-Relationship

 Problem: Where and how should

«include»
A B «include» be located within the
base use case ?
 Possible solution: “Probes”
from OOSE

A B

26
Excursion (2/4)
Semantics of the «extend»-Relationship

«extend»
A B

B
A

“inner” of the language BETA

27
Excursion (3/4)
Semantics of the Generalization Relationship

A B

B
A

“super” of the language Smalltalk

28
Excursion (4/4)
Generalization Relationship between Actors
 An actor A which inherits another actor B is able to
communicate with the same use cases as B
 Multiple inheritance also allowed
 It can be distinguished whether multiple actors have to
communicate with a use case in common or not

A A

A B A B

B B

 29
Partitioning Use Case Diagrams
Package (2/3)
Appointment Manager

query update
entry calender
«include»
«include» «include»
User insert change delete
entry entry entry
«include» «include»
«include»
export notify
entries participants

«actor» «actor»
E-Mail-System Fax-System


  30
Excursion (1/4)
Description of Use Case
 Name/Short Description
 Preconditions: prerequisites for successful execution
 Postcondition: system state upon successful completion
 Failure Situations: only domain-related failures
 Postcondition in case of failure
 Actors: communicating with the use case
 Trigger: initiating event for the use case
 Main Success Scenario: single (atomic) steps/other use cases
 Extensions/Variations: deviations from main success scenario

[cf.: A. Cockburn, Goals and Use Cases. JOOP, Sept. 1997]

31
Excursion (2/4)
Description of Use Case - “Insert Appointment”
 Name and Short Description: Insert appointment
»An appointment can be inserted for one or more participants by an authorized
user, who does not need to be one of the participants. All participants must be
notified of this new appointment. New appointments must be visualized
immediately in all open calendars of the respective participants.«
 Precondition: User is known by the system.
 Postcondition:
◦ New appointment is inserted.
◦ All participants are notified either about the new appointment or that due to
authorization problems it was not possible to change their calendar.
◦ All calendar views are updated.
 Failure Situations: The user lacks proper authorization for every participant in order
to insert the new appointment into their calendars.

 32
Excursion (3/4)
Description of Use Case - “Insert appointment”
 Postcondition in case of failure:
◦ appointment could not be inserted.
◦ The calendars of all participants as well as their views haven‘t been changed by the
use case.
 Actors: User (primary actor), E-Mail-System (secondary actor), Fax-System (secondary
actor).
 Trigger: -
 Main Success Scenario:
(1) User identifies him/herself.
(2) The details of the new appointment (time, location, duration, participants, etc.) are
being recorded.
(3) User is authorized to insert the appointment for all participants.
(4) appointment does not cause any collisions and is inserted.

3
Excursion (4/4)
Description of Use Case - “Insert appointment”
(5) All participants (except the user in case (s)he is a participant too) are
notified according to their preferred type of communication ( «include» notify
participants)
(6) All currently open calendars of participants are updated. ( «include» update
calendar)
 Extensions/Variations:
(3’) For at least one participant, the user is not authorized to insert a
appointment.
(4’) Analogous to (4)
(5’) Analogous to 5, whereas each participant whose calendar could not be
changed is notified about this authorization problem.
(6’) All calendars of participants without authorization problems are updated,
where proper authorization exists.

3
Flow of events in a use case
 Has one normal, basic flow
(“Happy Path”)
 Several alternative flows
◦ Regular variants
“
”
◦ Odd cases
◦ Exceptional flows handling
error situations
Use Case Description: Change Flight
 Actors: traveler, client account db, airline reservation system
 Preconditions:
◦ Traveler has logged on to the system and selected ‘change flight itinerary’ option
 Basic course
◦ System retrieves traveler’s account and flight itinerary from client account database
◦ System asks traveler to select itinerary segment she wants to change; traveler selects
itinerary segment.
◦ System asks traveler for new departure and destination information; traveler provides
information.
◦ If flights are available then
◦ …
◦ System displays transaction summary.
 Alternative courses
◦ If no flights are available then …
When to model use cases
Model user requirements with use cases.
Model test scenarios with use cases.
If you are using a use-case driven method
◦ start with use cases and derive your structural
and behavioral models from it.
Ifyou are not using a use-case driven
method
◦ make sure that your use cases are consistent
with your structural and behavioral models.
Model requirements of a system
Establish the context (actors).
Consider behavior expected by an actor.
Name the common behaviors as use cases.
Create use case descriptions.
Factor common behavior into new use
cases
Model use cases, actors and their
relationships in a use case diagram.
Using use-cases
First describe flow of events for a use
case in text.
With refinement of your understanding,
use interaction diagrams to specify these
flows.
Use one diagram to specify the main flow.
Use variations of the main diagram to
specify exceptional cases.
Problem Domain Model
Represents the conceptual model of the problem
domain (also called universe of discourse)
◦ does not contain any implementation details
◦ supports the communication between developer and
user
Result of problem domain modeling:
◦ class diagram, visualizing the static structure of the
system under development (“static structure
diagram”)

40
Class and Object
 Class:
User
name: String
Attributes authorization: Right
pwd: String
number: Integer Class Attribute
Operations
validatePW (PW: String): bool
computeNumber(): Integer Class Operation

 Object: Name of object (and class) is underlined

aUser
aUser : User
: User

 41
Characteristics of a Class
 Classattributes/operations: underlined
 Properties of attributes:
◦ “/” attribute name: derived attribute
◦ {optional}: null values permitted
 Properties of operations:
◦ {query}: operation without side effects
◦ {sequential}, {guarded}, {concurrent}: kind of concurrency
 Visibilities:
◦ + ... public
◦ - ... private
◦ # ... protected

 42
 Abstract Class
 Cannot be instantiated
 Useful for generalization hierarchies only
 Factors out common properties of subclasses

Entry
or Entry
{abstract}

 The same notation is used in order to distinguish between

abstract operations and implemented operations

 4
 Classes in Different Phases
Requirements Specification: Design:
Appointment «entity»
/ visualization: Color Appointment
start: DateTime {persistence=persistent}
description: String - startDate: Date
duration: Time - startTime: Time = “09:00”
hyperlink[0..1]: URL - duration: Time = “01:00”
type: AppointmentType - description: String = ""
numberOfAppointments: Int
+visualization(): Color
{visualization = colorCode(type)} +collidesWith (t: Appointment):
bool
(t.startDate=startDate  ...
Note (t.startTime startTime+duration 
t.startTime+t.duration  startTime))

 47
 Welcome to




 48
Association (1/3)
 Association between classes
◦ association name (optional)
◦ arrow above each edge expresses reading direction (optional)
◦ arrow at the end of an edge expresses navigation direction (optional)
◦ each end of an association is defined by means of multiplicity
◦ for a binary association, the multiplicity on the target end contrains how many
objects of the target class may be associated with a given single object from the
other (source) end

1..* attachedTo *
Calendar Appointment
 Link between objects
◦ represents an instance attachedTo
of an association aCalendar : a1:Appointment
Calendar
attachedTo a2:Appointment

 4
Association (2/3)
Multiplicity

 arbitrary number “ * ”
 a range is specified by means of “ .. ”
 possible numbers are separated by means of commas

exactly 1: 1
 0: * (or 0..*)
0  1: 0..1
fixed number (e.g. 3): 3
range (e.g. 3 or more): 3..*
range (e.g. 3-6): 3..6
enumeration (e.g. 3,6,7,8,9): 3, 6..9

 50
 Association (3/3)
Role
Classes play roles within associations
◦ a single class can play more than one role

Insurance 1 issued by 0..* Insurance

Company insurer Contract
0..*

refe
rs
to
married to
superior wife 1..*
0..* 0..1 0..* 0..1 0..1 policyholder
subordinate Employee husband
0..* peer married to is still
Person
incompletely
specified...
 51
Properties of Associations (1/2)
 {sorted}

Appointment
Calendar 1..* *
/visualization
isOpen {sorted} start
description
duration
type

 {ordered}

1 contains *
Queue QueueItem
{ordered}

 Ordering is independent of QueueItem attributes.

 52
Properties of Associations (2/2)
 Exclusive 1
Or {xor} SerialEntry
◦ only one of a set of possible 1 {xor}
associations can be instantiated
for a certain object at
1..* {sorted} 1..* {sorted}
a certain time
ToDoEntry Appointment

 {subset}
1..* participates *
User Appointment
participant
{subset} *
coordinator 1

coordinates

 53
Qualified Association
 A Qualifier is an attribute or a list Bank Bank
of attributes * account#
◦ whose values partition the objects *
of the associated class in a disjoint * 0..1
manner Person Person
◦ in most cases, multiplicity is reduced to one
 Represents a property of the association

1 manages 1
User
GroupOfParticipants Owner groupName name
*
Participant 1..*

consistsOf

 54
Association Class (1/2)
 Necessary in case of m:n-associations with attributes:

1..* Participation *
User Appointment

association
isRelocatable class
 It enhances flexibility in case of 1:1 and 1:n-associations:

Company 1 Person
name * name
address socSec#
Employment address
loan loan
position { position

 55
Association Class (2/2)
Object Class  Association Class
1 1
Person Project
* *
Employment P1 E1 Pr1
qualificationProfile E2
hours
dailyRate E3
P2 E4 Pr2

Person * * Project

Employment P1 E1 Pr1
qualificationProfile
hours
dailyRate E3
P2 E4 Pr2

 56
N-ary Association
Relationship between more than two classes
◦ navigation direction cannot be specified
Example of a ternary association:
Calendar

* *
User AppointmentType

Authorization association
class
set of [r, w, d]

validateAuth(...)

 57
Aggregation
Aggregation is a special kind of association having
the following properties:
◦ Transitivity:
C is part of B and B is part of A  C is part of A
◦ Anti-Symmetry:
B is part of A  A is NOT part of B

UML supports two kinds of aggregation:

◦ “weak” aggregation
◦ Composition

 58
Weak Aggregation
The multiplicity at the aggregate end may be > 1
* *
A B
Properties:
◦ weak relationship, i.e., parts are independent of the
whole
◦ there is almost no propagation semantics
◦ the aggregated objects form a directed, acyclic
graph
* *
GroupOfPersons User

 59
Composition
 The multiplicity at the aggregate end must be <= 1
0..1 *
A B
 Properties:
◦ a certain part can be incorporated at a certain time in at most one
composite object only
◦ the parts are dependent on the composite object
◦ propagation semantics
◦ the composite objects form a tree

Graphic * * 1
* Annotation
Document
Paragraph * *

 60
 Composition vs. Association
Rules of Thumb
 Physically embedded vs. references:
◦ the parts are physically embedded within the composite object
◦ objects are associated by means of references
 Visibility:
◦ the part is visible for the composite object only
◦ the visibility of the associated object is public
 Life Time:
◦ the composite object creates and deletes its parts
◦ there is no existential dependency between associated objects
 Copy Semantics:
◦ composite objects and parts are copied together
◦ only the references to associated objects are copied

 61
 Generalization (1/2)
 is a taxonomic relationship between a specialized class
and a more general class
◦ the specialized one inherits all properties of the generalized one
◦ additional properties can be added
◦ an instance of the subclass can be used wherever an instance of
the superclass is allowed (at least syntactically)
◦ multiple inheritance is also allowed:
University Member
{overlapping}

... Student Lecturer

The model contains more

subclasses than actually
shown in this diagram Instructor

 62
 Generalization (2/2)
Properties of Generalization:
◦ non-complete / complete (default)
 complete: all possible subclasses are already part of the model
(but not necessarily visualized!)
◦ overlapping / disjoint (default)
 2 interpretations of overlapping:
 Concerning multiple inheritance: two or more subclasses can
have again common subclasses (e.g. Instructor)
 Concerning multiple classification: an object can be instance of
more than one subclass
2 alternative Employee {incomplete,
{complete, Entry
notations overlapping}
disjoint}
Technical Administrative
Appointment SerialEntry ToDoEntry Employee Employee

 63
Template Class
A template class describes a “family” of classes
on the basis of formal parameters
◦ each class is specified by binding the parameters with
actual values
T,k: Int
Array
length: 0..k
...

Alternative 1: putAt (e: T, i: Int) Alternative 2:

at (i: Int): T
«bind» (Point,3)
Array<Point,3>
ListOfPoints

 65
Outline
 Introduction

}
 Requirements Specification
 Analysis UMLSyntax
and Semantics
 Design

 Pitfalls
and Workarounds
 Roadmap to UML 2.0
 References


  66
 Phase 2: Analysis
 Goal is a detailed analysis of problem domain and use cases
◦ complementation of the model by means of additional objects
◦ definition / refinement of the object‘s structure
◦ definition of the object‘s behavior
◦ definition of the interaction between the objects
 Preservation of a certain level of abstraction enhances the potential of
reusability
 Categorization of objects increases locality of changes and therefore
leads to a more stable system architecture
◦ entity objects
◦ boundary objects
◦ control objects


  67
 Models of the Analysis Phase

Refining the Problem

Domain Model

Structure Model
[constructed]
Constructing the
Behavior Model

Behavior
Model
[constructed]

[else] [no additional refinements necessary]


  68
 Results of the Analysis Phase
1 Structure 1 «UML»
Model Class Diagram

* «UML»
Sequence Diagram

«UML»
*
Collaboration Diagram
Analysis Model 1 Behavior
Model «UML»
*
Statechart Diagram

«UML»
*
Activity Diagram


  69
 Structure Model

The structure model is a refinement of the

problem domain model
◦ a copy of the problem domain model is used as the basis
of a contract between client and developer

Partitioning of the Structure Model

◦ UML Packages


  70
 Example CALENDARIUM
Extract of the Class Diagram (1/2)
1
manages CALENDARIUM 1 manages

GroupOfPersons
* *{sorted}
* 1..* Calendar
User Entry *
* 1..* * is- isOpen: bool
isDirectedTo *
name partici- /visualization: Color AttachedTo
authorization pates description: String *
* visualizes
Notification 0..3 1 type: App’tmentType *
remindsOf View

Appointment Series Entry ToDoEntry

start: DateTime duration deadline: Date
duration: Time frequency
*
hyperlink [0..1]: URL 1..* {sorted}
/collidesWith 1 1
nOfAppts: Int
{xor}
* 1..* {sorted}


  71
 Example CALENDARIUM
Extract of the Class Diagram (2/2)

«control» «boundary»
C_User B_User
C_User(b:User) 1 1 B_User(b:User)
C_User() validate():bool
start() start()
finish()
0..1

«instantiate»

«instantiate» 1
«entity»
User
User()
«control»
save()
CALENDARIUM delete()


  72
 Behavioral Model
Goal

◦ Specification of the inter-object behavior

(interaction structure, responsibilities)
 interaction diagrams:
 sequence diagram
 collaboration diagram
 statechart diagram
 activity diagram

◦ Specification of the intra-object behavior

 statechart diagram

 7
Interaction Diagrams
Illustrate the communication between objects

Purpose:
◦ Specifying the realization of an operation
◦ Specifying the realization of a use case

2 Kinds:
◦ generic kind, i.e., all possible scenarios are described by means
of branching and iteration
◦ exemplary kind, i.e., one certain scenario is described

 74
Interaction Diagrams
Sequence and Collaboration Diagram
 Bothspecify the same information
 However, each emphasizes different aspects

◦ sequence diagram is “temporally”-oriented

 shows graphically the order
of messages
 does not show how to get
the receiver object

◦ collaboration diagram is “spatially”-oriented

 shows the static and dynamic relationships between
objects - the context aspect 1.1

 the order of messages is expressed by 1

means of decimal classification only 1.2

 time is no dimension on its own

 75
Interaction Diagrams
Sequence Diagram
 Objects are represented by means of vertical lines (“lifelines”)
◦ depict also the time line
◦ the horizontal ordering of the objects has no meaning
 An activation (“focus of control”) shows the period during which an
object is directly or indirectly executing an operation
 Messages between objects are denoted by means of arrows
 [Guard] specifies conditional sending of messages
: User : Calendar a1:Appointment a2:Appointment
totalDuration()
duration()
return(meetingTime)
duration()
return(total) return(meetingTime)

 76
 Interaction Diagrams
Sequence Diagram - Example
: User : Calendar a: Appointment
example insertAppt(“a1”)
new()
a1:Appointment

a2:Appointment
deleteAppt(“a2”)
delete()

totalDuration()
a = 1 .. nOfAppts
type()
return(aType)
[aType  private] duration()
return(meetingTime)
return(total)

 77
Interaction Diagrams
Collaboration Diagram
 Examples of messages (events):
◦ simple message: 2: display(x,y)
◦ nested call including
return value: 1.3.1: p:= find (specs)

◦ conditional message: [x<0] 4: invert(x,color)

◦ synchronization with other

threads and iterations:A3, B4 / C3.1*|| [i:= 1..n]: update

1.1 : meetingTime:= duration()

a1:Appointment
1 : total:= totalDuration()
: User : Calendar
1.2 : meetingTime:= duration()
a2:Appointment

 78
Interaction Diagrams
Collaboration Diagram - Example

1: insertAppt(“a1”) 1.1: new()

a1:Appointment
{new}
3: total := totalDuration()
: User : Calendar 3.1*[i=1..nOfAppts]:complete

a2:Appointment
{destroyed}
2: deleteAppt(“a2”) 2.1: delete()

3.1.2: aType := type ()

3.1.3 [aTypeprivate]: 3.1.1: a := select(i)
meetingTime := duration()
a:Appointment : Appointment

 79
Interaction Diagrams
Relationships & Roles in Collaboration Diagrams
 The kind of relationship between sender object and receiver
object may be specified (:: Sequence Diagram!)
◦ attribute «association» (default)
◦ global variable «global»
◦ local variable (temporary object) «local»
◦ parameter «parameter»
◦ self referencing «self»

readAuthorization( )
:Calendarium : User
loggedInUser
«local»

 80
 Interaction Diagrams
Collaboration Diagram - Example

redisplay()
window
:Controller :Window
«parameter» window
1: displayPositions 1.1.3.1: add(self)
(window)
wire
«self» contents {new}
«local» line
1.1*[i:=1..n]: wire: Wire :Line {new}
draw 1.1.2: create(r0,r1)
i-1 i 1.1.3: display(window)
Segment(i)
1.1.1a: r0:=position() 1.1.1b: r1:=position()

left: Bead right: Bead

[from Rumbaugh et al. 1999, p.202]

 81
 Interaction Diagrams
Numbering of Messages
 Ordering of messages is defined by means of a nested
numbering scheme

 “Decimal classification”:
◦ n.m … mth message with the realization of message n
◦ If the only differences between two or more message numbers
are the names at their end, then they may be potentially executed
in parallel:
1.1.1a can be executed at the same time as 1.1.1b
(both represent message 1.1.1)

 In case of asynchronous control flow decimal

classification is not used
 82
Interaction Diagrams
Kinds of Control Flow
 Synchronous
◦ a nested control flow,
typically realized as a
procedure call
 Return
◦ optional
 Unspecified
◦ is used if kind of control flow is not of
interest at this point in time
◦ (however, typically asynchronous)
 Asynchronous

 holds for sequence and collaboration diagrams

 8
Example CALENDARIUM
Sequence Diagram “Insert Appointment” (1/2)
: B_Calen- c : Calen- User: pa : Authorization : ca :
darium darium Class User Class Calendar

login(...) login(user,pwd)
login(user,pwd)
ok ok
new
appt storeAppt
(partic,appt)
forall pa in partic
checkAuthorization (user, pa, “write“)
authorized

forall pa in partic

checkCollision (bD, eD) checkCollision (bD, eD)

ok ok

 84
Example CALENDARIUM
Sequence Diagram “Insert Appointment” (2/2)
: B_Calen- c : Calen- User: pa : Authorization : ca : cv : Calendar
darium darium Class User Class Calendar View

d_new := new (...) d_new :

Appointment

forall pa in partic
Observer !
insertAppt(d_new)
insertAppt(d_new)
done
update( )
notify(d_new)
forall cv

 85
 Statechart Diagram
 describes
◦ the life cycle of the instances of a class
◦ the execution of an operation on an instance of a class

 models
◦ the possible states of the instances of a class
◦ the possible transitions from one state to another one
◦ the events firing transitions
◦ the operations (actions and activities) which are executed within
states or during a transition

 86
 Statechart Diagram
Kinds of Events

 CallEvent: receipt of a message: cancel

 SignalEvent: receipt of a signal: left_button_down
 ChangeEvent: a condition evaluates to true: when(x<y)
 TimeEvent: relative or absolute point in time: after(5 sec.)
cancel
“automatic transition” Canceled
Appointment
delete
start new
duration Enter Details Active

cancel () delete
delete ()
Finished
when(start+duration<=now)

 87
Statechart Diagrams
State
 State:
◦ state (in the strict sense) s
◦ final state
 Pseudostates:
◦ initial state
◦ history state, synch state, fork, join etc.
 Action and Activity:
◦ action: atomic and non-interruptible
◦ activity: complex (possibly nested statechart diagram) and interruptible
 Action / Activity within a state:
◦ entry / action action is executed when entering the state
◦ exit / action action is executed when leaving the state
◦ do / activity activity is executed, parameters are allowed
◦ event / action event is handled within the state

 88
Statechart Diagram
State Transition

 A state transition takes place, if

◦ the event occurs
◦ and the guard is true
 Default Assumptions
◦ the lack of an event corresponds to the event “activity is finished” (completion
transition)
◦ the lack of a condition corresponds to [true]
 Actions on state transitions are possible
◦ Special action: Sending a message to another object
send receiver.message()
◦ Example:
right-mouse-down (loc) [ loc in window ] / obj:= pick-obj (loc); send obj.highlight()

 89
Statechart Diagram
Example
DigitalWatch

modeButton()
inc()

“self transition” inc / hours:= hours+1 inc / min:= min+1

mode mode
Display time Button Set hours Button Set minutes
do/ display new entry/ beep entry/ beep
current time do/ display hours do/ display minutes

modeButton

 90
Statechart Diagram
Refining Statechart Diagrams
 Refinement of a state by means of a nested
statechart diagram
◦ disjoint substates
(OR-refinement) Z
exactly one substate is active in case that the
superordinate state (complex state, super state) is A
active
B

◦ parallel substates
(AND-refinement) Z
all substates are active in case that the super state
is active; A
the substates are again or-refined
B

 91
Statechart Diagram
Example “Appointment” (1/2)

cancel
Cancelled

new delete
Enter Details Active

Finished
when(start+duration<=now)

 92
 Statechart Diagram
Example “Appointment” (2/2)

Active

Occurred
when(start<=now) when(start+duration<=now)
Not Current Current

cancel
reschedule (newStart)
[not in Current] Reschedule
Fixed / start:=newStart Cancelled
do/ notify participants
and update views

 9
Statechart Diagram
History State (1/2)
 Complex states are able to remember the internal state which
had been left due to an interruption

 At a later point in time, one can go back to this internal state

by means of a transition from superordinate states via a
dummy state “H”
◦ all entry actions are executed again

 Bymeans of “H*” all states along the given nesting depth are
memorized

 9
Statechart Diagram
History State (2/2)

when(Balance < 0) Balancing

+ - [not in Frozen]
when(Balance > 0) / Balance := 0
H
Deposit(b)
/ Balance := Withdrawal(b) [not in Frozen]
Balance + b /Balance := Balance - b
Open
/ Balance := 0
Freeze
Normal Frozen
Unfreeze

 95
Statechart Diagram
Semantics of AND-Refinements

when(Balance < 0)
+/N -/N
Balancing
when(Balance > 0)
/ Balance := 0
H
Unfreeze

Unfreeze
Freeze

Freeze
Withdrawal(b) Open
/Balance := Balance - b / Balance := 0

when(Balance < 0)
+/F -/F
H*
when(Balance > 0)

Deposit(b) / Balance := Balance + b

 96
 Statechart Diagram
Stubbed State

yes
Question
no

Question
“F1“ / display help

do / pose question

“da“ “njet“

yes no

 97
 Statechart Diagram
Synch State

P1 P2

 Synchronization of control
between two concurrent regions C1 C2
 “Producer-Consumer”
 Upon activation, a token is inserted into the synch state
(at most k tokens, k = 1, 2, … *)
 Outgoing transition can fire if at least one token is available

 98
 Activity Diagram
Concepts (1/5)
 Describes a process
consisting of:
◦ actions and activities
◦ control flow
◦ input and output objects, object flow
◦ responsible objects
 Action
◦ atomic
◦ represented by an action state Define start of contract
 Activity
◦ can be further decomposed hierarchically
Check plausibility
◦ represented by a subactivity state

 99
Activity Diagram
Concepts (2/5)
 Control A [not
flow finished]
◦ order of actions / activities B
◦ represented by transition arrows
◦ no events - as soon as execution of the predecessor is finished,
execution of the successor is started
◦ guards and (send-) actions are allowed

 Responsibilities (swimlane)
◦ responsible “objects”can be assigned
◦ e.g., objects of the system to be realized, actors or organizational
units

 100
 Activity Diagram
Concepts (3/5)
 Startstate: start of an activity diagram
 End state: end of an activity diagram

 Object flow
Compute
◦ from actions to objects contract
◦ from objects to actions
◦ the current state of the object may be specified Contract
◦ in case that control flow and object flow [computed]
are identical, only the object flow is drawn
Authorize
contract

 101
Activity Diagram
Concepts (4/5)
 Guard
◦ a transition may be annotated with a guard or further actions
◦ in this case, both the execution of the predecessor must be
finished and the condition must be true in order to be able to
execute the successor

Check [OK]
Compute
plausibility contract

 Alternative Sequences
◦ either by means of mutually exclusive guards placed on the
outgoing transitions of an action or
◦ by means of dedicated decision states

 102
Activity Diagram
Concepts (5/5)
 Decision state
◦ makes alternative sequences explicit Compute
◦ complex decisions can be visualized contract
by means of decision trees
[else] [bonus > 500]
◦ outgoing transitions are required
to have mutually exclusive
guards

 Concurrency
◦ a fork denotes the starting point
of the concurrent execution of
activities/actions
◦ a join depicts the corresponding end
◦ conditional branches are possible

 10
 Activity Diagram
Example (1/2)
Claim Processing Automatic Processing Claim Check

Define start of Create

contract contract#

Attach Attach policy

insurance prod. holder

Establish
cover
Check
plausibility

 10
Activity Diagram
Example (2/2)
Claim Processing Automatic Specialized
Processing Claim Check
Compute
contract
Contract
[computed]

[else] [bonus>500]

[else] Draw [is a sample] Authorize

sample contract
{t<24h}
Release
contract

Contract Contract
[released] [authorized]

 105
Outline
 Introduction

}
 Requirements Specification
 Analysis UML Syntax
and Semantics
 Design

 Pitfalls
and Workarounds
 Roadmap to UML 2.0
 References


  106
Pitfalls & Workarounds
A (constructive) critical view
 Aggregation semantics
 Generalization semantics
◦ Static view
◦ Dynamic view
 Use Case formalization
◦ Interaction diagrams for algorithmic views
◦ Use case extension (include / extend / generalize) in I.D.
◦ Dynamic object references in sequence diagrams
 Some OCL obscenities
 Traceability of model refinement


  107
 Aggregation Semantics

Problems in UML:
◦ Weak aggregation does not bear useful
semantics
◦ “Canonical” variations of aggregation not
completely covered

 10
 Aggregation Semantics
Standard Classification
dependent independent
1 0..1
exclusive
*
shared ?
1..*
? + user specified del./propagation semantics necessary!

 Additional variants:
◦ 1 exclusive, dependent, but no delete propagation!
◦ 0..1 very specific semantics: only transition “01” allowed

 Weak aggregation is indeed weak :-)

 (Rumbaugh: “modeling placebo”)

 10
 Generalization Semantics

Problems in UML:
◦ “Canonical” variations of generalization not
completely covered
 w.r.t. static view (class diagram)
 w.r.t. dynamic view (state diagram)
◦ Properties of generalization relationships are
ambiguous,
depending on basic assumptions:
 multiple inheritance allowed?
 multiple classification allowed?
 Both allowed???

 110
 Generalization Semantics
Flavors of Inheritance
 Specification inheritance
not distinguished in UML!

◦ yields type hierarchies

◦ preconditions must not become stricter, postconditions not weaker
◦ DQueue subtype-of Stack
◦ contravariance
 Stack::push: Stack x Element  Stack
 DQueue::push: Stack x Element  Stack (possibly: DQueue)
 Specialization inheritance
◦ yields is-a hierarchies
◦ Integer is-a Rational
◦ covariance
 Rational::*: Rational x Rational  Rational
 Integer::*: Integer x Integer  Integer
«implementation»
«implementation»
 Implementation inheritance
◦ no conceptual relationship at all

  111
Generalization Semantics
Properties
 incomplete / complete (default)
◦ complete: All possible subclasses are already part of the model
◦ additional interpretation (outside UML) (with multiple classification):
Each super class instance must also belong to at least one subclass
 overlapping / disjoint (default)
◦ 2 interpretations of overlapping:
 w.r.t. multiple inheritance: two or more subclasses can have again common
subclasses (e.g. Instructor)
 w.r.t. multiple classification: an object can be instance of more than one subclass
Employee {incomplete,
{complete, Entry overlapping}
disjoint}
Technical Administrative
Appointment SerialEntry ToDoEntry Employee Employee

 112
Generalization Semantics
Inheritance of State Chart Diagrams (1/2)

class Reservation
establish consume pay
s2 s3

s4
create
s1
sendSorryLetter

Reservation
inheritance hierarchy
Reservation_ Reservation_
with_Cancel with_Insurance

 11
 Generalization Semantics
Inheritance of State Chart Diagrams (2/2)
Reservation_with_Cancel
cancel (contravariance)

Reservation
establish consume pay
s2 s3

s4
create makeInsurance
s1 s6 s7

Reservation_with_Insurance
sendSorryLetter (covariance)

UML remains silent about these alternatives!

 11
 Use Case Formalization

Use Cases need formal specifications

◦ Sequence Diagrams (SD)
◦ Collaboration Diagrams (CD)
◦ Activity Diagrams
Interaction Diagrams (SD, CD)
◦ are well suited to scenario description
◦ are not adequate for algorithmic views

(same applies for other behavioral aspects)

 115
 Alternatives (1/2)
Guarded Messages
◦ A message guard is a Boolean expression (a predicate) that indicates under what
circumstances the message can occur
◦ The guard appears in square brackets as part of the message label
◦ Multiple guarded messages within a single SD
reduce the SD’s readability considerably!
c:Customer b:Bank

transfer(rcvb, rcva, amnt)

[amnt<limit] true

[amnt >= limit] false

alternative

 116
 Alternatives (2/2)
Conditional Lifelines
◦ A conditional lifeline expresses alternative behavior of a single component
◦ Conditional lifelines typically occur in conjunction with guarded messages
and reduce an SD’s readability even further!
c:Customer b1:Bank a1:Account b2:Bank

bal:=getBal()
conditional
lifeline
[bala] transfer(rb,ra,a)

[bal<a] deposit(a-bal)
BTransfer(rcvb, rcva, amnt)

add(a-bal)

ack

 117
Repetition
The UML lets us specify loops by enclosing the section to
repeat, and by indicating (informally) the repetition
b1:Bank b2:Bank

initMultiTransfer()

for all t in transactionSet loop area

loop
condition
BTransfer(t)

ack

finishMultiTransfer()

 11
Real Life Example
CALENDARIUM SD “Insert Appointment” (excerpt)
: B_Calen- c : Calen- User: pa : Authorization : ca :
darium darium Class User Class Calendar

login(...) login(user,pwd)
login(user,pwd)
ok scope
ok
of pa?
new appt storeAppt
(partic,appt)
forall pa in partic
[authorized = checkAuthorization (user, pa, “write“)
false] authorized

forall pa in partic
? checkCollision (bD, eD) checkCollision (bD, eD)

[ok = false] ok ok

 11
Use-Case Formalization
Problems with Algorithms in Interaction Diagrams

 Decisions
◦ Where should you branch to?
◦ Message arrows pointing downwards (time dimension!)
 Iterations
◦ No multi-object in sequence diagrams
◦ Loops need pseudo-messages in collaboration diagrams : Appointment
 Class methods
◦ how to represent class methods
◦ classes seen as objects
◦ however: new is treated differently…
 Dynamic object references (e.g., pa)

 120
 Use-Case Formalization
Referencing of Use Cases (1/2)
“Probes” from OOSE are missing in UML

«include»
A B

A B
o1 o2 o3 o3 o4 o5

 121
 Use-Case Formalization
Referencing of Use Cases (2/2)

Variant borrowed from the MSC-96 standard

reference b1:Bank a:Account
SD SuccessfulWithdrawal

b1:Bank a:Account initTransfer()

withdraw(a) ref SuccessfulWithdrawal

ack endTransfer()

 122
Alternatives
Separate “alternation boxes”
◦ Each alternative has its own guard
◦ The disjunction of all guards must equal true
◦ Any one of the alternatives whose guard equals true will occur in an
execution that complies with the SD
c:Customer b1:Bank a1:Account b2:Bank

bal:=getBal()

alt: [bala]
transfer(rb,ra,a)
BTransfer(rcvb, rcva, amnt)

alt: [bal<a]
deposit(a-bal)
add(a-bal)

ack
 12
 Repetition
Use “repetition box” with guards for specifying loops
The loop guard is of any one of the following forms:
◦ loop<lb,ub> : at least lb and at most ub repetitions
◦ loop<*>: any finite number of repetitions
◦ loop<>: an infinite number of repetitions
◦ loop<g>: if g is a Boolean expression then the repetition occurs as long as g
evaluates to true

b1:Bank b2:Bank

loop<1,10>

BTransfer(t)

ack

 12
 Actions
 Use “action boxes” for specifying that a component performs a local activity,
such as an assignment to its attributes
 The activity’s position on the component’s lifeline indicates when the activity
occurs

b1:Bank a:Account

withdraw(amnt)
action symbol

bal := bal-amnt

 125