UML
Unified Modeling Language
UML
© Wolfgang Pelz 2000-04
1
Chapter One
Introduction
UML
© Wolfgang Pelz 2000-04
2
District Module
Order Initiated
Application Server
Semi-Auto Fill
Order
Requested
Central-Office Module
Order Approved
Database Server
Delivery Status
Sign-Shop Module
Order Filled
Figure 4 Data Flow of Sign Orders
UML
© Wolfgang Pelz 2000-04
3
Engineering and Blueprints
• standard notation
• communication tool
UML
© Wolfgang Pelz 2000-04
4
History
•
•
•
•
•
CASE Tools: Automation of Software Development
People-to-People
People-to-Computer
Rational Software (An IBM Company)
Rational Rose / MS Visio:
Converting UML-Diagrams-to-Programs
• OMG: Object Management Group
UML
© Wolfgang Pelz 2000-04
5
History
•
•
•
•
UML
Booch: Booch Method
Rumbaugh: OMT (object modeling tech.)
Jacobson: OOSE (OO software engrg.)
Three amigos: UML
© Wolfgang Pelz 2000-04
6
History
• UML: an open standard controlled by OMG
• UML 1.0 (1997)
• UML 2.0 (2004)
UML
© Wolfgang Pelz 2000-04
7
Meta-Model
• a diagram that defines the notation to be
used in the modeling language
UML
© Wolfgang Pelz 2000-04
8
UML supported diagrams
• class
• object
• use case
• interaction
» component
• package
• deployment
–
–
–
–
communication
sequence
collaboration
timing
• activity
• state/statechart
UML
© Wolfgang Pelz 2000-04
9
Brief Overview
• class - set of classes, interfaces,
collaboration, relationships
• object - set of objects and their relationships
• use case - description of functionality
provided by system along with actors and
their connection to the use case
UML
© Wolfgang Pelz 2000-04
10
Overview (cont.)
• interaction - set of objects and their
relationships including messages
• state/statechart - a state machine showing
states, transitions, events, and activities
• activity - statechart sequential flow of
activities
• component - physical structure of code in
terms of code components
UML
© Wolfgang Pelz 2000-04
11
Overview (cont.)
• deployment - physical architecture of
hardware and software in the system
• package - shows packages of classes and
dependencies among them
– grouping mechanism
– form of class diagram
– also called subsystem
UML
© Wolfgang Pelz 2000-04
12
Organization of Diagrams
domain expert
• use case
• activity
• interaction
UML
system designer
• class
• component
• deployment
• state
• package
© Wolfgang Pelz 2000-04
13
Another Organization
static
• class
• component
• package
• deployment
UML
dynamic
• use case
• interaction
• state
• activity
© Wolfgang Pelz 2000-04
14
Another Organization
UML
© Wolfgang Pelz 2000-04
15
Model Terminology
• user model view - problem and solution
from the perspective of the users
• structural model view - static or structural
aspects of a problem and solution
• behavioral model view - dynamic or
behavioral aspects; interactions or
collaborations among problem and solution
elements
UML
© Wolfgang Pelz 2000-04
16
Model Terminology
• implementation model view - structural and
behavioral aspects of the solution’s
realization
• environment model view - structural and
behavioral aspects of the domain in which a
solution must be realized
UML
© Wolfgang Pelz 2000-04
17
Language versus Method
• A (software engineering) method is composed of a language
and a process.
• UML is a language, not a method, since it has no notion of
process
• process can be:
UML
© Wolfgang Pelz 2000-04
18
UML
© Wolfgang Pelz 2000-04
19
Terminology
• inception - a few days’ work to decide if a
few months of elaboration is worth it
• elaboration - risk assessment, about 1/5 of
project time; includes planning based on use
cases; generates a commitment schedule
• construction - composed of iterations that
include refactoring, frameworks & patterns
• transition - beta testing, optimizing, training
UML
© Wolfgang Pelz 2000-04
20
Refactoring
the process of changing the internal structure
of a program or system to make it easier to
understand or change while maintaining its
functionality
UML
© Wolfgang Pelz 2000-04
21
Frameworks & Patterns
• frameworks are reusable designs of all or
part of a software system described by a set
of abstract classes and the way instances of
those classes collaborate
• patterns are common designs that have
repeating themes
UML
© Wolfgang Pelz 2000-04
22
Chapter Three
Class Diagram
UML
© Wolfgang Pelz 2000-04
23
Class Diagram
• static view of a system in terms of classes
and relationships among the classes
– associations
– subtypes
• typically done in parallel with interaction
diagrams
• a more graphical alternative to CRC cards
UML
© Wolfgang Pelz 2000-04
24
Important Questions
(Finding classes)
• Is there information to be stored/analyzed?
• Do external systems exist?
• Are there patterns, class libraries,
components, etc?
• Must the system handle devices?
• Are there organizational parts (business
model)?
• Do actors have roles to play in the system?
UML
© Wolfgang Pelz 2000-04
25
Common Uses
• Objective: provide a view of services the
system should provide to its end user
• model the vocabulary of a system
• model simple collaborations
• model a logical database schema
UML
© Wolfgang Pelz 2000-04
26
Terminology
• association: a description of a related set of
links between objects of two classes
• subtype: “is a” or “is a kind of”
• generalization: relationship between a more
general and a more specific element - see
subtype
UML
© Wolfgang Pelz 2000-04
27
Terminology (cont.)
• dependency: relationship where a change in
the independent element affects the
dependent element
• refinement: relationship between two
descriptions of the same thing, but at
different levels of abstraction
UML
© Wolfgang Pelz 2000-04
28
Terminology (cont.)
• Aggregation: association specifying a whole-part
relationship between the aggregate (whole) and a
component (part). An aggregation may not have
any components and a component may not belong
to any aggregation.
• composition: special form of aggregation (a
component must belong to a composition and only
to one composition)
– strong ownership
– coincident lifetime of parts and whole
UML
© Wolfgang Pelz 2000-04
29
Notation
UML
© Wolfgang Pelz 2000-04
30
More Notation
UML
© Wolfgang Pelz 2000-04
31
Aggregation/Composition
UML
© Wolfgang Pelz 2000-04
32
Example
UML
© Wolfgang Pelz 2000-04
33
Levels of Abstraction
• conceptual model: class name
– associations are conceptual relationships
• specification model: above + behavior
– associations and responsibilities
• implementation model: above + state
– probably too low-level for design stage
UML
© Wolfgang Pelz 2000-04
34
Another Example
UML
© Wolfgang Pelz 2000-04
35
Associations
• Describe relations between classes
• associations have roles (given at the end of
the association) which have multiplicities
• associations have navigability
– A sends a message to B
– A creates an instance of B
– A needs to maintain a connection with B
• navigability is identified from collaboration
diagrams
UML
© Wolfgang Pelz 2000-04
36
Associations (cont.)
• navigability in one direction is termed unidirectional association and has an arrow
• two-way navigability is bi-directional
association and has no arrow
• an association with no arrow could also
mean that the direction is unknown
• bidirectional requires inverse relationship
f ( f -1(y)) = y
UML
f -1( f (x)) = x
© Wolfgang Pelz 2000-04
37
Operation Signatures
visibility name (parameters) : return type
optional
optional
+ public
# protected
- private
• Example:
+ getData (pos : Position) : Data
UML
© Wolfgang Pelz 2000-04
38
Operations & Methods
• Operation
– something invoked on an object which in turn
is implemented by a method
• Method (in coding not design method)
– body of the procedure
• polymorphism forces a distinction between
the two (all siblings have the same
operation but different methods)
UML
© Wolfgang Pelz 2000-04
39
Steps to create a Class Diagram
• Identify classes using the interaction
diagram and place them in the class diagram
• get attributes from the conceptual model
and the method names from the interaction
diagram
• add type information and associations based
on attribute visibility
• add navigability arrows and dependencies
UML
© Wolfgang Pelz 2000-04
40
Another Example
UML
© Wolfgang Pelz 2000-04
41
Cautions
• start small
• perspective should match activity
– analysis: conceptual model
– software: specification model
• don’t go to details too early
UML
© Wolfgang Pelz 2000-04
42
Dependency Relationship
• One element (of any kind, including classes,
use cases, etc.) has knowledge of another
element
• if one element changes, the other might
have to change as well
• differs from plain attribute visibility which
uses regular association line and a
navigability arrow
UML
© Wolfgang Pelz 2000-04
43
Example revisited
UML
© Wolfgang Pelz 2000-04
44
Example with Dependency
UML
© Wolfgang Pelz 2000-04
45
Interface
• Interface is a class of abstract/pure virtual
functions.
• All functions in the interface are public.
• Interface cannot be used to instantiate
objects.
• There is no data members in an interface
class.
• UML: use <<interface>> to prefix the class
name.
UML
© Wolfgang Pelz 2000-04
46
Abstract Class
• An abstract class has one or more
abstract/pure virtual functions.
• An abstract class cannot be used to
instantiate objects.
• An abstract class can contain data members.
• UML: use Abstract to prefix the class name.
UML
© Wolfgang Pelz 2000-04
47
Examples
Figures in UML Distilled.
UML
© Wolfgang Pelz 2000-04
48
Chapter 6
Object Diagrams
UML
© Wolfgang Pelz 2000-04
49
Object Diagrams
•
•
•
•
A snapshot of the objects in a system at a point in time.
Also called instance diagrams.
Useful of showing object connections (not interactions)
Can be thought of as collaboration/communication
diagram without messages.
• Naming convention (did not change as sequence diagram
did):
UML
© Wolfgang Pelz 2000-04
50
UML
© Wolfgang Pelz 2000-04
51
Object Diagrams (try this example)
class Pet { // define a class
protected: string name; // protected members can be accessed by child classes
public:
Pet() {name = "";} // default constructor
Pet(string nm){name = nm;} // constructor
string getName() {return name;} // to be inherited by child classes
//virtual method, to be overridden
virtual string speak() const { return “’I can't speak.’”; }
};
...
int main() {
vector<Pet *> pets;
pets.push_back(new Dog("Midnight"));
pets.push_back(new Cat("Ginger"));
pets.push_back(new Pet("Dummy"));
}
UML
© Wolfgang Pelz 2000-04
52
Chapter 9
Use Case Diagram
UML
© Wolfgang Pelz 2000-04
53
Use Case Diagram
• For capturing the functional requirements of a
system.
• Typical interaction between user and system
– captures some user-visible function
– achieves a discrete goal for the user
note the distinction between the user goal and
system interaction in which system interaction is
the low-level work that ultimately achieves the
user goal
UML
© Wolfgang Pelz 2000-04
54
Notation
UML
© Wolfgang Pelz 2000-04
55
An Example (UML 1.3)
UML
© Wolfgang Pelz 2000-04
56
Another Example (UML 1.1)
UML
© Wolfgang Pelz 2000-04
57
Common Uses
• to model the context of a system
– system, actors, and their interactions with it
• to model the requirements of a system
– what system should do
– independent of how it is done
– point of view outside of system
UML
© Wolfgang Pelz 2000-04
58
Caution
• it is easy to get too low-level
A use case is a relatively large end-to-end
process description that typically includes
many steps or transactions; it is not
normally an individual step or activity in a
process.
– Larman [1998] Applying UML and Patterns
UML
© Wolfgang Pelz 2000-04
59
Steps
• capture normal case first
• for every step, ask:
“What can go wrong”
“How might this work differently”
• each variation is plotted as an extension
• common behavior can be encapsulated in
another use case to be used by other cases
UML
© Wolfgang Pelz 2000-04
60
Steps (cont.)
• after creating the diagram, write a generic
scenario (called a use case description)
which is a series of sentences describing
each step in the interaction
• Each step in a use case is an element of the
interaction between an actor and the system.
• use case description can be used to generate
specific scenarios and interaction diagrams
UML
© Wolfgang Pelz 2000-04
61
Scenario
• a thread through a use case
• a sequence of steps describing an
interaction between a user and a system.
• A use case is a set of scenarios tied together
by a common user goal.
UML
© Wolfgang Pelz 2000-04
62
Exercise
• Produce a use case diagram for an ATM
UML
© Wolfgang Pelz 2000-04
63