UML The Unified Modelling Language

1
UML - The Unified Modelling Language
Übung Softwareentwicklung 2für
Wirtschaftsinformatik
2
Calendarium Case

• A Calendarium-system is envisioned. The
  calendarium shall store toDo-entries and
  appointment-entries. Each entry comprises a
  description, a visual color indication and an
  type. ToDo-entries additionally have a deadline
  attached. Appointment entries have a start date
  and a duration may have an attached hyperlink for
  further information. One or more users may be
  assigned to an entry (i.e. participating or being
  responsible).
• Such entries may be also series-entries which are
  specified by a repeat frequency and a series
  duration.
• Users of the Calendarium shall be enabled to
  query entries and to manage entries, comprising
  inserting new entries, changing existing entries,
  and deleting entries. If any entry is changes all
  displayed calendarium needs to be updated and all
  participating users assigned for an entry need to
  be informed e.g. via email, via fax. The user is
  also informed when an appointment or a deadline
  is up to come.
• Different views (e.g. month, week, day) shall be
  supported.Users may configure their view on the
  Calendarium which comprises configuring access
  rights and configuring other parameters. The
  administrator may additionally administrate entry
  types and administrate users.
• Users may be grouped to user groups.
• For exchange purposes the entries can be
  exported.

3
Calendarium Beispiel

• Gesucht ist ein elektronisches Kalendersystem.
  Das Kalendarsystemsoll ToDo-Einträge und
  Termineinträge verwalten. Jeder Eintrag soll eine
  Beschreibung, eine wählbare Farbe für die Anzeige
  und eine Typisierung (z.B. Arbeit, Privat,
  Wichtig) aufweisen können. ToDo-Einträge haben
  eine Deadline bis zu der diese erledigt sein
  sollen. Terminehaben einen Startzeitpunkt und
  eine Dauer sowie einen Hyperlink auf weitere
  Informationen. Einem Eintrag können ein oder
  mehrere Benutzer zugeordnet sein. .
• Es sollen auch Serien von Einträgen möglich sein,
  die durch eine Wiederholungshäufigkeit und eine
  Seriendauer spezifiziert sind.
• Benutzer des Kalendersystems sollen Abfragen auf
  den Kalendar durchführen können sowie Einträge
  verwalten (einfügen, ändern, löschen). Wurde ein
  Eintrag geändert müssen alle Anzeigesichten auf
  den Kalender aktualisiert werden und alle
  Teilnehmer des Termins oder Verantwortliche des
  ToDo-Eintrags durch zum Beispiel eine eMail oder
  ein Fax benachrichtigt werden. Bei einer
  herannahende Deadline sollen die Benutzer
  ebenfalls informiert werden.
• Verschiedene Sichten auf den Kalender sollen
  möglich sein (z. B. Monatsansicht,
  Wochenansicht). Benutzer sollen sich ihre
  Ansichten des Kalenders konfigurieren können
  (umfasst Zugriffsrechte einstellen anderer
  Benutzer sowie weitere Parameter). Der
  Administrator darf darüber hinaus auch noch
  Termintypen und Benutzer administrieren.
• Benutzer können zu Benutzergruppen
  zusammengefasst werden.
• Zum Zwecke des Austausch können Einträge
  exportiert werden.

4
What is 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

5
Motivation... from the Method Wars to UML2
Extension and Consolidation
Essential Changes
2005
UML2
2004
Public Feedback
Action Model
UML 1.5
Industrialization
2003
Components, Profiles, Collaborations
2002
UML 1.4
2001
Public Feedback
2000
XMI
UML 1.3
1999
OCL
1998
UML 1.1
Standardization OMG, Sept. 1997
1997
UML1
Public Feedback
1996
UML 0.9
Unification
Unified Method 0.8
1995
Diverse Methods OML, Catalysis, Syntropy, etc.
Fragmentation Method Wars
Booch
OMT
OOSE
6
What is 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!

7
Views supported by UML

• Use Case View
• Use Case Diagram
• Statechart Diagram
• Interaction Diagrams

• Logical/Design View
• Class Diagram
• Statechart Diagram
• Interaction Diagrams
• Composite Structure Diagram
• Package Diagram

• Process/Concurrency View
• Class Diagram
• Statechart Diagram
• Interaction Diagrams
• Activity Diagram

• Component / Impl. View
• Component Diagram
• Statemachine Diagram
• Interaction Diagrams
• Activity Diagram

• Deployment View
• Deployment Diagram
• Statechart Diagram
• Interaction Diagrams
• Activity Diagram

8
UML Diagrams Structural Modeling
Structure Diagram
ClassDiagram
ObjectDiagram
PackageDiagram
Deployment Diagram
Minor Changes
Component Diagram
Major Changes
Composite Structure Diagram
New
9
UML Diagrams Behavioral Modeling
Major Changes
Minor Changes
Behavior Diagram
Activity Diagram
Use CaseDiagram
State Machine Diagram
Interaction Diagram
Sequence Diagram
Communication Diagram
Timing Diagram
Interaction Overview Diagram
New
10
Phase 1 Requirements Specification

• Goal is the description of the required system
  functionality from the users 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

11
Results of the Requirements Specification Phase
1
UML Use Case Diagram
Use Case Model
1
Description of Use Cases

Requirements Model
Problem Domain Model
1
1
UML Class Diagram

UI Specification
Interface Model
1
Spec. of System Interfaces

12
Results of the Requirements Specification Phase
1
UML Use Case Diagram
Use Case Model
1
Description of Use Cases

Requirements Model
Problem Domain Model
1
1
UML Class Diagram

UI Specification
Interface Model
1
Spec. of System Interfaces

13
Use Case Diagram

• 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

14
Use Case Diagram - Example
CALENDARIUM
query entry
export entries
delete entry
change entry
User
insert entry
include
include
update calendar
include
configure Program
notify participants
actor Fax-System
extend
configure parameters
configure access rights
actor E-Mail-System
administer users
administer entry types
Administrator
15
Use Case Diagrams - Partitioning into Package
System Administration
configure parameters
configure program
extend
User
extend
configure access rights
administer users
administer entry types
Adminis- trator
16
Results of the Requirements Specification Phase
1
UML Use Case Diagram
Use Case Model
1
Description of Use Cases

Requirements Model
Problem Domain Model
1
1
UML Class Diagram

UI Specification
Interface Model
1
Spec. of System Interfaces

17
Class Diagram - 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

18
Class Diagram - Identification of Attributes

• Linguistic analysis of the problem description -
  extraction of adjectives
• 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

19
Class Diagram - Identification of Operations

• Linguistic analysis of the problem description -
  extraction of verbs
• Rules of thumb
• which operations can be executed by a certain
  object
• not only the current requirements should be
  considered, but also reusability should be taken
  into account
• which events are expected
• which objects can react to these events
• which other events are raised in turn

20
Class Diagram - Associations

• 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
• Link between objects
• represents an instanceof an association

1..

attachedTo
Calendar
Appointment
21
Class Diagram - Associations
1
isCoordinatedBy

User
Appointment
class Appointment User isCoordinatedBy App
ointment(User coordinator) isCoordinatedBy
coordinator ...
class User ...
22
Class Diagram - Associations
1

User
Appointment
coordinator
coordinatedAppointments
23
Class Diagram - Associations
1

User
Appointment
coordinator
coordinatedAppointments

• class User
• CollectionltAppointmentgt coordinatedAppointments
  
• void coordinate(Appointment a)
• a.setAsCoordinator(this)
• appointments.add(a)

class Appointment User isCoordinatedBy App
ointment(User coordinator) isCoordinatedBy
coordinator setAsCoordinator(User
coordinator) isCoordinatedBy
coordinator ...
24
Class Diagram - Associations
1..
attachedTo

Calendar
Appointment

• class Calendar
• LinkedListltAppointmentgt appointments
• void add(Appointment a)
• a.addAssociateCalendar(this)
• appointments.add(a)
• void addAssociateAppointment(Appointment a)
• appointments.add(a)
• boolean removeAppointment(Appointment a)
• a.removeAssociate(this)
• appointments.remove(a)
• boolean removeAssociateAppointment(Appointment
  a)
• appointments.remove(a)
• return true

class Appointment LinkedListeltCalendargt
attachedTo void addCalendar(Calendar c)
c.addAssociate(this) appointments.add(c)
void addAssociateCalendar(Calendar c)
attachedTo.add(c) boolean
removeCalendar(Calendar c) if
(appointments.size() lt 1) return
false c.removeAssociate(this) attachedTo.rem
ove(c) return true boolean
removeAssociateCalendar(Calendar c) if
(appointments.size() lt 1) return
false attachedTo.remove(c) return true
25
Class Diagram - Associations / Roles

• Classes play roles within associations
• a single class can play more than one role

0..
1
Insurance Contract
Insurance Company
insurer
0..
refers to
married to
wife
superior
0..1
policyholder
1..
0..1
0..
0..1
0..
Employee
Person
subordinate
husband
peer
0..
married to is stillincompletely specified...
26
Class Diagram - Properties of Associations

• Exclusive Or xor
• only one of a set of possibleassociations can be
  instantiatedfor a certain object ata certain
  time
• subset

27
Class Diagram - Qualified Association

• A Qualifier is an attribute or a listof
  attributes
• whose values partition the objectsof the
  associated class in a disjointmanner
• in most cases, multiplicity is reduced to one
• Represents a property of the association

Bank
Bank

account

0..1

Person
Person
manages
1
1
User
GroupOfParticipants
groupName
Owner
name

1..
Participant
consistsOf
28
Class Diagram - Association Class
1
1
Project
Person


E1
Pr1
P1
Employment qualificationProfilehours dailyRate
E2
E3
P2
Pr2
E4


Person
Project
E1
Pr1
Employment qualificationProfilehours dailyRate
P1
E3
P2
Pr2
E4
29
Class Diagram - Weak Aggregation

• The multiplicity at the aggregate end may be gt 1
  
• 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

A
B


GroupOfPersons
User
30
Class Diagram - Composition

• The multiplicity at the aggregate end must be lt
  1
• 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

0..1

A
B


1

Annotation
Document


31
Class Diagram - 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

32
Class Diagram - Generalization

• 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
33
Class Diagram - Generalization

• 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

incomplete, overlapping
Employee
2 alternative notations
complete, disjoint
Entry
Technical Employee
Administrative Employee
SerialEntry
Appointment
ToDoEntry
34
Class Diagram - Example - Interface SMTPServer
Qsmtp
Email
Client
Supplier
SMTPServer
Email
Email (String to, String message) notify()
Qsmtp
use
mailer.open (mailbox.univie.ac.at,
25) mailer.sendmsg (CALENDARIUM,
hitz_at_acm.org, Reminder,
Meeting at 12.1.99, 1400) mailer.close()
open (String hostId, int
port25) sendmsg (String from,
String to, String subject,
String message) close() Qsmtp
() finalize()
interface SMTPServer
open (String hostId, int port) sendmsg (String
from, String to,
String subject, String
message) close()
realize
35
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 objects structure
• definition of the objects 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

36
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statemachine Diagram

Only important diagram types shown!
37
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statemachine Diagram

Only important diagram types shown!
38
Class Diagram - Example
1
1
CALENDARIUM
manages
manages
GroupOfPersons

sorted


1..

User

1..

is-AttachedTo
name authorization
partici-pates
isDirectedTo


visualizes

0..3
1

Notification
View
remindsOf
sorted

1..
1
1
/collidesWith
xor

1.. sorted
39
Package Diagram

• A package has no longer class properties as in
  UML1
• This allows a clear distinction between plain
  grouping mechanisms in terms of packages and
  software components/subsystems, incorporating
  class properties
• Introduction of a merge relationship between
  packages, instead of UML1s inheritance
  relationship
• This allows to reuse and redefine common core
  concepts to provide the basis for incremental
  system development
• Has been extensively used in the language
  architecture of UML2 to define its meta model
• Example

AssociationClasses
Kernel
Association End
Association
Class
merge
0..1
0..1
Property
0..1
2..


member End
owned Attribute
qualifier
Property
40
Results of the Analysis Phase
UML Sequence Diagram

UML Communication Diagram

Analysis Model
1
Behavior Model
UML Statemachine Diagram

41
Interaction Diagrams - Sequence Diagram

• Roles Objects play 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 objects in a certain role
  are directly or indirectly executing an operation
• Messages between objects in a certain role are
  denoted by means of arrows

User
Calendar
totalDuration()
duration()
return(meetingTime)
duration()
return(meetingTime)
return(total)
42
Sequence Diagram Combined Fragments Notation
CombinedFragments
Operators

• Combined fragment is modeled within a frame
• Kind of fragment is depicted by means of the
  operator within a pentagon(default seq)
• Operands are separated by means of dotted lines

sd Example
alt
Operand1
loop
Operand2
Operand3
43
Sequence Diagram Combined Fragments Kinds of
Operators
Alternatives Iterations
Concurrency Order
Filters Assertions
44
Sequence Diagram Interaction Use Example 1/2
sd CheckPassword
sd Delete Appointment
api Appointment
Appointment GUI
Calen- darium
loop (1,3)
valid password
ref
nj Noti- fikation
tnk Teil- nehmer
CheckPassword
check Password(pwd)
check Password(pwd)
break
invalid Password
cancel Delete
result checkPassword(pwd)
announce Cancel Delete
show (result)
showCalendar
show Calendar
delete(api)
delete(api)
user
u
45
Sequence Diagram Interaction Use Example 2/2
sd Delete Appointment
nj Noti- fication
pak Participant
api Appointment
Appointment GUI
u1 is not authorized
alt
not Authorized
announce Not Authorized
u1 is authorized
par
ref
DeleteNotification
ref
NotifyParticipants
x
x
46
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 xlt0 4 invert(x,color)
• synchronization with otherthreads and
  iterations A3, B4 / C3.1 i 1..n update

1.1 meetingTime duration()
1 total totalDuration()
Calendar
User
1.2 meetingTime duration()
47
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statemachine Diagram

48
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(xlty)
• TimeEvent relative or absolute point in time
  after(5 sec.)

cancel
Canceled
automatic transition
Appointment
delete
start duration
new
Active
Enter Details
delete
cancel () delete ()
Finished
when(startdurationltnow)
49
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statecmachine Diagram

UML Activity Diagram

50
Activity Diagram Elements of an Activity
Activity Name
precondition postcondition
...
...

• Activity
• User-defined behavior at different levels of
  granularity
• Is a directed graph comprisingnodes and edges
• Contains actions, control flow and data flow
• Can be associated with a Classifier directly or
  indirectly via a method or can exist
  autonomously
• Is initiated by an operation call or on
  Classifier instantiation
• Can have parameters, pre/postconditions and
  defines a namespace
• Action
• Corresponds to an activity in UML1 (!)
• Is atomic
• Control flows and data flows
• Determine potential flows throughout the
  activity diagram

Action2
Action1
Action4
Action3
Input parameter
Output parameter
Activity node
Activity edge
51
Activity Diagram Nodes

• Action nodes represent predefined actions
• Object nodes serve as formal in/out parameters
  and can have a central buffer function
• Control nodes
• Start and end of flows
• Initial node
• Activity end node
• Flow end node
• Alternative flows
• Decision node
• Merge node
• Concurrent flows
• Fork node
• Join node

52
Activity Diagram Decision Nodes and Join Nodes
Behavior Specification

• Decision input behavior for decision nodes
• Allows a detailed specification of the decision
  at a central place
• Arrival of a token initiates execution of
  decision behavior data token serve as parameter
• Join specification for join nodes
• For controlling when a token is passed on

Propose Appointment
Fix Appointment
true
false
decision Input Agreement of all participants?
joinSpec A and B and XltY
53
Activity Diagram Object Nodes

• An object node holds data token and is
  associated with an object flow
• Data token are the result of an action andinput
  for further actions
• Type definition and state constraints are
  optional
• Object nodes may serve as in/out-parameter
• for activities (activity parameter node)
• for action (pins)

ActivityName
ActivityName
ObjectNodeType State
Input parameter
Output parameter
ObjectNodeType State
Action Name
54
Activity Diagram Input Pins / Output Pins

• Input pin should be placed on the left hand side
  or above the action
• Direction of the object flow edge indicates kind
  of pin
• Explicit direction by means of arrows within pins
• Additional notationalvariants for pins

Action1
Action2
Action1
Action2
Action1
Action2
ONode1
ONode1
Action1
Action2
Action1 on ONode1
Action2 on ONode1
55
Activity Diagram Action Effects and Buffer Nodes

• Effects of an action
• create, read, update und delete
• Buffer nodes
• Central buffering of data token
• Transient buffer node (central buffer node)
  deletes forwarded data token
• Persistent buffer node (data store node) holds
  themand forwards duplicates
• No redundant storage of identical objects
• Explicit fetch of data token possible

Appointment
Enter Appointment
create
Deliver Invitation
Choose Participants
Participant
central Buffer ON1
Action1
Action2
data store ON1
Action1
Action2
56
Activity Diagram Example
User
CALENDARIUM
datastore User
Check UserID
else
ok
CreateAppointment
Appointment created
Appoint- ment
Participant selected
ChooseParticipants
Appoint- ment
RecordAppointment
Appointment assigned
Appoint-ment recorded
CheckCollision
57
Phase 3 Design

• Previous focus WHAT is required from the
  systemNew focus HOW should the system fulfil
  these requirements
• implementation dependent decisions are made,
  constituting the basis for refining the analysis
  model
• System design
• decomposition of the system into parts and
  distribution thereof
• concurrency and real-time aspects
• persistency mechanisms
• ...
• Detailed design
• completing the class diagram by means of
  impl.dep. concepts
• completing the class properties (e.g.
  visibilities)
• decomposing structures which cannot be
  implemented as such
• ...

58
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
59
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
60
Classes Diagram - Classes in Different Phases
Requirements Specification
Design
entity Appointment persistencepersistent
- startDate Date - startTime Time 0900 -
duration Time 0100 - description String
""
visualization() Color collidesWith (t
Appointment)
bool ...
visualization colorCode(type)
_at_ Ø(t.startDatestartDate ? (t.startTime ³
startTimeduration Ú t.startTimet.duration
startTime))
61
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
62
Component Diagram - Distribution

• 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 versa

file2. java
file1.java
I
file3. java
CompilationDependencies
file4. java
63
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
64
Deployment Diagram - Distribution

• Objects - Processes - Components - Nodes
• (bold style active objects)

Calendarium Client
Calendarium Server
internet
User Interface
access
Applet b_calendarium
access
Appointment Manager
access
Calendar Server Program
access
t1calThread
calendarium
appobj
...
DB-Server