DF14900 Software Engineering
Peter Bunus
Department of Computer and Information Science
Linköping University, Sweden
petbu@ida.liu.se
Copyright © Peter Bunus 2008
Introduction to UML
Unified Modeling Language
Product Development Process
TDDB84 Design Patterns
2
Traditional Design Flow
! Traditional Design Flow
•  Characterized by a sequential flow, iteration is expensive
•  Manual code development, paper intensive, error prone, resistant to change
•  Projects get complex to manage by the end of integration process
REQUIREMENTS
ANALYSIS
DESIGN
Documentation
Documentation
TDDB84 Design Patterns
IMPLEMENTATION
Documentation &
Code and Hardware
INTEGRATION &
TESTING
Documentation &
Testing
VALIDATION
Documentation &
Testing on Target
3
Model-Based Design
REQUIREMENTS
ANALYSIS
Documentation
Requirements &
Algorithm Spec &
Architecture Spec
DESIGN
Executable
Specification
IMPLEMENTATION
Executable Specification &
Generated Code
INTEGRATION &
TESTING
Simulation & Testing
VALIDATION
Simulation &
Testing on Target
! Model-Based Design Flow
•  Build explicit architectures of predictable systems
•  Go seamlessly from abstraction to realizations
•  Capitalize on V& activities early and all along the development flow
TDDB84 Design Patterns
4
Modeling as a Design Technique
! Testing a physical entity before building it
! Communication with customers
! Visualization
! Reduction of complexity
! Models supplement natural language
! Models support understanding, design, documentation
! Creating a model forces you to take necessary design decisions
! UML (Unified Modeling Language) is now the standard notation for
modeling software
TDDB84 Design Patterns
5
Literature on UML
! Official standard documents by OMG:
www.omg.org, www.uml.org
! Current version is UML 2.1.2 (2007-11-04)
! OMG documents: UML Infrastructure Specification, UML Superstructure
specification
! Books
TDDB84 Design Patterns
6
UML Diagram Types
! Modeling (logical) structure of software:
•  Static view: Class diagram
•  Design view: Structure diagram, collaboration diagr., component d.
•  Use case view: Use case diagram
! Modeling behavior of software:
•  Activity view: Activity diagram
•  State machine view: State machine diagram
•  Interaction view: Sequence diagram, communication diagram
! Modeling physical structure of software
•  Deployment view: Deployment diagram
! Modeling the model, and extending UML itself
•  Model management view: Package Diagram
! Profiles
TDDB84 Design Patterns
7
UML Diagram Types
! Class Diagrams
•  Class diagrams are the backbone
of almost every object oriented
method, including UML. They
describe the static structure of a
system.
! Package Diagrams
•  Package diagrams are a subset of
class diagrams, but developers
sometimes treat them as a
separate technique. Package
diagrams organize elements of a
system into related groups to
minimize dependencies between
packages.
TDDB84 Design Patterns
8
UML Diagram Types
! Object Diagrams
•  Object diagrams describe the static
structure of a system at a particular
time. They can be used to test
class diagrams for accuracy.
! Use Case Diagrams
•  Use case diagrams model the
functionality of system using actors
and use cases.
TDDB84 Design Patterns
9
UML Diagram Types
! Sequence Diagrams
•  Sequence diagrams describe
interactions among classes in terms
of an exchange of messages over
time.
! Collaboration Diagrams
•  Collaboration diagrams represent
interactions between objects as a
series of sequenced messages.
Collaboration diagrams describe
both the static structure and the
dynamic behavior of a system.
TDDB84 Design Patterns
10
UML Diagram Types
!
Statechart Diagrams
•  Statechart diagrams describe the
dynamic behavior of a system in
response to external stimuli. Statechart
diagrams are especially useful in
modeling reactive objects whose states
are triggered by specific events.
! Activity Diagrams
•  Activity diagrams illustrate the
dynamic nature of a system by
modeling the flow of control from
activity to activity. An activity
represents an operation on some
class in the system that results in a
change in the state of the system.
Typically, activity diagrams are
used to model workflow or business
processes and internal operation.
TDDB84 Design Patterns
11
UML Diagram Types
! Component Diagrams
•  Component diagrams describe the
organization of physical software
components, including source
code, run-time (binary) code, and
executables.
! Deployment Diagrams
•  Deployment diagrams depict the
physical resources in a system,
including nodes, components, and
connections.
TDDB84 Design Patterns
12
Use-Case Modeling
! A use-case is:
•  “… a particular form or pattern or exemplar of usage, a scenario that begins
with some user of the system initiating some transaction of sequence of
interrelated events.”
Jacobson, m fl 1992: Object-oriented software engineering. Addison-Wesley
TDDB84 Design Patterns
13
Use-Case Diagram
Buy a cup of coffee
CoffeeDrinker
Actor: a user of
the system in a
particular role.
Can be human
or system.
Detail of use-case
TDDB84 Design Patterns
A CoffeeDrinker approaches the machine
with her cup and a coin of SEK 5. She
places the cup on the shelf just under the
pipe. She then inserts the coin, and
presses the button for coffee to get coffee
according to default settings. Optionally
she might use other buttons to adjust the
strength and decide to add sugar and/or
whitener. The machine processes the
coffee and rings a bell when it is ready.
The CoffeeDrinker takes her cup from
the shelf.
14
Use-Case Diagram for the Coffee Machine
Buy a cup of
coffee
CoffeeDrinker
Get coin in
return
Service
Collect coins
Pour hot water
TDDB84 Design Patterns
Clean the
Machine
Add substances
System boundary
TeaDrinker
CoffeeMachine
Brew a can of
coffee
Porter
15
Relations Between Use-Cases
Clean the
machine
<<include>>
Open machine
Service
Stereotype: extended
classification of meaning
Please, keep as simple
as possible.
TDDB84 Design Patterns
Collect coins
<<include>>
Reuse
<<extend>>
Add change
Separating scenarious
(often conditional)
16
Identifying classes: noun analysis
A CoffeeDrinker approaches the
machine with her cup and a
coin of SEK 5. She places the
cup on the shelf just under the
pipe. She then inserts the coin,
and presses the button for
coffee to get coffee according
to default settings. Optionally,
she might use other buttons to
adjust the
strength and decide to add
sugar and/or whitener. The
machine processes the coffee
and rings a bell when it is
ready. The CoffeeDrinker takes
her cup from the shelf.
TDDB84 Design Patterns
• machine – real noun handled by the
system
• cup – unit for beverage
• coin – detail of user and machine
• shelf – detail of machine
• pipe – detail of machine
• button– handled by the system
• sugar – detail of coffee
• whitener – detail of coffee
• cup of coffee – handled by the system
• indicator – not discovered
17
Recommended Book
TDDB84 Design Patterns
18
The Single Class Model
CoffeeCustomer
name
name: String
attribute
numberOfCoins() : Integer
buy ( c : CupOfCoffee )
TDDB84 Design Patterns
operations
19
Associations Between Classes
association
CoffeeCustomer
0..*
multiplicity
TDDB84 Design Patterns
buys
0..*
CupOfCoffee
A multiplicity can be:
•  an exact number
•  a range of numbers
•  unspecified number denoted by *
20
Extended Class Model
CoffeeCustomer
Porter
TDDB84 Design Patterns
0..*
0..*
buys
buys
0..*
0..*
CupOfCoffee
CanOfCoffee
21
Revised Class Model
CoffeeCustomer
0..*
buys
0..*
CupOfCoffee
Generalisation
association
Porter
TDDB84 Design Patterns
0..*
buys
0..*
CanOfCoffee
22
Class model with navigability
CoffeeCustomer
buys
0..*
0..*
CupOfCoffee
Generalisation
association
Porter
TDDB84 Design Patterns
0..*
buys
0..*
CanOfCoffee
23
Class Model with Inheritance and Abstract Classes
CoffeeCustomer
Abstract class
(cannot be instantiated,
only extended/specialized)
pay( c: coin )
IndividualCustomer
getCup()
TDDB84 Design Patterns
Porter
getCan()
pay() method is inherited
from CoffeeCustomer
24
Class Model With Agregation
Aggregation: part-of relationship
Machine
1
1
Interface
TDDB84 Design Patterns
1
1
1
CoinHandler
1
Brewer
25
The coffee machine class model
Interface
1
buys
CoffeeCustomer
0..* 0..*
Porter
TDDB84 Design Patterns
byus
0..1 0..*
CoinHandler
Brewer
1 1
1
CupOfCoffee
CanOfCoffee
1
makes
0..* 1
1
machine
Even small models take
space. You need good
drawing tools and a
large sheet.
26
Classes and Objects
Classes:
CoffeeCustomer
0..*
buys
0..*
CupOfCoffee
Objects:
Kristian:
CoffeeCustomer
buys
c1: CupOfCoffee
buys
c1: CupOfCoffee
TDDB84 Design Patterns
27
Reasoning About Arbitrary Objects
Like this:
aCoffeeCustomer:
CoffeeCustomer
buys
theCupOfCoffee:
CupOfCoffee
buys
: CupOfCoffee
...or simply like this:
: CoffeeCustomer
TDDB84 Design Patterns
28
Sequence Diagram
: Interface
Message
: CoffeeCustomer
insertCoin
machineReady
Life line of object
pressButton(b1)
time
TDDB84 Design Patterns
pourCoffee
29
More relations between classes
1..*
10..*
Topic
1
1..*
Encylopedia
Board
row:{1,2,..8}
column:{1,2,..8}
1
is a copy of
Copy
TDDB84 Design Patterns
Link
0..*
1..*
{xor}
1..*
is a copy of
0..*
Volume
1
Square
Book
aggregation
composition
Stronger form of
aggregation: Composite has
sole respon- sibility for
managing its parts, e.g.
allocation / deallocation
qualified association
constraint
Journal
30
Classes and objects
Classes:
CoffeeCustomer
0..*
buys
0..*
CupOfCoffee
Objects:
Kristian:
CoffeeCustomer
buys
c1: CupOfCoffee
buys
c1: CupOfCoffee
TDDB84 Design Patterns
31
Sequence Diagram with Several Objects
: Interface
: CoinHandler
: Brewer
: CoffeeCustomer
A
{C-A < 5s}
insertCoin
litIndicators
pressButton(b1)
C
pourCoffee
TDDB84 Design Patterns
transport
coinAccepted
warmUp
makeOrder(o1)
pourCoffee
32
State Machine Diagram
For class CoinHandler:
message
checking
start state marker
this object
falseCoin()/returnCoin(self)
insertCoin()/checkCoin(self)
state
event, causing
transition
TDDB84 Design Patterns
idle
action, reaction
to the event
33
Activity Diagram
! Graph
•  Nodes are activities (actions)
–  Method invocations, operations, sending / receiving messages, handling events, creating /
accessing / modifying / deleting objects, variables …
–  Data flow by input and output parameter pins
•  Edges are control flow transitions
•  To some degree dual to the state diagram
! Might be refined to a low-level specification;
cf. control flow graph (~ compiler IR)
! A Petri Net
•  Interpretation by moving tokens along edges
•  Models concurrency by multiple tokens for current state
•  Fork / join for synchronization
! Models real-world workflows
TDDB84 Design Patterns
34
Activity Diagram
initial node
insert coin
decision
[no]
coin accepted?
fork
final node
[yes]
brew coffee
add hot water
to adjust strength
add sugar/whitener
join
pour coffee
TDDB84 Design Patterns
35
Other Features
! Comments
! Constraints in OCL (Object Constraint Language)
! Profiles: Collections of stereotypes for specific domains, e.g. Realtimeprofile for UML
•  Customize (specialize) UML elements, e.g. associations
•  Can introduce own symbols
! MOF (Meta-Object Facility):
•  UML is specified in UML
•  Powerful mechanism for extending UML by adding new language elements
TDDB84 Design Patterns
36
UML Summary
! UML – the standard for modeling software
! Modeling before/during design, precedes coding
! Different diagrams for different views
! Model a software system only partially,
focus on a certain aspect and/or part at a time
! Problem: Maintaining consistency across diagrams
! Tools
! Trend towards more detailed modeling
•  Stepwise refinement
•  executable UML : UML 2 is almost a programming language…
•  UML is customizable and extendible: Profiles, MOF
! Trend towards automatized partial generation of models and code from
models (MDA – model-driven architecture)
TDDB84 Design Patterns
37
! Comments
! Constraints in OCL (Object Constraint Language)
! Profiles: Collections of stereotypes for specific domains, e.g. Realtimeprofile for UML
•  Customize (specialize) UML elements, e.g. associations
•  Can introduce own symbols
! MOF (Meta-Object Facility):
•  UML is specified in UML
•  Powerful mechanism for extending UML by adding new language elements
TDDB84 Design Patterns
38