Unified Modeling Language (UML)

Modeling for SoftwareModeling for Software
Design and UMLDesign and UML
ewË&ewËhevxshqhs„`b`wËxaewËewËhevxshqhs„`b`wËxa
xrqxrqËËwËËw

UML - OutlineUML - Outline
Introduction to Modeling
Requirements Specification
Analysis
Design
Pitfalls and Workarounds
Roadmap to UML 2.0
References
}}UML SyntaxUML Syntax
and Semanticsand Semantics

WHAT IS A MODEL?WHAT IS A MODEL?
WHY WE NEED MODELS?WHY WE NEED MODELS?
Software Engineering Model

Motivation for Analysis and DesignMotivation for Analysis and Design
Why do we model?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]

Models we may have seen …Models we may have seen …
Physics
◦ Time-Distance
Equation
Chemistry
◦ Valency-Bond
Structures
Mathematics
◦ All about models …
Geography
◦ Maps
◦ Projections
Electrical Circuits
◦ Kirchoff’s Loop
Equations
◦ Time Series Signals
FFT
◦ Transistor Models
Building Bridges
◦ Drawings
◦ Finite Element Models
Machine Design
◦ Differential Equations
!

Why do we need models?Why do we need models?
Solutions Method: Real Systems may not
be available, accessible, affordable …
◦ Represent the System as a Model
◦ Solve problems on the Model
◦ Map the solutions back to the System
Human Cognition Mechanism is limited
◦ Short Term Long Term Memory
◦ Ability to track only up to 7 entities
Models are Abstractions that help track
complexity

Implication in Program DevelopmentImplication in Program Development
A small program having just a few
variables:
◦ Is within easy grasp of an individual.
As the number of independent variables
in the program increases:
◦ It quickly exceeds the grasping power of
an individual:
 Requires an unduly large effort to master the
problem. !

Implication in Program DevelopmentImplication in Program Development
Instead of a human, if a machine could be
writing (generating) a program,
◦ The slope of the curve would be linear.
But, why does the effort-size curve
become almost linear when software
engineering principles are deployed?
◦ Software engineering principles extensively use
techniques specifically to overcome the human
cognitive limitations.

How to overcome Human CognitiveHow to overcome Human Cognitive
Limitations?Limitations?
Two important principles are
profusely used in SE:
◦Abstraction
◦Decomposition
#

AbstractionAbstraction
Simplify a problem by omitting
unnecessary details.
◦Focus attention on only one
aspect of the problem and ignore
irrelevant details.
◦Also called Model Building
$

Suppose you are asked to develop an
overall understanding of some country.
◦ Would you:
 Meet all the citizens of the country, visit
every house, and examine every tree of
the country?
◦ You would possibly only refer to various
types of maps for that country.
%

A map is:
◦ An abstract representation.
i

Several abstractions of the
same problem possible:
◦Focus on some specific aspect
and ignore the rest.
◦Different types of models help
understand different aspects of
the problem.

Abstraction -ViewsAbstraction -Views
Maps
◦ Physical
◦ Political
◦ Road Network
◦ Rivers
Electrical Design
◦ Schematic
◦ Layout
◦ Timing
Building Design
◦ Physical
 Plan
 Elevation
◦ Water Supply
◦ Electrical Distribution
◦ Sewage

For complex problems:
◦ A single level of abstraction is inadequate.
◦ A hierarchy of abstractions needs to be
constructed.
Hierarchy of models:
◦ A model in one layer is an abstraction of
the lower layer model.
◦ An implementation of the model at the
higher layer.

DecompositionDecomposition
Decompose a problem into many
small independent parts.
◦ The small parts are then taken up one
by one and solved separately.
◦ The idea is that each small part would
be easy to grasp and can be easily solved.
◦ The full problem is solved when all the
parts are solved.

DecompositionDecomposition
A popular use of decomposition
principle:
◦ Try to break a bunch of sticks tied
together versus breaking them individually.
Any arbitrary decomposition of a
problem may not help.
◦ The decomposed parts must be more or
less independent of each other.
#

Decomposition ExampleDecomposition Example
Example use of decomposition
principle:
◦You understand a book better
when the contents are organized
into independent chapters.
◦Compared to when everything is
mixed up.
$

Decomposition is HierarchicalDecomposition is Hierarchical
Decompose the WHOLE into
PARTs
Decompose each PART into
SUB-PARTs
Decompose each SUB-PART into
SUB-SUB-PARTs
%

Decomposition HierarchyDecomposition Hierarchy
ExamplesExamples
Books
◦ Chapters
 Sections
 Paragraphs
 Sentences
 …
Cars
◦ Engine
 Piston
 Cylinders
◦ Wheels
 Tyre
 Tube
◦ Steering
◦ Brakes
◦ AC
◦ Seats
◦ …
i

Modelling Relations forModelling Relations for
HierarchiesHierarchies
Abstraction Hierarchy
◦IS-A
Decomposition Hierarchy
◦ HAS-A

Motivation for Analysis and DesignMotivation for Analysis and Design
The Model as an Abstraction of the RealityThe 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

UML OVERVIEWUML OVERVIEW
Software Engineering Model

What is the UML?What is the UML?
GoalsGoals
 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 UMLWhat is the UML notnot??
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!

Objects – Core to S/W ModelsObjects – Core to S/W Models
Defines object-orientation
Has multiple viewpoints
◦ Modeling / Conceptual
◦ Philosophical
◦ Software Engineering
◦ Implementation
◦ Formal
Fundamental and most widely used UML
model

ObjectsObjects
ModelingViewpoint
◦ Conceptual Model
◦ An object has
 Identity
 Substance – Properties

ObjectsObjects
PhilosophicalViewpoint
◦ Existential Abstractions
◦ Two types of abstractions
 Objects created, used and destroyed
 Eternal Objects
 Numbers, Dates, Colors

ObjectsObjects
Software EngineeringViewpoint
◦ Data Abstractions
◦ Encapsulates
 Data
 Operations
◦ Language Types
 Object-based Languages: C
 Encapsulating Modules
 Object-oriented Languages: C++, Java
 Supports inheritance
!

ObjectsObjects
ImplementationViewpoint
◦ Contiguous Structure in Memory
◦ An Object is a
 Composite or aggregate – possessing other
objects
 At lowest level has atomic objects
◦ An object supports
 Value Semantic
 Reference Semantics

ObjectsObjects
FormalViewpoint
An object is a state machine with
◦ Finite set of states
◦ Finite set of state functions
#

Defining ObjectsDefining Objects
Characterized by a set of properties
◦ Set of Attributes and
◦ Set of Associations
 Relationships
◦ Attributes are
 Structural
 Behavioral
Description of Properties
◦ Called a Class
$

Behaviors of ObjectsBehaviors of Objects
Behavior is
◦ Services provided by an object
Services are invoked by
◦ Sending Messages
In Client-ServerView
◦ Clients request for Services
◦ Servers provide Services
◦ Contract between client and server ensures
correctness
%

Objects – Number ExampleObjects – Number Example
Complex Numbers
◦ Variables
 Real Part
 Imaginary Part
◦ Operations
 Create
 Norm
 Add / Subtract
!i

Objects – Geometry ExamplesObjects – Geometry Examples
Points
◦ Variables
 X Coordinate
 Y Coordinate
◦ Operations
 GetX / SetX
 GetY / SetY
 FindQuadrant
Lines
◦ Variables
 Point 1
 Point 2
◦ Operations
 GetPt1 / SetPt1
 GetPt2 / SetPt2
 FindLength
!

Objects – Geometry ExamplesObjects – Geometry Examples
Triangles
◦ Variables
 Point 1
 Point 2
 Point 3
◦ Operations
 GetPt1 / SetPt1
 GetPt2 / SetPt2
 GetPt3 / SetPt3
 FindPerimeter
 FindArea
Polygon
◦ Variables
 Number of Points
 Array of Points
◦ Operations
 GetPtCount
 GetPt(int i)
 FindPerimeter
 FindArea
!

Objects – Library Example 1Objects – Library Example 1
Books
◦ Variables
 Acc_no
 Title
 Author
 Publisher
 Status // Issued,Available
 Borrower // Member
◦ Operations
 Get
 Acc_no,Title,Author,
Publisher, Status
 Issue(Member)
 Return
Members
◦ Variables
 Member_ID
 Name
 Address
 Books_Issued // Array of
Books
◦ Operations
 Get
 Member_ID, Name,
Address, Books_Issued,
FreeCards
!

Objects – Library Example 2Objects – Library Example 2
Books
◦ Variables
 Acc_no, Title, Author,
Publisher, Status
◦ Operations: Get
Members
◦ Variables
 Member_ID, Name,
Address, Count of
Books_Issued
◦ Operations: Get
Borrow_Register
◦ Variables
 Borrow_ID
 Acc_no
 Member_ID
 Borrow_Date
 Operator_ID
◦ Operations
 Borrow(Books,
Members)
 Return(Books)
!

Relations between ObjectsRelations between Objects
Relation Example
Specialization-
Generalization
, IS-A
Book is-a Publication
Journal is-a Periodical
Periodical is-a Publication
Whole-Part,
HAS-A
Book has-a Title
Book has-a Publisher
Publisher has-a Address
Member-of,
HAS
Library has Member
!!

Relations between ObjectsRelations between Objects
IS-A
◦ Class or Type Hierarchy
HAS-A
◦ Composition
 Uniquely contains the component
◦ Aggregation (called ‘Weak’ Aggregation)
 Multiple containments possible
Member-of
◦ Special case of HAS-A
◦ Does not support transitivity
!

History of UMLHistory of UML
Various Methods Booch’91 OMT-1 OOSE
Booch’93 OMT-2
Unified Method 0.8
June `99
OMG accepts the UML as the official
industrial standard for software modeling
notations on 17th Nov. ‘97
Submission to OMG, Sept ‘97
Submission to OMG, Jan ‘97
Beta Version OOPSLA ‘96
WWW-June ‘96
OOPSLA ‘95
UML 0.9
UML 1.0
UML 1.1
Public
Feedback
“Method Wars”
Industrialization
Standardization
Unification
Fragmentation
UML 1.3
!#

Diagrams of UMLDiagrams of UML
(1) Use Case Diagram
(2) Class Diagram
(3) Sequence Diagram
(4) Collaboration Diagram
(5) Statechart Diagram
(6) Activity Diagram
(7) Component Diagram
(8) Deployment Diagram
Implementation
Diagrams
Interaction
Diagrams
Behavior
Diagrams
!$

Views supported by UMLViews supported by UML
Use Case ViewUse Case View
 Use Case DiagramUse Case Diagram
 Statechart DiagramStatechart Diagram
 Interaction DiagramsInteraction Diagrams
 Activity DiagramActivity Diagram
Logical/Design
View
Logical/Design
View
Class Diagram
Class Diagram
Statechart Diagram
Statechart Diagram
Interaction Diagrams
Activity Diagram
Activity Diagram
Process/Concurrency View
Process/Concurrency View
Class Diagram
Class Diagram
Statechart Diagram
Statechart Diagram
Activity Diagram
Activity Diagram
System
Deployment ViewDeployment View
Deployment DiagramDeployment Diagram
Statechart DiagramStatechart Diagram
Interaction DiagramsInteraction Diagrams
Activity DiagramActivity Diagram [after Booch et al., 1999][after Booch et al., 1999]
Component / Impl. ViewComponent / Impl. View
Component DiagramComponent Diagram
Activity DiagramActivity Diagram
!%

Ongoing ExampleOngoing Example
Calendar Manager “CALENDARIUM” (1/2)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
i

Ongoing ExampleOngoing Example
Calendar Manager “CALENDARIUM” (2/2)Calendar Manager “CALENDARIUM” (2/2)
Communication
◦ timely notification of all persons involved in an
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
Various visualization parameters may be
configured by the user

Process for Introducing UMLProcess for Introducing UML
Phases (1/2)Phases (1/2)
ContractContract
Requirements ModelRequirements Model
Analysis ModelAnalysis Model
Design ModelDesign Model
CodeCode
Requirements SpecificationRequirements Specification
AnalysisAnalysis
DesignDesign
ImplementationImplementation
TestTest
[else]
[else]
[else]
[Analysis Model
complete]
[Requirements Model
complete]
[Design Model
complete]

Process for Introducing UMLProcess for Introducing UML
Phases (2/2)Phases (2/2)
TestTest
Start of OperationStart of Operation
EmploymentEmployment
[else]
[else]
[else]
[incremental development necessary]
[Start of operation successful]
[Test successful]
[Maintenance necessary] [additional functionality required]

OutlineOutline
Introduction
Analysis
Design
References
}}UML-SyntaxUML-Syntax
and -Semanticsand -Semantics

REQUIREMENTREQUIREMENT
SPECIFICATION PHASESPECIFICATION PHASE
UML Diagrams
!

Phase 1: Requirements SpecificationPhase 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

Models of theModels of the
Requirements Specification PhaseRequirements Specification Phase
Use Case
Model
Problem Domain
Model
Interface
Model
Constructing the
Use Case Model
Constructing the
Problem Domain Model
Constructing the
Interface Model
[else]
[no further use cases][no further use cases]
#

Results of theResults of the
Requirements Specification PhaseRequirements Specification Phase
Use Case
Model
Interface
Model
Requirements
Model
1
1
1
1
*
*
«UML»
Class Diagram
«UML»
Use Case Diagram
UI Specification
Spec. of System Interfaces
Problem Domain
Model
Description of Use Cases*
1
$

USE CASE MODELUSE CASE MODEL
UML Diagrams in Requirement Specification Phase
%

Use Case ModelUse Case Model
System, Actor and Use CaseSystem, 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
#i

Use Case DiagramUse Case Diagram
CALENDARIUMCALENDARIUM
queryquery
appointmentappointment
exportexport
appointmentsappointments
deletedelete
changechange
insertinsert
UserUser
#

Actor (1/2)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»«actor»
UserUser
UserUser
#

Actor (2/2)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 fulfill 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 CaseUse 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
insertinsert
Short DescriptionShort Description::
»An appointment can be inserted for one or more»An appointment can be inserted for one or more
participants by an authorized user, who does not needparticipants by an authorized user, who does not need
to be one of the participants. All participants must beto be one of the participants. All participants must be
notified of this new appointment. New appointmentsnotified of this new appointment. New appointments
must be visualized immediately in all open calendars ofmust be visualized immediately in all open calendars of
the respective participants.«the respective participants.«
NoteNote
#

«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
Relationships Between Use Cases (1/4)Relationships Between Use Cases (1/4)
AA BB
«include»«include»
basebase use case;use case;
needs Bneeds B
includedincluded use case;use case;
is self-containedis self-contained
#!

«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
AA BB«extend»«extend»
is self-contained;is self-contained;
controls, if B is executed or notcontrols, if B is executed or not
extendingextending use case;use case;
#

◦ 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
configureconfigure
access rightsaccess rights
configureconfigure
parametersparameters
configure programconfigure program
extension pointsextension points
Modify access rightsModify access rights
Modify parametersModify parameters
«extend»
(Modify access rights)
[Access rights selected]
«extend»(Modify parameters)[Parameters selected]
##

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})
AA BB
subsub use case;use case;
needsneeds AA (gets base functionality from(gets base functionality from AA););
controls, what is executed fromcontrols, what is executed from AA
and what gets changedand what gets changed
#$

CALENDARIUM (refined, 1/2)CALENDARIUM (refined, 1/2)
queryquery
entryentry exportexport
entriesentries deletedelete
entryentry
changechange
entryentryinsertinsert
entryentry
UserUser
updateupdate
calendarcalendar
notifynotify
participantsparticipants
configureconfigure
ProgramProgram
configureconfigure
parametersparametersconfigureconfigure
administeradminister
usersusers
entry typesentry types
AdministratorAdministrator
«extend»«extend»
«actor»«actor»
E-Mail-SystemE-Mail-System
«actor»«actor»
Fax-SystemFax-System
#%

CALENDARIUM (refined, 2/2)CALENDARIUM (refined, 2/2)
insertinsert
entryentry
{abstract}{abstract}
UserUser
insertinsert
insertinsert
to-do entryto-do entry
Analogous for query/export/delete/change entryAnalogous for query/export/delete/change entry
$i

Excursion (1/4)Excursion (1/4)
Semantics of the «include»-RelationshipSemantics of the «include»-Relationship
 Problem:Where and how
should «include» be located
within the base use case ?
 Possible solution:“Probes”
from OOSE
A
B
B
AA BB
$

Semantics of the «extend»-RelationshipSemantics of the «extend»-Relationship
AA BB«extend»«extend»
“inner” of the language BETA
B
A
$

B
A
Semantics of the Generalization RelationshipSemantics of the Generalization Relationship
AA BB
“super” of the language Smalltalk
$

Generalization Relationship between ActorsGeneralization 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
AA
BB
AA BB
AA
BB
AA BB
$

Partitioning Use Case DiagramsPartitioning Use Case Diagrams
Package (1/3)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
◦ Experience
◦ ....
AppointmentAppointment
ManagerManager
System AdministrationSystem Administration
«system«systemModelModel»»
$!

«actor»«actor»
E-Mail-SystemE-Mail-System
«actor»«actor»
Fax-SystemFax-System
notifynotify
participantsparticipants
updateupdate
calendercalender
changechange
entryentry
deletedelete
entryentry
insertinsert
entryentry
queryquery
entryentry
exportexport
entriesentries
UserUser
Appointment ManagerAppointment Manager
«include»«include» «include»«include»
«include»«include» «include»«include»
$

UserUser
Adminis-Adminis-
tratortrator
configureconfigure
programprogram
usersusers
entry typesentry types
configureconfigure
configureconfigure
parametersparameters
$#

Description of Use CaseDescription 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][cf.: A. Cockburn, Goals and Use Cases. JOOP, Sept. 1997]
$$

Description of Use Case - “Insert Appointment”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.
$%

Description of Use Case - “Insert appointment”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.
%i

Description of Use Case - “Insert appointment”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.
%

PROBLEM DOMAINPROBLEM DOMAIN
MODELMODEL
%

Problem Domain ModelProblem 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”)
%

Class and ObjectClass and Object
 Class:
 Object: Name of object (and class) is underlined
UserUser
name: Stringname: String
authorization: Rightauthorization: Right
pwd: Stringpwd: String
number: Integernumber: Integer
validatePW (PW: String): boolvalidatePW (PW: String): bool
computeNumber(): IntegercomputeNumber(): Integer
Class AttributeClass Attribute
Class OperationClass Operation
AttributesAttributes
OperationsOperations
: User: User
aUseraUser
: User: User
aUseraUser
%

Characteristics of a ClassCharacteristics 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 ClassAbstract Class
 Cannot be instantiated
 Useful for generalization hierarchies only
 Factors out common properties of subclasses
 The same notation is used in order to distinguish between
abstract operations and implemented operations
EntryEntry
{abstract}{abstract}
EntryEntryoror
%

Identification of ClassesIdentification 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]
%#

Identification of AttributesIdentification of Attributes
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
%$

Identification of OperationsIdentification of Operations
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
[cf.: R.J. Abbott, Program Design by Informal
%%

Classes in Different PhasesClasses in Different Phases
/ visualization: Color/ visualization: Color
start: DateTimestart: DateTime
description: Stringdescription: String
duration: Timeduration: Time
hyperlink[0..1]: URLhyperlink[0..1]: URL
type: AppointmentTypetype: AppointmentType
numberOfAppointments: IntnumberOfAppointments: Int
- startDate: Date- startDate: Date
- startTime: Time = “09:00”- startTime: Time = “09:00”
- duration: Time = “01:00”- duration: Time = “01:00”
- description: String = - description: String =
+visualization(): Color+visualization(): Color
+collidesWith (t: Appointment):+collidesWith (t: Appointment):
boolbool
......
«entity»«entity»
{persistence=persistent}{persistence=persistent}
{visualization = colorCode(type)}{visualization = colorCode(type)}
Requirements Specification:Requirements Specification: Design:Design:
≅ ¬(t.startDate=startDate ∧
(t.startTime ≥ startTime+duration ∨
t.startTime+t.duration ≤ startTime))NoteNote
ii

Association (1/3)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 constrains 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 instance
of an association
CalendarCalendar AppointmentAppointment
attachedToattachedTo1..*1..* **
aCalendar :aCalendar :
CalendarCalendar
a1:Appointmenta1:Appointment
attachedToattachedTo
attachedToattachedTo a2:Appointmenta2:Appointment
i

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

RoleRole
Classes play roles within associations
◦ a single class can play more than one role
i
PersonPerson
InsuranceInsurance
ContractContract
InsuranceInsurance
CompanyCompany insurerinsurer
11 issued byissued by 0..*0..*
referefe
rsrs
toto
1..*1..*
0..*0..*
policyholderpolicyholder
husbandhusband
married tomarried to
EmployeeEmployee
superiorsuperior
subordinatesubordinate
0..*0..* 0..10..1 0..10..10..10..1
wifewife
married to is stillmarried to is still
incompletelyincompletely
specified...specified...
0..*0..*
0..*0..*
peerpeer

Properties of Associations (1/2)Properties of Associations (1/2)
 {sorted}
 {ordered}
Ordering is independent of QueueItem attributes.
CalendarCalendar
isOpenisOpen
/visualization/visualization
startstart
descriptiondescription
durationduration
typetype
{sorted}{sorted}
**1..*1..*
QueueQueue QueueItemQueueItem
11 containscontains **
{ordered}{ordered}
i!

Properties of Associations (2/2)Properties of Associations (2/2)
 Exclusive Or {xor}
◦ only one of a set of possible
associations can be instantiated
for a certain object at
a certain time
 {subset}
1..*1..*
ToDoEntryToDoEntry
{sorted}{sorted} 1..*1..*
{xor}{xor}
{sorted}{sorted}
SerialEntrySerialEntry
11
1
UserUser AppointmentAppointment
1..*1..* participatesparticipates **
**{subset}{subset}
coordinatescoordinates
11
participantparticipant
coordinatorcoordinator
i

Qualified AssociationQualified Association
 A Qualifier is an attribute or a list
of attributes
◦ whose values partition the objects
of the associated class in a disjoint
manner
◦ in most cases, multiplicity is reduced to one
 Represents a property of the association
BankBank
PersonPerson
account#account#
**
0..10..1
BankBank
PersonPerson
**
**
GroupOfParticipantsGroupOfParticipants UserUser
namename
groupNamegroupName
1..*1..*
11 11
**
consistsOfconsistsOf
ParticipantParticipant
OwnerOwner
managesmanages
i#

Association Class (1/2)Association Class (1/2)
 Necessary in case of m:n-associations with attributes:
 It enhances flexibility in case of 1:1 and 1:n-associations:
UserUser AppointmentAppointment**1..*
isRelocatableisRelocatable
CompanyCompany
namename
addressaddress
**
PersonPerson
namename
socSec#socSec#
addressaddress
loanloan
positionposition
EmploymentEmployment
loanloan
positionposition
11
associationassociation
classclass
{{
ParticipationParticipation
i$

Association Class (2/2)Association Class (2/2)
Object ClassObject Class ≠≠ Association ClassAssociation Class
Person Project**
Employment
qualificationProfile
hours
dailyRate
Person Project
**
Employment
qualificationProfile
hours
dailyRate
1 1
P1P1 E1E1
E3E3
E4E4
Pr1Pr1
P2P2 Pr2Pr2
E2E2
P1P1 E1E1
E3E3
E4E4
Pr1Pr1
P2P2 Pr2Pr2
i%

N-ary AssociationN-ary Association
Relationship between more than two classes
◦ navigation direction cannot be specified
Example of a ternary association:
CalendarCalendar
AppointmentTypeAppointmentTypeUserUser
**
****
associationassociation
classclass
AuthorizationAuthorization
set of [r, w, d]set of [r, w, d]
validateAuth(...)validateAuth(...)
i

AggregationAggregation
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 AggregationWeak Aggregation
The multiplicity at the aggregate end may be
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
GroupOfPersonsGroupOfPersons UserUser
**
AA BB
* *

CompositionComposition
 The multiplicity at the aggregate end must be = 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
AA BB
DocumentDocument AnnotationAnnotation
GraphicGraphic
ParagraphParagraph
* *
* *
*
1
0..1 *

Composition vs.AssociationComposition vs.Association
Rules of ThumbRules 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
 LifeTime:
◦ 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

Generalization (1/2)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 MemberUniversity Member
StudentStudent LecturerLecturer
InstructorInstructor
......
The model contains moreThe model contains more
subclasses than actuallysubclasses than actually
shown in this diagramshown in this diagram
{overlapping}{overlapping}
!

Generalization (2/2)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
EntryEntry
SerialEntrySerialEntry ToDoEntryToDoEntry
EmployeeEmployee
{complete,{complete,
disjoint}disjoint}
{incomplete,{incomplete,
overlapping}overlapping}
TechnicalTechnical
EmployeeEmployee
AdministrativeAdministrative
EmployeeEmployee
2 alternative2 alternative
notationsnotations

Example CALENDARIUMExample CALENDARIUM
Extract of the Class Diagram (1/2)Extract of the Class Diagram (1/2)
/visualization: Color/visualization: Color
type: App’tmentTypetype: App’tmentType
EntryEntry
isOpen: boolisOpen: bool
CalendarCalendar
ViewView
namename
authorizationauthorization
UserUser 1..*1..* **
partici-partici-
patespates visualizesvisualizes
**
**
is-is-
AttachedToAttachedTo
{sorted}{sorted}
** 1..*1..*
NotificationNotification
managesmanagesmanagesmanages
****
isDirectedToisDirectedTo
remindsOfremindsOf
deadline: Datedeadline: Date
ToDoEntryToDoEntry
durationduration
frequencyfrequency
Series EntrySeries Entry
hyperlink [0..1]: URLhyperlink [0..1]: URL
nOfAppts: IntnOfAppts: Int
11
{sorted}{sorted}
11
{{xorxor}}
**
**
/collidesWith/collidesWith
1..* {sorted}1..* {sorted}
1..*1..*
GroupOfPersonsGroupOfPersons
**
**
**
**
0..30..3 11
1111
#

C_User(b:User)C_User(b:User)
C_User()C_User()
start()start()
finish()finish()
««controlcontrol»»
C_UserC_User
B_User(b:User)B_User(b:User)
validate():boolvalidate():bool
start()start()
«boundary»
B_UserB_User
User()User()
save()save()
delete()delete()
««entityentity»»
UserUser
«instantiate»«instantiate»
0..10..1
11 11
11
$

Template ClassTemplate 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
Alternative 1:Alternative 1:
ArrayPoint,3ArrayPoint,3
Alternative 2:Alternative 2:
ListOfPointsListOfPoints
«bind» (Point,3)«bind» (Point,3)
ArrayArray
T,k: IntT,k: Int
length: 0..klength: 0..k
......
putAt (e: T, i: Int)putAt (e: T, i: Int)
at (i: Int): Tat (i: Int): T
i

INTERFACE MODELINTERFACE MODEL

InterfaceInterface
 Required behavior is defined by specifying the necessary
operations
◦ of a class
◦ of a component
◦ of a package
 Difference to abstract classes
◦ abstract class contains operations AND attributes
◦ abstract class can be realized by subclasses only, whereas an
interface can be realized by means of arbitrary classes
 Classes realizing a certain interface (supplier) can contain
additional operations
 Classes using an interface (clients) are not forced to
use all available operations

Interface “SMTPServer”Interface “SMTPServer”
Email (String to, String message)Email (String to, String message)
notify()notify()
EmailEmail
open (String hostId, int port)open (String hostId, int port)
sendmsg (String from,sendmsg (String from,
String to,String to,
String subject,String subject,
String message)String message)
close()close()
«interface»«interface»
SMTPServerSMTPServer
QsmtpQsmtp
+open (String hostId,+open (String hostId,
int port=25)int port=25)
+sendmsg (String from,+sendmsg (String from,
String to,String to,
String subject,String subject,
String message)String message)
+close()+close()
+Qsmtp ()+Qsmtp ()
#finalize()#finalize()
«use»«use»
mailer.open
(“mailbox.univie.ac.at”, 25);
mailer.sendmsg
(“CALENDARIUM“,
“hitz@acm.org”,
“Reminder”,
“Meeting at 12.1.99, 14:00”);
mailer.close();
QsmtpQsmtp
SMTPServerSMTPServer
EmailEmailClientClient SupplierSupplier
«realize»«realize»

Benefits of InterfacesBenefits of Interfaces
 By means of interfaces, the inheritance of
implementations can be separated from the
inheritance of interfaces
◦ frameworks especially are built on the basis of interfaces
 A class can be seen as a set of roles which are specified by
means of use cases
◦ each interface represents a role played by the class
◦ different clients use only those roles which are interesting for them
◦ by means of interfaces, different views on a class can be realized
for different clients
◦ coupling is reduced, flexibility with respect to maintenance
and extensibility is increased

Interface ModelInterface Model
Goals
◦ Specification of the user interface for each
use case / actor
not explicitly supported by UML
◦ Specification of the internal interfaces
supported by UML in terms of interfaces
!

User Interface SpecificationUser Interface Specification
Example (1/2 - Poor Man’s Prototype)Example (1/2 - Poor Man’s Prototype)
WednesdayWednesday
3030 10-1210-12
ConsultConsult
Hour (2)Hour (2)
66
1313 10-1210-12
ConsultConsult
Hour (2)Hour (2)
11-1211-12
ConsultConsult
Hour (1)Hour (1)
2020 10-1210-12
ConsultConsult
Hour (2)Hour (2)
11-1211-12
ConsultConsult
Hour (1)Hour (1)
2727 10-1210-12
ConsultConsult
Hour (2)Hour (2)
MondayMonday
2828
44
1111 MeetingMeeting
(1,2)(1,2)
1818
2525
TuesdayTuesday
2929
55
1212 14-1714-17
UMLUML
Meeting (2)Meeting (2)
1919
2626
ThursdayThursday
3131
77
1414 8-9:308-9:30
InfoSys IIInfoSys II
(1)(1)
2121 8-9:308-9:30
(1)(1)
2828 8-9:308-9:30
(1)(1)
FridayFriday
11
88 16-1816-18
C++ (2)C++ (2)
1515 16-1816-18
C++ (2)C++ (2)
2222 16-1816-18
C++ (2)C++ (2)
2929 16-1816-18
C++ (2)C++ (2)
17-18 Info-17-18 Info-
sys II Exam.sys II Exam.
SaturdaySaturday
22
99
1616
2323
3030
SundaySunday
33 *Konstan-*Konstan-
tin (2)tin (2)
1010
1717
2424
3131
GK (1)GK (1)
MH (2)MH (2)
JanuaryJanuary
19991999
TT WW
MM JJ

User Interface SpecificationUser Interface Specification
Example (2/2 - GUI Builder Prototype)Example (2/2 - GUI Builder Prototype)
#

OutlineOutline
Introduction
Analysis
Design
References
}}UMLSyntaxUMLSyntax

Phase 2:AnalysisPhase 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
!

Models of the Analysis PhaseModels of the Analysis Phase
Refining the Problem
Domain Model
Structure Model
[constructed]
[no additional refinements necessary][no additional refinements necessary][else][else]
Constructing the
Behavior Model
Behavior
Model
[constructed]

Results of the Analysis PhaseResults of the Analysis Phase
BehaviorBehavior
ModelModel
Analysis ModelAnalysis Model
StructureStructure
ModelModel
«UML»«UML»
Class DiagramClass Diagram
1111
11
«UML»«UML»
Collaboration DiagramCollaboration Diagram
**
«UML»«UML»
**
«UML»«UML»
Sequence DiagramSequence Diagram
**
«UML»«UML»
**
#

Structure ModelStructure 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
$

/visualization: Color/visualization: Color
type: App’tmentTypetype: App’tmentType
EntryEntry
isOpen: boolisOpen: bool
CalendarCalendar
ViewView
namename
authorizationauthorization
UserUser 1..*1..* **
partici-partici-
patespates visualizesvisualizes
**
**
is-is-
AttachedToAttachedTo
{sorted}{sorted}
** 1..*1..*
NotificationNotification
managesmanagesmanagesmanages
****
isDirectedToisDirectedTo
remindsOfremindsOf
deadline: Datedeadline: Date
ToDoEntryToDoEntry
durationduration
frequencyfrequency
Series EntrySeries Entry
hyperlink [0..1]: URLhyperlink [0..1]: URL
nOfAppts: IntnOfAppts: Int
11
{sorted}{sorted}
11
{{xorxor}}
**
**
/collidesWith/collidesWith
1..* {sorted}1..* {sorted}
1..*1..*
GroupOfPersonsGroupOfPersons
**
**
**
**
0..30..3 11
1111
%

C_User(b:User)C_User(b:User)
C_User()C_User()
start()start()
finish()finish()
C_UserC_User
B_User(b:User)B_User(b:User)
validate():boolvalidate():bool
start()start()
«boundary»
B_UserB_User
User()User()
save()save()
delete()delete()
««entityentity»»
UserUser
0..10..1
11 11
11
i

Partitioning of the Class DiagramPartitioning of the Class Diagram
PackagePackage
 Large class diagrams are quickly getting complex and confusing
 UML abstraction mechanism: Package
 Criteria for partitioning:
◦ Functional cohesion
◦ Informational cohesion
◦ Access control
◦ Distribution structure
◦ ....
 Elements of a package may be all kinds of UML model elements
 Visibility of elements may be restricted (+,#,-)

Dependencies between PackagesDependencies between Packages
 Elements of one package require elements of another one
◦ «access»-dependency on the
level of packages
◦ forms a graph
◦ «access»-dependencies are NOT transitive!
 Certain elements of a package require certain elements of another
one
◦ specific relationship on the element level
◦ or incorporation by means of qualification
PackagePackage
XX
PackagePackage
YY
««accessaccess»»
Class AClass A
Package XPackage X
Package XPackage X
Class AClass A
Package YPackage Y
::Class C::Class C
Class BClass B
Class DClass D
Package YPackage Y
««accessaccess»»
Class CClass CClass BClass B

Kinds of PackagesKinds of Packages
 Package
◦ represents a grouping mechanism only
 Subsystem
◦ allows also the specification of the behavior
of a package
◦ interfaces and operations may be specified
◦ icon:
 Model
◦ describes a certain view of the
system to be modeled
◦ icon: ∆
«subsystemsubsystem»
«modelmodel»
SS
PP
MM

Packages and SubsystemsPackages and Subsystems
 Interfaces offer part of the behavior of packages (subsystems!)
◦ realized by means of an arbitrary number of classes within the package
 Packages can be nested
◦ semantics is determined
by the implementation language
◦ arbitrary depth
◦ package hierarchy forms a tree
Package XPackage X
Class AClass A
Package YPackage Y
Class BClass B
Class AClass A Class BClass B
Package XPackage X
Class CClass C Class DClass D
««subsystemsubsystem»»
Package YPackage Y
II

GeneralizationGeneralization
 Generalization relationships between packages
ControllerController
DiagramDiagram
ElementsElements
DomainDomain
ElementsElements
GraphicsGraphics
CoreCore
MotifCoreMotifCore
WindowsCoreWindowsCore
MotifMotif
WindowingWindowing
SystemSystem
MSWindowsMSWindows
«subsystem»«subsystem»
EditorEditor
«access»«access»
⇒⇒
There exists at least oneThere exists at least one
generalization relationshipgeneralization relationship
between the elements of thebetween the elements of the
respective packagesrespective packages
!

PackagesPackages
«system«systemModelModel»»
User InterfaceUser Interface
B_CalendarB_Calendar B_CalendariumB_Calendarium
B_AppointmentB_Appointment ......
Appointment ManagerAppointment Manager
CalendariumCalendariumUserUser
......
CalendarCalendar

ExcursionExcursion
Employment of PackagesEmployment of Packages
 Bottom-up approach
◦ a-posteriori-decomposition of class diagrams
◦ goal is small units and intuitive groupings
◦ packages are “automatically” disjoint
 Top-down approach
◦ a-priori-allocation of use cases to packages
◦ goal is distribution of work
◦ similar concepts may occur several times in multiple packages
 Normalization of packages eliminates redundancies
◦ recognize common properties (Generalization?)
◦ factor out classes
◦ explicitly import classes and operations
#

Behavioral ModelBehavioral 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
$

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

Sequence and Collaboration DiagramSequence 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
objects - the context aspect
 the order of messages is expressed by
means of decimal classification only
 time is no dimension on its own
11
1.11.1
1.21.2
!i

Sequence DiagramSequence 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: User : Calendar: Calendar a2:Appointmenta2:Appointment
totalDuration()totalDuration()
return(total)return(total)
duration()duration()
return(meetingTime)return(meetingTime)
duration()duration()
!

return(total)return(total)
Sequence Diagram - ExampleSequence Diagram - Example
: User: User : Calendar: Calendar a: Appointmenta: Appointment
insertAppt(“a1”)insertAppt(“a1”)
new()new()
deleteAppt(“a2”)deleteAppt(“a2”)
delete()delete()
totalDuration()totalDuration()
[aType[aType ≠≠ private] duration()private] duration()
a = 1 .. nOfApptsa = 1 .. nOfAppts
type()type()
return(aType)return(aType)
exampleexample
!

Collaboration DiagramCollaboration Diagram
 Examples of messages (events):
◦ simple message: 2: display(x,y)
◦ nested call including
return value: 1.3.1: p:= find (specs)
◦ conditional message: [x0] 4: invert(x,color)
◦ synchronization with other
threads and iterations: A3, B4 / C3.1*|| [i:= 1..n]:
update
1.1 : meetingTime:= duration()1.1 : meetingTime:= duration()
: User: User
1 : total:= totalDuration()1 : total:= totalDuration()
: Calendar: Calendar
1.2 : meetingTime:= duration()1.2 : meetingTime:= duration()
!

3: total := totalDuration()3: total := totalDuration()
: User: User
Collaboration Diagram - ExampleCollaboration Diagram - Example
: Appointment: Appointment
{new}{new}
1: insertAppt(“a1”)1: insertAppt(“a1”)
2: deleteAppt(“a2”)2: deleteAppt(“a2”)
1.1:1.1: newnew()()
2.1:2.1: deletedelete()()
{destroyed}{destroyed}
3.1.1: a := select(i)3.1.1: a := select(i)
a:Appointmenta:Appointment
3.1.3 [aType3.1.3 [aType≠≠private]:private]:
meetingTime := duration()meetingTime := duration()
3.1*[i=1..nOfAppts]:complete3.1*[i=1..nOfAppts]:complete
3.1.2: aType := type ()3.1.2: aType := type ()
: Calendar: Calendar
!

Relationships Roles in Collaboration DiagramsRelationships 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»
:Calendarium:Calendarium : User: User
loggedInUserloggedInUser
«local»«local»
readAuthorization( )readAuthorization( )
!!

Collaboration Diagram - ExampleCollaboration Diagram - Example
:Controller:Controller :Window:Window
:Line:Line {new}{new}
left: Beadleft: Bead right: Beadright: Bead
windowwindow
redisplay()redisplay()
««parameterparameter» window» window
1.1.3.1: add(self)1.1.3.1: add(self)
contents {new}contents {new}
1.1.2: create(r0,r1)1.1.2: create(r0,r1)
1.1.3: display(window)1.1.3: display(window)
1: displayPositions1: displayPositions
(window)(window)
wirewire
1.1.1b: r1:=position()1.1.1b: r1:=position()1.1.1a: r0:=position()1.1.1a: r0:=position()
1.1*[i:=1..n]:1.1*[i:=1..n]:
drawdraw
Segment(i)Segment(i)
wire: Wirewire: Wire
««locallocal» line» line
i-1i-1 ii
««selfself»»
[from Rumbaugh et al. 1999, p.202][from Rumbaugh et al. 1999, p.202]
!

Numbering of MessagesNumbering 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
!#

Kinds of Control FlowKinds 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
!$

Sequence Diagram “Insert Appointment” (1/2)Sequence Diagram “Insert Appointment” (1/2)
: B_Calen-: B_Calen-
dariumdarium
c : Calen-c : Calen-
dariumdarium
User:User:
ClassClass
Authorization :Authorization :
ClassClass
ca :ca :
CalendarCalendar
pa :pa :
UserUser
login(user,pwd)login(user,pwd)
checkAuthorization (user, pa, “write“)checkAuthorization (user, pa, “write“)
forall pa in particforall pa in partic
checkCollision (bD, eD)checkCollision (bD, eD)
okok
authorizedauthorized
storeApptstoreAppt
(partic,appt)(partic,appt)
okokokok
newnew
apptappt
okok
login(...)login(...)
!%

Sequence Diagram “Insert Appointment” (2/2)Sequence Diagram “Insert Appointment” (2/2)
dariumdarium
dariumdarium
User:User:
ClassClass
ClassClass
ca :ca :
CalendarCalendar
d_new :d_new :
pa :pa :
UserUser
d_new := new (...)d_new := new (...)
insertAppt(d_new)insertAppt(d_new)
insertAppt(d_new)insertAppt(d_new)
cv : Calendarcv : Calendar
ViewView
notify(d_new)notify(d_new)
update( )update( )
forall cvforall cv
donedone
Observer !Observer !
i

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

Kinds of EventsKinds of Events
 CallEvent: receipt of a message: cancel
 SignalEvent: receipt of a signal: left_button_down
 ChangeEvent: a condition evaluates to true: when(xy)
 TimeEvent: relative or absolute point in time: after(5 sec.)
startstart
durationduration
cancel ()cancel ()
delete ()delete ()
deletedelete
deletedelete
ActiveActive
newnew
CanceledCanceled
cancel
FinishedFinished
whenwhen(start+duration=now)(start+duration=now)
Enter DetailsEnter Details
““automatic transition”automatic transition”

Statechart DiagramsStatechart Diagrams
StateState
 State:
◦ 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
ss

State TransitionState 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()

ExampleExample
modemode
ButtonButton
inc / min:= min+1inc / min:= min+1inc / hours:= hours+1inc / hours:= hours+1
modemode
ButtonButton
modeButtonmodeButton
DigitalWatchDigitalWatch
modeButton()modeButton()
inc()inc()
Display timeDisplay time
do/ displaydo/ display
current timecurrent time
Set hoursSet hours
entry/ beepentry/ beep
do/ display hoursdo/ display hours
Set minutesSet minutes
entry/ beepentry/ beep
do/ display minutesdo/ display minutes
newnew
““self transition”self transition”
!

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

Example “Appointment” (1/2)Example “Appointment” (1/2)
ActiveActive
CanceCancelledlled
cancelcancel
FinishedFinished
whenwhen(start+duration=now)(start+duration=now)
deletedelete
Enter DetailsEnter Details
newnew
#

Example “Appointment” (2/2)Example “Appointment” (2/2)
RescheduleReschedule
do/ notify participantsdo/ notify participants
and update viewsand update views
CurrentCurrent
reschedule (newStart)reschedule (newStart)
[not in Current][not in Current]
/ start:=newStart/ start:=newStart
Not CurrentNot Current
whenwhen(start=now)(start=now) whenwhen(start+duration=now)(start+duration=now)
FixedFixed
ActiveActive
OccurredOccurred
CanceCancelledlled
cancelcancel
$

History State (1/2)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
 By means of “H*” all states along the given nesting depth are
memorized
%

History State (2/2)History State (2/2)
NormalNormal FrozenFrozen
FreezeFreeze
UnfreezeUnfreeze
++ --
whenwhen(Balance 0)(Balance 0)
HH
Withdrawal(b) [not in Frozen]Withdrawal(b) [not in Frozen]
/Balance := Balance - b/Balance := Balance - b
Deposit(b)Deposit(b)
/ Balance :=/ Balance :=
Balance + bBalance + b
BalancingBalancing
[not in Frozen][not in Frozen]
/ Balance := 0/ Balance := 0
OpenOpen
#i

Semantics of AND-RefinementsSemantics of AND-Refinements
FreezeFreeze
UnfreezeUnfreeze
+/N -/N
H
Withdrawal(b)Withdrawal(b)
/Balance := Balance - b/Balance := Balance - b
BalancingBalancing
OpenOpen
+/F -/F
when(Balance 0)when(Balance 0)
when(Balance 0)when(Balance 0)H*
Deposit(b) / Balance := Balance + bDeposit(b) / Balance := Balance + b
FreezeFreeze
UnfreezeUnfreeze
#

Stubbed StateStubbed State
QuestionQuestion
yesyes
nono
QuestionQuestion
““F1“ / display helpF1“ / display help
do / pose questiondo / pose question
yesyes nono
““njet“njet“““da“da“
#

Synch StateSynch State
 Synchronization of control
between two concurrent regions
 “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
kk
P1P1 P2P2
C1C1 C2C2
#

Concepts (1/5)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
 Activity
◦ can be further decomposed hierarchically
◦ represented by a subactivity state
Define start ofDefine start of contractcontract
Check plausibilityCheck plausibility
#

 Control flow
◦ order of actions / activities
◦ 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
AA
BB
[not[not
finished]finished]
#!

 Start state: start of an activity diagram
 End state: end of an activity diagram
 Object flow
◦ from actions to objects
◦ from objects to actions
◦ the current state of the object may be specified
◦ in case that control flow and object flow
are identical, only the object flow is drawn
ContractContract
[[computedcomputed
]]
ComputeCompute
contractcontract
AuthorizeAuthorize
contractcontract
#

 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
 Alternative Sequences
◦ either by means of mutually exclusive guards placed on the
outgoing transitions of an action or
◦ by means of dedicated decision states
[OK][OK]
ComputeCompute
contractcontract
CheckCheck
plausibilityplausibility
##

 Decision state
◦ makes alternative sequences explicit
◦ complex decisions can be visualized
by means of decision trees
◦ 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
[else][else] [bonus 500][bonus 500]
ComputeCompute
contractcontract
#$

Example (1/2)Example (1/2)
Attach policyAttach policy
holderholder
AttachAttach
insurance prod.insurance prod.
EstablishEstablish
covercover
Define start ofDefine start of
contractcontract
CreateCreate
contract#contract#
Automatic ProcessingAutomatic ProcessingClaim ProcessingClaim Processing Claim CheckClaim Check
CheckCheck
plausibilityplausibility
#%

Example (2/2)Example (2/2)
ComputeCompute
contractcontract
DrawDraw
samplesample
AuthorizeAuthorize
contractcontract
{{∆∆t24h}t24h}
ReleaseRelease
contractcontract
ContractContract
[released][released]
ContractContract
[authorized][authorized]
ContractContract
[computed][computed]
[else][else] [bonus500][bonus500]
[is a sample][is a sample][else][else]
AutomaticAutomatic
ProcessingProcessing
Claim ProcessingClaim Processing SpecializedSpecialized
Claim CheckClaim Check
$i

OutlineOutline
Introduction
Analysis
Design
References
$

Phase 3: DesignPhase 3: Design
 Previous focus: WHAT is required from the system
New focus: HOW should the system fulfill 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
$

Models of the Design PhaseModels of the Design Phase
Design
Model
[refined]
Design
Model
System Design
Detailed Design
[else]
[no further refinements necessary]
$

Results of the Design PhaseResults of the Design Phase
«UML»«UML»
ComponentComponent
DiagramDiagram
«UML»«UML»
DeploymentDeployment
DiagramDiagram
ArchitecturalArchitectural
DescriptionDescription
StructuralStructural
ModelModel
BehavioralBehavioral
ModelModel
Design ModelDesign Model
11
11
11
11
11
$!

DistributionDistribution
Distribution Alternatives (1/2)Distribution Alternatives (1/2)
Distributed User
Interface
Remote User
Interface
Distributed
Application
ApplicationApplication
PresentationPresentation



DataData
ManagementManagement
$

Distribution Alternatives (2/2)Distribution Alternatives (2/2)
 Distributed
User Interface
 Remote
User Interface
 Remote DB
 Distributed DB
 Distributed
Application
Complexity Security Consistency Reusability
Distribution
Costs
Bottlenecks
$#

Component DiagramComponent 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 versa
file3. javafile3. java
file2. javafile2. javafile1.javafile1.java
Compilation
Dependencies
II
file4. javafile4. java
$$

Deployment Diagram (1/3)Deployment Diagram (1/3)
Shows the actual HW configuration
consisting of
◦ nodes (processors (default), I/O, ...)
◦ SW-components
◦ processes
◦ objects
and of the communication channels between nodes
Properties of nodes can be denoted by
means of tagged values and/or stereotypes
(e.g., capacity, reliability)
Calen-Calen-
dariumdarium
ClientClient
**
Calen-Calen-
dariumdarium
ServerServer
DBDB
ServerServer
«internet»«internet»
«device»«device»
TapeTape
$%

 Possible system configuration:
Calen-Calen-
dariumdarium
ServerServer
DBDB
ServerServerCalen-Calen-
dariumdarium
Client 2Client 2
Calen-Calen-
dariumdarium
Client 1Client 1
%i

Objects - Processes - Components - Nodes:
User Interface
Appointment Manager
Calendarium Client
Calendar
Server Program
calendarium appobj
t1:calThread
...
System Administration
DBAccessDB-Server
Applet
b_calendarium
Calendarium
Server
«internet»
«access»
«access»
«access»
«access»
%

Migration between NodesMigration between Nodes
notebooknotebook
:Customer:Customer
newCustomernewCustomer
mainServermainServer
:Customer:Customer
newCustomernewCustomer
«become»«become»
%

System DesignSystem Design
ConcurrencyConcurrency
 UML does not provide a dedicated diagram type in
order to express different aspects of concurrency
◦ instead, concurrency aspects are incorporated into existing diagram
types, in particular into behavior diagrams
 Active objects are represented using rectangles with bold
border lines
◦ in sequence diagrams, in addition, the whole lifeline is depicted as
activation
◦ in collaboration diagrams, different objects sharing a certain
process can be grouped together using a bolded rectangle
 Implementation alternatives for active objects:
◦ heavyweight processes: own address space
◦ lightweight processes (threads): common address space
%

Concurrency in Sequence Diagrams (1/2)Concurrency in Sequence Diagrams (1/2)
: Credit
Registry
: Local Credit
Agency
anUnfunded
Order
: Credit
Agency
authorizePurchase
(312779,
8144-22-7999,
$22,64)
: Credit
Authorization
new(...)
execute( )
lookup( )
authorize(...) authorize(...)
authorized( )
authorized( )authorized( )return(true)
: Funds
Request
%

Concurrency in Sequence Diagrams (2/2)Concurrency in Sequence Diagrams (2/2)
Objects may be used by multiple other objects in
parallel
An object is able to initiate parallel executions
Server
One
Server
Two
System
Clock
currentTime
currentTime
Client
Request
Handler
handleRequest
[x100] doPart
[y5] doPart
%!

Concurrency in Collaboration DiagramsConcurrency in Collaboration Diagrams
 Concurrency is expressed by different names instead
of numbers at the same level of the decimal classification
 Synchronization is expressed by message numbers
preceding a slash
:Oven:Oven:Robot:Robot
currentJobcurrentJob
:TransferJob:TransferJob
:Factory:Factory
SchedulerScheduler
:Factory:Factory
JobMqrJobMqr
jobjob
1:start(job)1:start(job)
A2,B2 / 2:completed(job)A2,B2 / 2:completed(job)
:FactoryManager:FactoryManager
A1/A1/A2:completedA2:completed
1 / A1:start(job)1 / A1:start(job)
B1/B1/B2:completedB2:completed
1 / B1:start(job)1 / B1:start(job)
[cf.: Rumbaugh
et al., 1999]
%

Real-Time (1/2)Real-Time (1/2)
 Application areas for real-time systems:
◦ telecommunication, embedded systems, mobile computing, ...
 Properties of real-time systems:
◦ reactive: reaction to events whose occurrence and order of occurrence
cannot be predicted
◦ timeliness: correct reaction within certain time intervals
◦ dynamic: system components must be reconfigurable dynamically due to
frequent changes of environmental characteristics
◦ concurrency
◦ distribution
◦ ...
Proposal for an integration of the concepts of ROOM (Real Time
Object Modeling Language, ObjecTime Inc.) in UML
http://www.objecTime.com/uml/index.html
%#

Real-Time (2/2)Real-Time (2/2)
 The time axis may contain metrics information (time
restrictions)
◦ duration for executing an operation
◦ duration for sending a message
: Local Credit
Agency
: Credit
Agency
b: authorize()
{ c.sendTime - b.receiveTime 0,1 sec }
: Funds
Request
a: authorize()
{ d.receiveTime - a.sendTime 1 sec }
{ b.receiveTime - b.sendTime 0,5 sec }
d: c:
%$

PersistencePersistence
 Decision about the type of persistence mechanism
◦ File system
◦ object-relational database system
◦ object-oriented database system
 Selecting the classes which should be made persistent
◦ mapping of these classes to the selected persistence mechanism
 Defining the transaction boundaries
 Specifying the coupling between application and database
(DB)
%%

Connecting to Relational DB - Alternative 1Connecting to Relational DB - Alternative 1
 Database access is not decoupled from application
specific behavior
 Each persistent class performs the mapping and access to
the underlying relations by itself
 Disadvantages:
◦ high coupling between
problem domain classes
and DB structure
◦ DB-specific code is intermingled
with different classes
◦ poor portability of the application,
since changes of the DB structure
influence the application and vice versa
save()
: Calendarium : Appointment
makePersistent
/* SQL-Code */
ii

 Separation of DB access and application specific behavior
◦ for each persistent problem domain class, n DB classes are implemented,
corresponding 1:1 to the DB relations
◦ these DB classes realize both, mapping and access to the DB relations
 Disadvantages:
◦ inflexible, high maintenance overhead, poor scalability
saveAppt(appt)
: Calendarium : DBAppointment: DBManager : Appointment
save (appt)
get Description
makePersistent
i

 Separation of DB access and application specific behavior
◦ there exists a generic interface to a relational DB, automatically realizing
mapping and access to the relations
 Can be realized by means of the Broker-pattern or by deriving
from a persistent class
save()
: Calendarium : Termin : DBManager
makePersistent(this)
i

Coupling Alternatives (1/2)Coupling Alternatives (1/2)
A fat client
◦ all data from the database is located at the client (Calendarium
is located at the client too)
◦ all checks are performed by the client
B thin client
◦ on every check, the client accesses the Calendarium within the
DB
◦ B1 methods are implemented on the basis of SQL-statements,
operating on relational counterparts of the objects, namely
the
tuples within the DB (Alternative 1)
B2 methods and all objects which are accessed are located
within
memory (Alternative 3)
i

Coupling Alternatives (2/2)Coupling Alternatives (2/2)
«boundaryboundary»
:X
«SQLSQL»
ClientClient ServerServerB1B1
X1X1
X2X2
X3X3
ClientClientAA
ServerServer
«useuse»
«SQLSQL»
:X1
:X2
:X3
ClientClient ServerServer
B2B2
«useuse»
«SQLSQL»
:X1
:X2
:X3
i

DB Access for “Insert Appointment”DB Access for “Insert Appointment”
: B_Calen-
darium
c : Calen-
darium
«persistent»
User :
Class
«persistent»
Authorization :
Class
«persistent»
ca : Calendar
«persistent»
u : User
checkAuthoriz (user, pa, auth)
forallpa
inpartic
checkCollision (bD, eD) checkCollision (UD, eD)
ok
authorized
storeAppt
(partic, appt)
con
forall
painpartic
con :
Connection
authorizationData
executeQuery(sqlString)
u
select(pa)
concon
new
appt
login(user,pwd)
select(“User“,pa,2)
dbmgr :
DBManager
u
new()
Alternative 3
Alternative 1
login(...)
i!

Detailed DesignDetailed Design
Completing ClassesCompleting Classes
 State variables from statechart diagrams, which were
not considered within the class diagram yet
 Operations,
◦ implementing activities of states
◦ implementing reactions to events in statechart and interaction
diagrams
◦ reacting on external events with or without state transitions
◦ for CRUD (create, read, update, delete)
◦ managing associations
 Visibility of attributes / operations
i

Realizing RelationshipsRealizing Relationships
 Mapping of associations / aggregations to oo
programming language and DB
◦ specifying the realization of relationships (global, local, etc.) within
collaboration diagrams and modifying the class diagram accordingly
◦ navigation - optimizing access paths by means of redundant
associations
◦ materializing derived attributes
◦ realizing collections of objects
 Mapping of generalizations to oo programming
language and DB
◦ multiple, extensional, overlapping
i#

Pattern - Framework - ComponentPattern - Framework - Component
Pattern:
schematic solution for an often recurring problem, emphasizing on the
collaboration between objects
Framework:
collection of reusable design decisions (patterns) of a domain, represented
by abstract and concrete classes as well as collaborations (“inversion of
control”)
Component:
reusable unit having a clearly defined offering interface and a clearly defined
required interface
i$

Patterns in UMLPatterns in UML
Example “Observer Pattern”Example “Observer Pattern”
Observer:
◦ goal is the automatic notification of dependent objects
in case of state changes of an object
◦ ensures consistency for loosely coupled objects
◦ most often used in the area of graphical user interfaces
: Calendar cv1 : CalendarView
Observer
subject observer
cv2 : CalendarView
observer
i%

Schema of the Observer PatternSchema of the Observer Pattern
addObserver (Observer)addObserver (Observer)
removeObserver (Observer)removeObserver (Observer)
notifyObservers()notifyObservers()
SubjectSubject
for all o in observersfor all o in observers
o-update(this);o-update(this);
update (Subject)update (Subject)
ObserverObserver
observerStateobserverState
update (Subject)update (Subject)
ConcreteObserverConcreteObserver
subjectStatesubjectState
getState ()getState ()
setState ()setState ()
ConcreteSubjectConcreteSubject
return subjectState;return subjectState;
observerState=subject-getState()observerState=subject-getState()
observersobservers **
subjectsubject
// change state…// change state…
notifyObservers();notifyObservers();
i

Observer Pattern in CALENDARIUMObserver Pattern in CALENDARIUM
Updating the CalendarViewsUpdating the CalendarViews
ca :ca :
CalendarCalendar
pa :pa :
UserUser
insertAppt (d_new)insertAppt (d_new)
cv1 : Calendarcv1 : Calendar
ViewView
update(this)update(this)
cv2 : Calendarcv2 : Calendar
ViewView
addObserver(this)addObserver(this)
addObserver(this)addObserver(this)
notifyObservers()notifyObservers()
update(this)update(this)
appointments( )appointments( )
appointments( )appointments( )
further
acces methods
okok
further
access methods

OutlineOutline
Introduction
Analysis
Design
References

Pitfalls WorkaroundsPitfalls Workarounds
A (constructive) critical viewA (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

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

Aggregation SemanticsAggregation Semantics
Standard ClassificationStandard Classification
 Additional variants:
◦ exclusive, dependent, but no delete propagation!
◦ very specific semantics: only transition “0 1” allowed
Weak aggregation is indeed weak :-)
(Rumbaugh:“modeling placebo”)
dependentdependent
exclusiveexclusive
sharedshared ??
independentindependent
11
**
0..10..1
11
0..10..1
?? + user specified del./propagation semantics+ user specified del./propagation semantics necessarynecessary!!
1..*1..*
!

Generalization SemanticsGeneralization 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???

Flavors of InheritanceFlavors of Inheritance
 Specification inheritance
◦ 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 inheritance
◦ no conceptual relationship at all
«implementation»«implementation»
notdistinguishedinUML!notdistinguishedinUML!
#

PropertiesProperties
 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
EntryEntry
SerialEntrySerialEntry ToDoEntryToDoEntry
{complete,{complete,
disjoint}disjoint}
EmployeeEmployee {incomplete,{incomplete,
overlapping}overlapping}
TechnicalTechnical
EmployeeEmployee
AdministrativeAdministrative
EmployeeEmployee
$

s1s1
createcreate
s2s2
establishestablish
s3s3
consumeconsume
s4s4
sendSorryLettersendSorryLetter
paypay
Inheritance of State Chart Diagrams (1/2)Inheritance of State Chart Diagrams (1/2)
class Reservationclass Reservation
inheritance hierarchyinheritance hierarchy
ReservationReservation
Reservation_Reservation_
with_Cancelwith_Cancel
Reservation_Reservation_
with_Insurancewith_Insurance
%

s1s1
createcreate
s2s2
establishestablish
s3s3
consumeconsume
s4s4
sendSorryLettersendSorryLetter
paypay
ReservationReservation
cancelcancel
Reservation_with_CancelReservation_with_Cancel
((contracontravariance)variance)
((cocovariance)variance)
Reservation_with_InsuranceReservation_with_Insurance
s6s6 s7s7
makeInsurancemakeInsurance
Inheritance of State Chart Diagrams (2/2)Inheritance of State Chart Diagrams (2/2)
UML remains silent about these alternatives!UML remains silent about these alternatives!

Use Case FormalizationUse 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)

c:Customerc:Customer b:Bankb:Bank
transfer(rcvb, rcva, amnt)transfer(rcvb, rcva, amnt)
[amntlimit] true[amntlimit] true
[amnt = limit] false[amnt = limit] false
alternativealternative
Alternatives (1/2)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:Customerc:Customer b1:Bankb1:Bank
bal:=getBal()bal:=getBal()
ackack
a1:Accounta1:Account b2:Bankb2:Bank
BTransfer(BTransfer(rcvb,rcvb, rcva,rcva, amnt)amnt)
add(add(a-bal)a-bal)
transfer(transfer(rb,ra,a)rb,ra,a)[[balbal≥≥a]a]
deposit(deposit(a-bal)a-bal)[[bala]bala]
conditionalconditional
lifelinelifeline
Alternatives (2/2)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!

b1:Bankb1:Bank b2:Bankb2:Bank
initMultiTransfer()initMultiTransfer()
finishMultiTransfer()finishMultiTransfer()
BTransfer(t)BTransfer(t)
ackack
for allfor all tt inin transactionSettransactionSetlooploop
conditioncondition
loop arealoop area
RepetitionRepetition
The UML lets us specify loops by enclosing the section to
repeat, and by indicating (informally) the repetition

Real Life ExampleReal Life Example
CALENDARIUM SD “Insert Appointment” (excerpt)CALENDARIUM SD “Insert Appointment” (excerpt)
dariumdarium
dariumdarium
User:User:
ClassClass
ClassClass
ca :ca :
CalendarCalendar
papa ::
UserUser
checkAuthorization (user, pa, “write“)checkAuthorization (user, pa, “write“)
forallforall papa in particin partic
forallforall papa in particin partic
okok
authorizedauthorized
storeApptstoreAppt
(partic,appt)(partic,appt)
okokokok
new apptnew appt
okok
login(...)login(...)
[authorized =[authorized =
false]false]
[ok = false][ok = false]
??
scopescope
of pa?of pa?

Use-Case FormalizationUse-Case Formalization
Problems with Algorithms in Interaction DiagramsProblems 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
 Class methods
◦ how to represent class methods
◦ classes seen as objects
◦ however: new is treated differently…
 Dynamic object references (e.g., pa)
: Appointment: Appointment

AA
o1o1 o2o2 o3o3
BB
o3o3 o4o4 o5o5
AA BB
««includeinclude»»
Referencing of Use Cases (1/2)Referencing of Use Cases (1/2)
“Probes” from OOSE are missing in UML
BB

Referencing of Use Cases (2/2)Referencing of Use Cases (2/2)
Variant borrowed from the MSC-96 standard
b1:Bankb1:Bank a:Accounta:Account
withdraw(a)withdraw(a)
SDSD SuccessfulWithdrawalSuccessfulWithdrawal
ackack
initTransfer()initTransfer()
endTransfer()endTransfer()
refref SuccessfulWithdrawalSuccessfulWithdrawal
referencereference

c:Customerc:Customer b1:Bankb1:Bank
bal:=getBal()bal:=getBal()
ackack
a1:Accounta1:Account b2:Bankb2:Bank
BTransfer(BTransfer(rcvb,rcvb, rcva,rcva, amnt)amnt)
add(add(a-bal)a-bal)
transfer(transfer(rb,ra,a)rb,ra,a)
deposit(deposit(a-bal)a-bal)
alt:alt: [[balbal≥≥a]a]
alt:alt: [[bala]bala]
AlternativesAlternatives
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

RepetitionRepetition
Use “repetition box” with guards for specifying loops
The loop guard is of any one of the following forms:
◦ looplb,ub : at least lb and at most ub repetitions
◦ loop*: any finite number of repetitions
◦ loop∞: an infinite number of repetitions
◦ loopg: if g is a Boolean expression then the repetition occurs as long as g
evaluates to true
b1:Bankb1:Bank b2:Bankb2:Bank
BTransfer(t)BTransfer(t)
ackack
loop1,10loop1,10
i

ActionsActions
 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
withdraw(withdraw(amnt)amnt)
bal :=bal := bal-amntbal-amnt
action symbolaction symbol

OCLOCL
 Purpose
◦ Capture properties of modelling elements not conveniently
covered by other UML constructs
◦ Documentation specification
◦ Reason about specification
◦ Execution (of a sub-language)
 Characteristics
◦ First-order specification language
 Boolean operators, quantifiers
◦ Basic datatypes included
◦ very similar to
 Algebraic specification language
 Logic language

Missing Definitions in OCLMissing Definitions in OCL
let-construct:
◦ let p = a*b
min(x,y) = if(xy) then x else y fi
in min(a,p)+min(b,p)
dataype-construct:
◦ dataype Error = Ok | ReadOnly | ReadErr |
DiskErr(String)
both from functional languages

The Russel ParadoxonThe Russel Paradoxon
 “Each type is subtype of OclAny.”
◦ Therefore, Set(OclAny) is subtype of OclAny.
 Define set R and Boolean value P:
◦ R = OclAny.allInstances -
select( x:Set(OclAny) | not x-includes(x) )
◦ P = R-includes(R)
 P is neither True nor False,
◦ as both would lead to contradiction
 Logic contains contradictions:
 Everything can be deduced

Prevention of the Russel ParadoxonPrevention of the Russel Paradoxon
No OclAny type, or
OclAny type, but no operations on it (?)
Disallowing type constructors on OclAny
Instead:
◦ Define operations for each type separately!
◦ Introduce “OclObject” as top for all Classes!
!

Traceability of Model RefinementTraceability of Model Refinement
Example 1Example 1
«refine» and «trace» dependency
◦ between 2 model elements (need some kind of n:m-relationship…)
◦ «trace» semantics not quite clear
◦ impossible for model elements on different diagrams
XX
op’()op’()
op’’()op’’()
YY
αα **11
XX
op()op()
YY
αα 1111
«trace»«trace»
«refine»«refine»

Unified Modeling Language (UML)

Unified Modeling Language (UML)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Unified Modeling Language (UML)

Semelhante a Unified Modeling Language (UML) (20)

Mais de ppd1961

Mais de ppd1961 (20)

Último

Último (20)

Unified Modeling Language (UML)

Notas do Editor