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


 Provide a 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

 What is the UML not?
It is 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!


 The Roots of UML
 OMT - Object Modeling Technique (James
Rumbaugh et al.)
 especially suited for analysis of data intensive information systems
 among others, employment of extended Entity-Relationship diagrams
 Booch-Method (Grady Booch)
 particularly suited for modeling real-time systems and concurrent
systems
 strong relationship to programming languages (Ada)
 OOSE - Object-Oriented Software Engineering
(Ivar Jacobson)
 use case-oriented approach
 excellent support for business engineering and requirements analysis
 modeling and simulation of telecommunication systems by means of
Message Sequence Charts and SDL (Specification and Description
Language)
➨UML unifies many of their concepts and introduces
new ones
 Diagrams of UML

(1) Use Case Diagram
 (2) Class Diagram


 (3) Sequence Diagram Interaction


Diagrams
Behavior  (4) Collaboration Diagram


Diagrams
 (5) Statechart Diagram


 (6) Activity Diagram



Implementation  (7) Component Diagram


Diagrams
 (8) Deployment Diagram

 Views supported by UML
Use Case View


 Use Case Diagram

 Statechart Diagram
ew Interaction Diagrams Pr
Vi

oc
n
 Activity Diagram ■C
l es
ig ■S a ss s/C
s
e m am ■I tate Dia on
/ D
l gra agr ms nte ch
a
g ram cur
i a
c Dia Di gra
■
Ac ac r r t ren
g rt ia tiv tion Dia cy
ity
Lo ass ha D m
l c n ra
D
Dia iag m
gra
Vie
■ C tate ctio iag gra ram w
a
■ S ter ty D m m s
n i
■ I ctiv
■A 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]
Process for Introducing UML
Phases (1/2)
Requirements
Specification
Contract

Requirements
Analysis Model

[Requirements Model Analysis Model

[else] complete]

Design

[Analysis Model Design Model

[else]
complete]
Implementation

[else] [Design Model Code

complete]
Test
Process for Introducing UML
Phases (2/2)
Test

[else]
[Test successful]

[incremental development necessary]

[else]

Start of Operation

[else]
[Start of operation successful]

Employment
[Maintenance necessary] [additional functionality required]
Models of the
Requirements Specification
Phase

Constructing the
Constructing the Constructing the
Problem Domain
Use Case Model Interface Model
Model

Problem
Use Case Interface
Domain
Model Model
Model

[else]
[no further use cases]
 Results of the
Requirements Specification Phase
1 «UML»
Use Case Diagram
1 Use Case
Model
* Description of Use Cases

Requirements 1 Problem 1 «UML»

Model Domain
Class Diagram
Model

* UI Specification
1 Interface
Model
* Spec. of System Interfaces
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
Use Case Diagram
CALENDARIUM

CALENDARIUM
query
appoint
ment export
appointm
ents delete
appointm
ent
change
User appoint
insert ment
appointm
ent
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 «actor»
than one role at a time User
 actors are located outside the
system boundaries User
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?
 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:

insert
appointme
nt

of the participants. All participants must be notified of this new appointment. New appoint
Note
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
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» B
A

base use case; extending use case;

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

 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




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
Use Case Diagram
CALENDARIUM (refined, 1/2)
CALENDARIUM
query
entry export
entries delete
entry
change
User insert entry
entry «include»
«include»
«include» update
configur calenda
e notify r
Program participa «actor»
nts Fax-System
«extend»
configure
configur
paramete «actor»
e
rs E-Mail-
access administe
rights r System
administe users
r
Administrator
entry
types
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
Partitioning Use Case Diagrams
Package (1/3)
Large use case diagrams are becoming too
complex and confusing
(as is the case for all diagrams :-()
UML abstraction mechanism: Package
Criteria for partitioning:
 Functional cohesion
 Actors
«systemModel
«systemModel»
»
 ExperienceCALENDARIUM
 ....

System Appointment
Administration Manager
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»
notify
export
participa
entries
nts
«actor» «actor»
E-Mail-System Fax-System
Partitioning Use Case Diagrams
Package (3/3)

System Administration

«extend» configure
configure parameter
program s
User «extend»

administe configure
r access
users rights
administe
r
Adminis- entry
trator types
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
aUser of object
aUser (and class)
: User is
: User
underlined


Characteristics of a Class
Class attributes/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
 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
Excursion (1/3)
Identification of Classes
Linguistic analysis of the problem
description - extraction of nouns

Rules of thumb:
 elimination of irrelevant terms
 elimination of names of values
 elimination of vague terms
 identification of attributes
 identification of operations
 elimination of terms which are in fact relationships


[cf.: R.J. Abbott, Program Design by Informal

English Descriptions, CACM, Vol. 26, No. 11, 1983]
Excursion (2/3)
Identification of Attributes

Linguistic analysis of the problem description

- extraction of adjectives and
participles


Rules of thumb:
 attributes describe objects and should be neither class-
valued nor multi-valued
 derived attributes should be marked as such
 context-dependent attributes should be assigned to
associations rather than to classes
The list of attributes is usually incomplete in
the problem description
[cf.: R.J. Abbott, Program Design by Informal
English Descriptions, CACM, Vol. 26, No. 11, 1983]
 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
+collidesWith (t:
{visualization = colorCode(type)} Appointment):
startTime))
t.startTime+t.duration ≤ bool
Note ∨
(t.startTime ≥ startTime+duration ...
≅ ¬(t.startDate=startDate 
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

attachedTo
 Link between objects a1:Appointment
aCalendar :
aCalendar :
 represents an instance
Calendar
of an association attachedTo a2:Appointment
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
 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 Contract
insurer
0..*

refers to
married to

0..1 superior wife

0..* 0..1 1..* policyholder
0..* 0..1
subordinate Employee husband Person
0..* peer
specified...
incompletely
married to is still
Properties of Associations (1/2)
{sorted}

Appointment
 Calendar 1..* * /visualization
isOpen start
 {sorted} description
 duration
type

{ordered}

 1 contains *
Queue QueueItem
 {ordered}
Ordering is independent of QueueItem attributes.


Properties of Associations (2/2)
Exclusive Or {xor} SerialEntry
1
 only one of a set of possible
associations can be instantiated1 {xor}
for a certain object at
a certain time 1..* {sorted} 1..* {sorted}
 ToDoEntry Appointment

{subset}

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

coordinates
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

GroupOfParticipant 1 manages 1
groupName User
s Owner name
*
Participant 1..*

consistsOf
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(...)
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
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
Composition
The multiplicity at the aggregate end must
be <= 1 A
0..1 *
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 1a tree
Graphic * *
 Document * Annotation
Paragraph
* *
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 University
inheritance is also allowed:
Member
{overlapping}

... Student Lecturer

The model contains more

subclasses than actually
shown in this diagram Instructor
 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 overlapping}
disjoint} notations

Technical Administrative
Appointment SerialEntry ToDoEntry Employee Employee
 Generalization of Associations
 Used for restricting the possible links
between objects whose superclasses are
associated with each other

1 visualizes 0..1
Entry B_Entry

ToDoEntry B_ToDoEntry

Appointment B_Appointment
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

Array T,k: Int

length: 0..k
...
putAt (e: T, i: Int)
Alternative 1: at (i: Int): T Alternative 2:

«bind» (Point,3)
Array<Point,3>
ListOfPoints
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
Interaction Diagrams
Sequence and Collaboration Diagram
 Both specify 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
1.1
objects - the context aspect 1
 the order of messages is expressed by
1.2
means of decimal classification only
 time is no dimension on its own
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]
: User specifies conditional
: Calendar sending of
a1:Appointment messages
a2:Appointment
totalDuration()
 duration()
return(meetingTime)
duration()
return(total) return(meetingTime)
 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)
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
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
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»
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

 Statechart Diagram
Kinds of Events

CallEvent: receipt of a message:

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

cancel () delete
delete ()
Finished
when(start+duration<=now)
Statechart Diagrams
State
State:
s
 state (in the strict sense)
 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
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()

Statechart Diagram
Example
DigitalWatch

modeButton()
inc()

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

Display mode Set hours mode Set minutes

time Button Butto
entry/ beep n entry/ beep
do/ display new do/ display do/ display
current time hours minutes

modeButton
Statechart Diagram
Refining Statechart Diagrams

 Refinement of a state by means
of a nested statechart
diagram
 disjoint substates Z
(OR-refinement)
exactly one substate is active in case A
that the superordinate state (complex
state, super state) is active
B

 parallel substates
(AND-refinement)
all substates are active in case that the Z
super state is active;
the substates are again or-refined A

B
Statechart Diagram
Example “Appointment” (1/2)

cancel
Cancelled

new delete
Enter Details Active

Finished
when(start+duration<=now)
Distribution
Component Diagram
Describes SW-components and their
dependencies
 source code components (can offer interfaces - Java)
 binary code components (can offer interfaces - OLE)
 executable code components: instances are represented
by means of deployment diagrams
Packages can contain components and vice
file2. java
versa file1.java

I
Compilation
Dependencies file3. java file4. java
 Distribution
Deployment Diagram (1/3)

Calen-
Shows the actual HW configuration «internet» darium
Server
consisting of Calen-
 nodes (processors (default), I/O, ...) darium
Client *
 SW-components
 processes DB
 objects Server
 and of the communication channels between
nodes
Properties of nodes can be denoted by means of«device»
Tape
tagged values and/or stereotypes
(e.g., capacity, reliability)

Distribution
Deployment Diagram (2/3)

 Possible system configuration:

Calen-
darium
Client 1 Calen-
darium
Server

DB
Calen- Server
darium
Client 2
Distribution
Deployment Diagram (3/3)
 Objects - Processes - Components - Nodes:



Calendarium
 Client
«internet» Calendarium
User Interface System Server
 Administration
 «access»
Applet «access»
Appointment Manager
 b_calendarium
«access»
 Calendar
 «access» Server Program
t1:calThread
 DBAcces calendarium ... appobj
DB-Server
 s

(bold style: active objects)