Session 5 UML The Unified Modelling Language

1
Session 5UML - The Unified Modelling Language
Übung Softwareentwicklung 2für
Wirtschaftsinformatik
Ismail Khalil IbrahimWieland Schwinger
2
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

3
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!

4
Views supported by UML

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

• Logical/Design View
• Class Diagram
• Statechart Diagram
• Interaction Diagrams
• Activity Diagram

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

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

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

after Booch et al., 1999
5
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

6
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

7
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

8
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

9
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
10
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
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
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

13
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

14
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

15
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
16
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...
17
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

18
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
19
Class Diagram - Association Class
1
1
Person
Project


E1
Pr1
P1
Employment qualificationProfilehours dailyRate
E2
E3
P2
Pr2
E4


Person
Project
E1
Pr1
Employment qualificationProfilehours dailyRate
P1
E3
P2
Pr2
E4
20
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
21
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


22
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

23
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
24
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
25
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
26
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

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

Analysis Model
1
Behavior Model
UML Statechart Diagram

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

Analysis Model
1
Behavior Model
UML Statechart Diagram

29
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
30
Packages 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 determinedby the implementation
  language
• arbitrary depth
• package hierarchy forms a tree

subsystem Package Y
Package X
I
Class C
Class D
Class B
Class A
Package X
Class A
Class B
Package Y
31
Results of the Analysis Phase
UML Sequence Diagram

UML Collaboration Diagram

Analysis Model
1
Behavior Model
UML Statechart Diagram

32
Interaction Diagrams - Sequence Diagram

• Objects are represented by means of vertical
  lines (lifelines)
• depict also the time line
• the horizontal ordering of the objects has no
  meaning
• An activation (focus of control) shows the
  period during which an object is directly or
  indirectly executing an operation
• Messages between objects are denoted by means of
  arrows
• Guard specifies conditional sending of messages

Calendar
User
totalDuration()
duration()
return(meetingTime)
duration()
return(meetingTime)
return(total)
33
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()
34
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statechart Diagram

35
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)
36
Results of the Analysis Phase
UML Class Diagram
Structure Model
1
1
UML Sequence Diagram

Analysis Model
1
Behavior Model
UML Statechart Diagram

UML Activity Diagram

37
Activity Diagram - Concepts

• 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 of contract
38
Activity Diagram- Example (1/2)
Claim Check
Automatic Processing
Claim Processing
Define start ofcontract
Create contract
Attach policyholder
Attach insurance prod.
Establish cover
Check plausibility
39
Activity Diagram - Example (2/2)
Specialized Claim Check
Automatic Processing
Claim Processing
Compute contract
Contract computed
bonusgt500
else
Authorizecontract Dtlt24h
is a sample
Draw sample
else
Release contract
Contract released
Contract authorized
40
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
• ...

41
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
42
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
43
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))
44
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
45
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
46
Results of the Design Phase
UML Component Diagram
1
UML Deployment Diagram
1
Design Model
StructuralModel
1
Architectural Description
1
Behavioral Model
1
47
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