Selic - An Overview of UML 2-0

®
IBM Software Group
An Overview of UML 2.0

Bran Selic
IBM Distinguished Engineer
IBM Rational Software – Canada
bselic@ca.ibm.com
Clic
k to
DISCLAIMER
The technical material described here is still

under development and is subject to
modification prior to full adoption by the
Object Management Group
2 IBM Software Group |

The Essence of MDA
! Support for model-driven development through open
industry standards
Abstraction Automation
MDA
Open
Standards

The Languages of MDA
! Set of modeling languages for specific purposes
UML
UML
“bootstrap”
“bootstrap” General
General Real -Time
Real-Time
Standard
Standard UML
UML profile
profile
For
For general
general OO
OO
MetaObject
MetaObject modeling
modeling
Facility EAI
EAI profile
profile
Facility (MOF)
(MOF)
MOF
MOF Common
Common
“core”
“core” Warehouse
Warehouse
Metamodel Software
Software
Metamodel (CWM)
(CWM)
process
process profile
profile
AA modeling
modeling language
language For
For exchanging
exchanging
for
for defining
defining modeling
modeling information
information
languages
languages about
about business
business
data
data etc.
etc.
etc.
etc.
Contents
! A critique of UML 1.x

! Requirements for UML 2.0
! UML 2.0 architecture
! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

UML: The Foundation of MDA
3Q2004
UML 2.0 (MDA)

UML
UML 1.5
1.5
1Q2003
2001
UML
UML 1.4
1.4 (action
(action semantics)
semantics)
1998
UML
UML 1.3
1.3 (extensibility)
(extensibility)
1997
UML 1.1 (OMG Standard)

1996
Rumbaugh Booch Harel Jacobson
Foundations
Foundations ofof OO
OO ((Nygaard,
Nygaard, Goldberg,
Goldberg, Meyer,
Meyer,
Stroustrup , Harel, Wirfs - Brock, Reenskaug
Stroustrup, Harel, Wirfs-Brock, Reenskaug,…),…)
1967

UML 1.x: What Went Right
! Timeliness (meeting a real need)
! Emphasis on semantics as opposed to notation
" model-based approach (versus view-based)
" detailed semantic specifications
! Higher-level abstractions beyond most current OO
programming language technology
" state machines and activity diagrams
" support for specifying inter-object behavior (interactions)
" use cases
! Customizability (extensibility)

Traditional Approach to Views in Modeling
! Multiple, informally connected views
" Combined in the final (integration) phase of design
View 1 View 2
?
UML Approach: Single Model
! Views are projections of a complete model
" Continuous integration of views with dynamic detection of
inconsistencies
View 1 View 2
Well-formedness
rules defined by the P2
UML metamodel Pn
P1 Mapping rules defined by
System the UML specification
model

The Model and the System
modeledBy
system
system Computer
model Computer
model Model
Model
repository
repository
P2
P2
Pn
Pn
0110110 10110
P1
P1 modeledBy 0110110
10100 10110
0100111
0110110 10110
System
System
10100 0100111
0110110 10111
10100 0100111
0110110 10111
model
model 0110110 10111
“meaning”
“meaning” of
of the
the
model
model (semantics)
(semantics)
The “4-Layer” Architecture
01011
<sawdust>
<sawdust>
01011
<2
<2 tons>
tons>
<lard>
<lard>
01011
Real Objects
<Ben&Jerry’s>
<Ben&Jerry’s> <5
<5 tons>
tons> (computer memory,
(M0)
run-time environment)
«modeledBy» «modeledBy» «modeledBy»
Customer
Customer CustomerOrder
CustomerOrder Model (M1)
id
id item
item (model repository)
quantity
quantity
«specifiedBy» «specifiedBy»
Class
Class Association
Association ... Meta-Model (M2 = UML,
(modeling tool) CWM)
«specifiedBy»
Class(MOF)
Class(MOF) ... Meta-Meta-Model (M3 = MOF)
(modeling tool)

Specializing UML
! Avoiding the PL/I syndrome (“language bloat”)
" UML standard as a basis for a “family of languages”
Using built-in
extensibility
mechanisms:
UML Standard 1.x profiles,
stereotypes, etc.
Real-Time UML
Real-Time UML for EDOC …..etc.

UML 1.x: What Went Wrong?
! Inadequate semantics definition
"" Vague
Vague or
or missing
missing (e.g.,
(e.g., inheritance,
inheritance, dynamic
dynamic semantics)
semantics)
"" Informal
Informal definition
definition (not
(not suitable
suitable for
for code
code generation
generation or
or executable
executable models)
models)
! Does not fully exploit MDD potential of models
"" E.g.,
E.g., “C++
“C++ in
in pictures”
pictures”
! Inadequate modeling capabilities
"" Business
Business and
and similar
similar processes
processes modeling
modeling
"" Large-scale
Large-scale systems
systems
"" Non-functional
Non-functional aspects
aspects (quality
(quality of
of service
service specifications)
specifications)
! Too complex
"" Too
Too many
many concepts
concepts
"" Overlapping
Overlapping concepts
concepts
! No diagram interchange capability
! Not fully aligned with MOF
"" Leads
Leads to
to model
model interchange
interchange problems
problems (XMI)
(XMI)

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Sources of Requirements
! MDA (retrofit)
" Semantic precision
" Consolidation of concepts
" Full MOF-UML alignment
! Practitioners
" Conceptual clarification
" New features, new features, new features…
! Language theoreticians
" My new features, my new features, my new features…
" Why not replace it with my modeling language instead?
! Dilemma: avoiding the “language bloat” syndrome
Formal RFP Requirements
1) Infrastructure – UML internals

" More precise conceptual base for better MDA support
2) Superstructure – User-level features
" New capabilities for large-scale software systems
" Consolidation of existing features
3) OCL – Constraint language
" Full conceptual alignment with UML
4) Diagram interchange standard
" For exchanging graphic information (model diagrams)

Infrastructure Requirements
! Precise MOF alignment
" Fully shared “common core” metamodel
! Refine the semantic foundations of UML (the UML
metamodel)
" Improve precision
" Harmonize conceptual foundations and eliminate semantic
overlaps
" Provide clearer and more complete definition of instance
semantics (static and dynamic)
! Improve extension mechanisms
" Profiles, stereotypes
" Support “family of languages” concept
OCL Requirements
! Define an OCL metamodel and align it with the UML
metamodel
" OCL navigates through class and object diagrams ⇒ must
share a common definition of Class, Association, Multiplicity,
etc.
! New modeling features available to general UML users
" Beyond constraints
" General-purpose query language

Diagram Interchange Requirements
! Ability to exchange graphical information between tools
" Currently only non-graphical information is preserved during
model interchange
" Diagrams and contents (size and relative position of diagram
elements, etc.)

Superstructure Requirements (1 of 2)
! More direct support for architectural modeling
" Based on existing architectural description languages
(UML-RT, ACME, SDL, etc.)
" Reusable interaction specifications (UML-RT protocols)
! Behavior harmonization
" Generalized notion of behavior and causality
" Support choice of formalisms for specifying behavior
! Hierarchical interactions modeling
! Better support for component-based development
! More sophisticated activity graph modeling
" To better support business process modeling
Superstructure Requirements (2 of 2)
! New statechart capabilities
" Better modularity
! Clarification of semantics for key relationship types
" Association, generalization, realization, etc.
! Remove unused and ill-defined modeling concepts
! Clearer mapping of notation to metamodel
! Backward compatibility
" Support 1.x style of usage
" New features only if required

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Standardization Process
! Multiple competing submissions (5)
" Most involved consortia of companies representing both UML
tool vendors and UML users
" One prominent (800-lb gorilla) submission team (“U2P”) with
most of the major vendors (Rational, IBM, Telelogic, ...) and
large user companies (Motorola, HP, Ericsson…)
! Over time:
" Some submissions lapsed
" Some submissions were merged into the U2P
" Currently there is just one submission

Approach to Evolving UML 2.0
! Evolutionary rather than revolutionary
! Improved precision of the infrastructure
! Small number of new features
! New feature selection criteria
" Required for supporting large industrial-scale applications
" Non-intrusive on UML 1.x users (and tool builders)
! Backward compatibility with 1.x

Language Structure
! A core language + a set of optional “sub-languages”
" Defined in three separate compliance levels Multiple
Multiple levels
levels of
of
compliance
compliance
Complete
Complete Level
Level
State Structured Activities Interactions Flows
Detailed
Machines Classes and
Actions
Components
Intermediate
Intermediate Level
Level
MOF Profiles OCL
Basic
Basic Level
Level
Basic UML
(Classes, Basic behavior, Internal structure, Use cases…)
UML Infrastructure

UML-MOF Alignment
! Shared conceptual base
" MOF: language for defining modeling languages
" UML: general purpose modeling language
UML
UML Superstructure
Superstructure
MOF
MOF “Superstructure”
“Superstructure”
UML
UML «import»
«import» MOF
MOF
Infrastructure
Infrastructure
Library
Library

Infrastructure Library – Metamodel Structure
! Shared by MOF, UML, and other languages
Boolean,
Boolean, Integer,
Integer,
String,
String, ...
...
Primitive
Primitive Types
Types
«import»
«import» Basic
Basic definition
definition
«import»
«import» of
of Class
Class concept
concept
Namespace,
Namespace,
Classifier,
Classifier,
Relationship,
Relationship,
Abstractions
Abstractions Generalization,
Generalization, Basic
Basic
…
…
«import»
«import»
Extended
Extended notion
notion
of
of Class,
Class,
Association,
Association, «import»
«import»
Constructs
Constructs Profiles
Profiles

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Class Diagram Semantics
! Represent relationships between instances of classes
0..* 0..*
Company Person
employer employee
Formal (set theoretic) interpretation:
Set of all Set of all

Companies Link <C1, P2> Persons
... Cn
Cn Pm
Pm ...
P1
C3
C3 P1
C2 P2
P2
C2
C1
C1 P3
P3
Set: employee(s) of C1

Generalization Semantics
! Subclasses = specialized subsets of parent
! Subclass inherits all features of the parent and may add
its own
! Relationship between classes
Set of all instances of

Shape Shape
position : Point ... sp

sp
s3
s3
... sn
sn
s2
s2
s1
s1
Ellipse Polygon Spline

Association Specialization
! Also used widely in the definition of the UML metamodel
" Avoids covariance problems
/owner /accounts
{union}
owner {union}
accounts
Customer
Customer Account
Account
0..1
*
company accounts
Corporate
Corporate Corporate
Corporate
Customer
Customer 1 * Account
Account
{subsets {subsets
owner} accounts}
Private owner accounts Private
Private Private
Customer
Customer 1 0..5 Account
Account
{subsets {subsets
owner} accounts}

Example: Classifier Definition
! Constructed from a Ownership
Ownership
basic set of primitive
Element
Element
concepts
«import»
Namespace
Namespace
Element Classifiers
Classifiers
Element
Namespace
Namespace
NamedElement
NamedElement
name
name :: String
String NamedElement
NamedElement Classifier
Classifier
«import»
Feature
Feature
Namespace
Namespace
Kinds of Classifiers
! The following are kinds of ! Kinds of Behavior
Classifier in UML 2.0: " Activity
" Association (including " Interaction
AssociationClass)
" State Machine
" Class (including structured
classes) " Protocol State Machine
" Component
" Collaboration
" Interface
" Data Type
" Use Case
" Signal
" Behavior !
" etc.
Infrastructure: Consolidation of Concepts
! The re-factoring of the UML metamodel into fine-grained
independent concepts
" Eliminates semantic overlap
" Provides a better foundation for a precise definition of
concepts and their semantics
" Conducive to MDD

Package Merge: Motivation
! In some cases we would like to modify a definition of a class
without having to define a subclass
" To retain all the semantics (relationships, constraints, etc.) of the
original
Library
Library
Customer
Customer
1
*
Customer
Customer Account
Account
name:
name: String
String
name:
name: String
String
Customer Slightly MyCustomer

MyCustomer
Customer Slightly extended
extended
definition
definition of
of the
the age:
name:
name: String
String Customer age: Integer
Integer
Customer class
class
age:
age: Integer
Integer
Package Merge: Semantics
! Optional incremental definition of concepts
Library
Library
1
*
Customer
Customer Account
Account
name:
name: String
String
«merge»
Extend
Extend
Customer
Customer
age:
age: Integer
Integer

Package Merge: Metamodel Usage
! Enables common definitions for shared concepts with the ability
to extend them according to need
" E.g. MOF and UML definitions of Class
Infrastructure
Infrastructure
Library
Library UML
UML
«merge» 0..1
*
Class
Class Class
Class Behavior
Behavior
MOF
MOF
«merge»
Class
Class
xmi
xmi (( ))
UML 2.0: Run-Time Semantics
Activities
State
Machines ...
Interactions
ActionSemantics
(Communications)
Basic Structural Concepts

Metamodel Description of Objects
Element
NamedElement
(from Namespaces)
Object
Object (from Ownerships)
owningInstance owningSlot
InstanceSpecification Va lueS pe ci fic at ion
{subsets owner} slot * {subsets owner} val ue
Slot (from Expres sions)
1 {subsets {ordered,
0..1 *
ownedElement} subsets
ownedElement}
StructuralFeature
definingFeature (from StructuralFeatures)
classifier
Classifier
1..* (from Classifiers)
inst ance 1
ValueSpecification
(from Expressions)
Object
Object Identifier
Identifier
InstanceValue

Basic Structural Elements
! Values
"" Universal,
Universal, unique,
unique, constant
constant
"" E.g.
E.g. Numbers,
Numbers, characters,
characters, object
object identifiers
identifiers (“instance
(“instance value”)
value”)
! “Cells” (Slots/Variables)
"" Container
Container for
for values
values or
or objects
objects
"" Can
Can be
be created
created and
and destroyed
destroyed dynamically
dynamically
"" Constrained
Constrained byby aa type
type
"" Have
Have identity
identity (independent
(independent ofof contents)
contents)
! Objects (Instances)
"" Containers
Containers ofof slots
slots (corresponding
(corresponding to
to structural
structural features)
features)
"" Just
Just aa special
special kind
kind of
of cell
cell
! Links
"" Tuples
Tuples of
of object
object identifiers
identifiers
"" May
May have
have identity
identity (i.e.,
(i.e., some
some links
links are
are objects)
objects)
"" Can
Can be
be created
created and
and destroyed
destroyed dynamically
dynamically
How Things Happen in UML
! In UML, all behavior results from the actions of (active) objects
Obj1 Obj2
Object
behavior
s1 s1 (e.g., statechart)
s2 s2
Obj3
s1
s2
Inter-
Inter-object
behavior
(interaction)
How Things Happen in UML
! An action is executed by an object
" May change the contents of one or more variables or slots
" If it is a communication (“messaging”) action, it may:
• Invoke an operation on another object
• Send a signal to another object
• Either one will eventually cause the execution of a procedure on the
target object…
• …which will cause other actions to be executed, etc.
" Successor actions are executed
• Determined either by control flow or data flow

Active Object Definition
! From the spec:
An active object is an object that, as a direct
consequence of its creation, [eventually] commences to
execute its classifier behavior [specification], and does
not cease until either the complete behavior is executed
or the object is terminated by some external object.
The points at which an active object responds to
[messages received] from other objects is determined
solely by the behavior specification of the active object...
AnActiveClass

Metamodel Structure
Structure-Behavior
Structure-Behavior
Classes
Classes Dependency
Dependency
Shared
Shared Behavior
Behavior
Semantics
Semantics
Different
Different Behavior
Behavior
Formalisms
Formalisms Common
Common
Behaviors
Behaviors
Activities
Activities Interactions
Interactions StateMachines
StateMachines UseCases
UseCases
Actions
Actions
Common Behavior Metamodel
! The “classifier behavior” of a composite classifier is distinct from
the behavior of its parts (i.e., it is NOT a resultant behavior)
Classifier Class
(from Kernel)
(f ro m Ke rne l)
0..1 +ownedBehavior *
BehavioredClassifier Behavior 0..1 +parameter *
+context {subsets Parameter
isReentrant : Boolean
ownedMember} {ordered, subsets
ownedMember}
0..1 +classifierBehavior 0..1
{subsets
ownedBehavior}
+/returnResult
+specification +method * 0..1 {ordered} *
BehavioralFeature
isAbstract : Boolean 0..1

UML 2.0: Kinds of Behavior
! Actions
" Formally, defined in the context of an Activity
! Activities
! Interactions
! State machines
! Use cases

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Actions in UML
! Action = fundamental unit of behavior
" for modeling fine-grained behavior
" Level of traditional programming languages
! UML defines:
" A set of action types
" A semantics for those actions
• i.e. what happens when the actions are executed
• Pre- and post-condition specifications (using OCL)
" No concrete syntax for individual kinds of actions (notation)
• Flexibility: can be realized using different concrete languages
! In UML 2, the metamodel of actions was consolidated
" Shared semantics between actions and activities (Basic Actions)

Shared Action/Activity Semantics
! Data/control flow foundations for maximal implementation
flexibility
OutputPin Control Flow
(typed)
ActivityM
ActivityM
. .
.
Action2
Action2 .
.
. .
.
. .
. .
.
Action1
Action1 .
.
.
. . .
.
.
.
Action3
Action3 .
.
Input Pin
(typed) VariableA
VariableA
Data Flow

Categories of Actions
! Communication actions (send, call, receive,…)
! Primitive function action
! Object actions (create, destroy, reclassify,start,…)
! Structural feature actions (read, write, clear,…)
! Link actions (create, destroy, read, write,…)
! Variable actions (read, write, clear,…)
! Exception action (raise)

General Notation for Actions
! No specific symbols (some exceptions)
«precondition»
«precondition»
{port.state
{port.state >> 0}
0}
for( int ii == 0;
for(int 0; ii <s)
<s)
portP->send ((sig)
portP->send sig)
ia [i] == i++;
ia[i] i++;
««postcondition»
postcondition»
{port.state alternatives
alternatives
{port.state >> 1}
1}
sig
on portP

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Activities
! Significantly enriched in UML 2.0 (relative to UML 1.x
activities)
" More flexible semantics for greater modeling power (e.g., rich
concurrency model based on Petri Nets)
" Many new features
! Major influences for UML 2.0 activity semantics
" Business Process Execution Language for Web Services
(BPEL4WS) – a de facto standard supported by key industry
players (Microsoft, IBM, etc.)
" Functional modeling from the systems engineering
community (INCOSE)

Activity Graph Example
parameter contracts Interruptible
Region
Order Processing «precondition»

precondition» Order entered
Invoice : InvoiceKind «postcondition»
postcondition» Order complete
Order
cancel Cancel
request
Input order
pin
Ship
Receive Fill Close
Order order
order order order
Send Make Accept

Invoice
invoice payment payment

“Unstructured” Activity Graphs
! Not possible in 1.x
" But, business processes are not necessarily well structured
A1 A2 A4 A5
A3

Partitioning capabilities
Seattle
Seattle Reno
Reno
OrderDepartment
Ship
Ship
Receive
Receive Fill
Fill Close
Close
order
order
order
order order
order order
order
Company
Accounting
Send
Send Accept
Accept
invoice
invoice payment
payment
Invoice
Invoice
Customer
Make
Make
payment
payment

Activities: Basic Notational Elements
Control/Data
Control/Data Flow
Flow
Control
Control Fork
Fork
Activity
Activity or
or Action
Action
Control
Control Join
Join
Object
Object Node
Node
(may
(may include
include state)
state) Initial
Initial Node
Node
Pin
Pin (Object)
(Object)
Activity
Activity Final
Final
Choice
Choice
Flow
Flow Final
Final
(Simple)
(Simple) Join
Join
Extended Concurrency Model
! Fully independent concurrent streams (“tokens”)
Concurrency
Concurrency fork
fork Concurrency
Concurrency join
join
B C
A Z
X Y
Trace: A, {(B,C) || (X,Y)} , Z

“Tokens”
“Tokens” represent
represent
individual
individual execution
execution
threads
threads (executions
(executions ofof
activities)
activities)
NB:
NB: Not
Not part
part of
of the
the
notation
notation

Activities: Token Queuing Capabilities
! Tokens can
" queue up in “in/out” pins.
" backup in network.
" prevent upstream behaviors from taking new inputs.
Activity 2 Activity 3
! …or, they can flow through continuously

" taken as input while behavior is executing
" given as output while behavior is executing
" identified by a {stream} adornment on a pin or object node
Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Overview of New Features
! Interactions focus on the communications between collaborating
instances communicating via messages
" Both synchronous (operation invocation) and asynchronous (signal
sending) models supported
! Multiple concrete notational forms:
" sequence diagram (based on ITU Standard Z.120 – MSC-2000)
" communication diagram
" interaction overview diagram
" timing diagram
" interaction table

Interaction Diagrams
Interaction Frame Lifeline
Lifeline is
is one
one
object or a part
object or a part
sd ATM-transaction Interaction
Interaction Occurrence
Occurrence
client: atm: dbase:

insertCard sd CheckPin
ref
CheckPin client: atm: dbase:
askForPIN
alt [chk= OK] data(PIN)
check(PIN)
ref
DoTransaction result(chk)
result(chk)
[else]
error(badPIN)
Combined
Combined (in-line)
(in-line)
Fragment
Fragment

Structural Decomposition in Sequence Diagrams
Detailed
Decomposed
Decomposed lifeline
lifeline context
ServiceBase
sd sd
SB_GoHomeSetup SB_Authorization
sd GoHomeSetup
:Central :Authorizer
:ServiceBase
:ServiceUser :ServiceTerminal
ref SB_GoHomeSetup
:TimeKeeper
ref
Authorization
sd SB_GoHomeSetup
opt
ref FindLocation :Central :TimeKeeper
SetHome
ref SB_Authorization
SetInvocationTime
opt
SetTransportPreferences
SetHome
Decomposition
Decomposition with
with SetInvocationTime
global constructs
global constructs
corresponding
corresponding toto SetTransportPreferences
those
those on
on decomposed
decomposed
lifeline
lifeline
Combined Fragments and Data
sd GoHomeInvocation(Time invoc)
:ServiceUser :Clock :ServiceBase :ServiceTerminal

loop
loop [Now>invoc]
InvocationTime FindLocation
TransportSchedule
Choice
Choice
loop
alt
[Now>interv+last]
Operand
Operand
ScheduleIntervalElapsed
FindLocation
Separator
Separator TransportSchedule
[pos-lastpos>dist]
GetTransportSchedule
TransportSchedule
FetchSchedule
Guarding
Guarding Data
Data
Constraint
Constraint
Combined Fragment Types (1 of 2)
! Alternatives (alt)
" choice of behaviors – at most one will execute
" depends on the value of the guard (“else” guard supported)
! Option (opt)
" Special case of alternative
! Break (break)
" Represents an alternative that is executed instead of the remainder of
the fragment (like a break in a loop)
! Parallel (par)
" Concurrent (interleaved) sub-scenarios
! Negative (neg)
" Identifies sequences that must not occur

Combined Fragment Types (2 of 2)
! Critical Region (region)
" Traces cannot be interleaved with events on any of the
participating lifelines
! Assertion (assert)
" Only valid continuation
! Loop (loop)
" Optional guard: [<min>, <max>, <Boolean-expression>]
" No guard means no specified limit

Interaction Overview Diagram
! Like flow charts sd OverviewDiagram lifelines Client, :Server
" using activity graph notation

for control constructs ref
Authorization
sd
:Client :Server
request
~[more]
[more]
ref
DoMore

Timing Diagrams
! Can be used to specify time-dependent interactions
" Based on a simplified model of time (use standard “real-time”
profile for more complex models of time)
sd DriverProtocol
Idle Wait Busy Idle

d : Driver
0111 0011 0001 0111

o : OutPin
t=0 t=5 t = 10 t = 15

Timing Diagrams (cont.)
Constraint
Constraint
State
State
sd Reader {d..d+0.5}
Reading
r : Reader Idle
Read ReadDone Read
{t1..t1+0.1}
Uninitialized
Initialize Event
Event
Occurrence
Occurrence
t1
Observation
Observation
Sidebar: Information Flows
! For specifying kinds of information that are exchanged between
elements of the system – at a very abstract level
" Do not specify details of the information (e.g., type)
" Do not specify how the information is relayed
" Do not specify the relative ordering of information flows
Customer
Customer «flow» «flow» Employee
Employee
product wages
Company
Company

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Aren’t Class Diagrams Sufficient?
! No!
" Because they abstract out certain specifics, class diagrams
are not suitable for performance analysis
! Need to model structure at the instance level
N2:Node
N2:Node
N1:Node
N1:Node N3:Node 0..1
N3:Node Node
Node
right
N4:Node
N4:Node
left 0..1
Same class diagram

N1:Node
N1:Node N2:Node
N2:Node N3:Node
N3:Node describes both systems!

Collaborations
! In UML 2.0 a collaboration is a purely structural concept
"" (But,
(But, can
can include
include one
one or
or more
more associated
associated interactions)
interactions)
collaboration
collaboration
"" More
More general
general than
than an
an instance
instance model
model
RedundantSystem
role
role associated
interaction primary
primary
get
2 a
1query 2b get
arbiter
arbiter
client
client backup1
backup1
::Arb
Arb 2c
ge
t
connector
connector
(link
(link role)
role) backup2
backup2

Roles and Instances
! Specific object instances playing specific the roles in a
collaboration
d1 /primary
d1/primary
:Dbase
:Dbase
c1 /client
c1/client aa/arbiter
/arbiter d2 /backup1
d2/backup1
::Cl
Cl ::Arb
Arb :Dbase
:Dbase
d2 /backup2
d2/backup2
:Dbase
:Dbase

Alternative Notation
a:Arb
a:Arb collaboration
collaboration
occurrence
occurrence
arbiter
client
c1:Cl
c1:Cl rs1:RedundantSystem d1:Dbase
d1:Dbase
primary
backup1 backup2
d2:Dbase
d2:Dbase

Collaboration Protocols
! For dynamic relationships between interfaces
FaxProtocol sd StartCall
FaxSender FaxReceiver
sd sd FaxSender FaxReceiver
EndCall
EndCall StartCall
StartCall
Call
AckCall (parms)
CallParms(par)
««interface»
interface»
interface»
««interface»
interface»
interface» FaxReceiver
FaxReceiver loop Data
FaxSender
FaxSender AckData
Call()
Call()
AckCall(par)
AckCall(par)
AckCall(par) CallParms(
CallParms(( ))
CallParms
AckData(
AckData(( ))
AckData Data()
Data()
AckHangup(
AckHangup(( ))
AckHangup Hangup(
Hangup(( ))
Hangup
Fax
Fax Fax
Fax
Sender
Sender Receiver
Receiver

Structured Classes
! Classes with
" Internal (collaboration) structure
" Ports (optional)
! Primarily intended for architectural modeling
! Heritage: architectural description languages (ADLs)
" UML-RT profile: Selic and Rumbaugh (1998)
" ACME: Garlan et al.
" SDL (ITU-T standard Z.100)

Structured Objects: Ports
! Multiple points of interaction
" Each dedicated to a particular purpose
e.g.,
e.g., Database
Database Object
Object
e.g.,
e.g., Database
Database Admin
Admin port
port
e.g.,
e.g., Database
Database User
User ports
ports

New Feature: Ports
! Used to distinguish between multiple collaborators
" Based on port through which interaction is occurring
! Fully isolate an object’s internals from its environment
objC objF
void E () {…
E() pp objM.setA(d)
q.setA(d) qq objG
…
objM

Port Semantics
! A port can support multiple interface specifications
" Provided interfaces (what the object can do)
" Required interfaces (what the object needs to do its job)
Incoming
Incoming signals/calls
signals/calls
«interface»
«interface»
MasterIF
MasterIF «provides»
«provides»
stateChange
stateChange (( ss :: state
state )) :: void
void
…
…
c: ClassX
c:ClassX
«interface»
«interface» «uses»
«uses» p1
p1
SlaveIF
SlaveIF
start
start (( )) :: void
void
stop
stop (( )) :: void
void
queryState
queryState (( )) :: state
state Outgoing
Outgoing signals/calls
signals/calls
…
…
Ports: Alternative Notation
! Shorthand “lollipop” notation with 1.x backward
compatibility
MasterIF
MasterIF
c: ClassX
c:ClassX
SlaveIF
SlaveIF

Assembling Structured Objects
! Ports can be joined by connectors
! These connections can be constrained to a protocol
" Static checks for dynamic type violations are possible
" Eliminates “integration” (architectural) errors
remote
remote remote
remote
sender
sender :: Fax
Fax receiver
receiver :: Fax
Fax
FaxSender FaxReceiver
:FaxProtocol

Structured Classes: Internal Structure
! Structured classes may have an internal structure of
(structured class) parts and connectors
Delegation
Delegation connector
connector
sendCtrl
sendCtrl receiveCtrl
receiveCtrl
cc cc
remote
remote
sender:Fax
sender:Fax receiver:Fax
receiver:Fax
remote
remote
FaxCall
FaxCall
Part
Part
Structure Refinement Through Inheritance
! Using standard inheritance mechanism (design by
difference)
sender:Fax
receiver:Fax
ProductArchitecture
mgr:FaxMgr
mgr:FaxMgr
mgr:FaxMgr
sender:Fax receiver:Fax sender:Fax

receiver:Fax
ProductA ProductB

Components
! A kind of structured class whose specification
" May be realized by one or more implementation classes
" May include any other kind of packageable element (e.g.,
various kinds of classifiers, constraints, packages, etc.)
(Structured)
(Structured)
Class
Class
0..1 0..1
Packageable
Packageable
*
Component
*
Realization
Element Component Realization
Element
1
Class
Class

Subsystems
! A system stereotype of Component («subsystem») such
that it may have explicit and distinct specification
(«specification») and realization («realization»)
elements
" Ambiguity of being a subclass of Classifier and Package has
been removed (was intended to be mutually exclusive kind of
inheritance)
" Component (specifications) can contain any packageable
element and, hence, act like packages

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

State Machine Improvements
! New modeling constructs:
" Modularized submachines
" State machine specialization/redefinition
" State machine termination
" “Protocol” state machines
• transitions pre/post conditions
• protocol conformance
! Notational enhancements
" action blocks
" state lists

Modular Submachines: Definition
Submachine
Submachine
definition
definition
ReadAmountSM
abort
EXIT
EXIT point
point
otherAmount
selectAmount
amount
abort
EnterAmount
aborted
ok
again
ENTRY
ENTRY point
point
Modular Submachines: Usage
invoked
invoked
submachine
submachine
ATM
VerifyCard
acceptCard
outOfService
ReadAmount : aborted
OutOfService ReadAmountSM
again usage
usage of
of
exit
exit point
point
rejectTransaction
releaseCard
VerifyTransaction ReleaseCard
usage
usage of
of
entry
entry point
point

Specialization
! Redefinition as part of standard class specialization
ATM Behaviour
Statemachine
acceptCard()
outOfService()
amount()
<<Redefine>>
FlexibleATM Behaviour
Statemachine
otherAmount()
rejectTransaction()

Example: State Machine Redefinition
! State machine of ATM to be redefined
ATM
VerifyCard
{final}
acceptCard
ReadAmount
OutOfService
outOfService selectAmount
{final} amount
releaseCard
{final} {final}

State Machine Redefinition
ATM {extended}
FlexibleATM VerifyCard
{final}
acceptCard
ReadAmount {extended}
otherAmount
OutOfService
outOfService selectAmount
{final} amount enterAmount
reject ok
releaseCard
{final} {final}

Protocol State Machines
! Impose sequencing constraints on interfaces
" (should not be confused with multi-party protocols)
ready ( )
Landed Ready
land ( )
[cleared]
takeOff ( ) / [gearRetracted]
Flying
Equivalent to pre and post conditions
added to the related operations:
takeOff()
Pre
-in state ”Ready"
-cleared for take off
Post
-landing gear is retracted
-in state ”Flying"
Notational Enhancements
! Alternative transition ! State lists
notation
Idle
VerifyCard, logCard Logged

eventA ReleaseCard
[ID<=10] [ID>10]
Is a notational shorthand for
MinorReq=Id; MajorReq=Id;
VerifyCard logCard
Minor(Id) Major(Id) Logged

ReleaseCard
logCard
Busy
Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Specializing UML
! Lightweight extensions
" Extend semantics of existing UML concepts by specialization
" Conform to standard UML (tool compatibility)
" Profiles, stereotypes
! Heavyweight (MOF) extensions
" Add new non-conformant concepts or
" Incompatible change to existing UML semantics/concepts
Standard
Standard UML
UML Semantics
Semantics
Heavyweight
Heavyweight Lightweight
Lightweight
extension
extension M
M extension
extension

Stereotyping versus Inheritance
! For semantics not expressible through standard UML
mechanisms
! Stereotypes can be standardized (application independent)
Instance of the UML Class concept
Integer «clock»
«clock» Stereotype
Stereotype of
of Class
Class
with
with added
added semantics:
semantics:
an
an active
active counter
counter whose
whose
value
value changes
changes
synchronously
synchronously with
with the
the
progress
progress of
of physical
physical time
time
«clock» Stereotype-specific
Stereotype-specific attribute
attribute
MyClockClass
{resolution = 500 ns}
SetTime( )

Profiles: Metamodel
! Semantically equivalent to 1.x from a user’s perspective
" But, new notation introduced
" Extension concept: a form of “specialization” of metaclasses
Package PackageImport Class As sociation Property
(from Constructs) (f rom Const ructs) (from Constructs) (from Constructs) (f ro m Con st ru ct s)
appliedProfile
Package ProfileApplication Class /metaclass /extension Extens ion ownedEnd ExtensionEnd
{subsets packageImport}
/ isRequired : Boolean
1 1 / * 1 1
*
* *
importedProfile
Profile
1 {subsets importedPackage}
St ereotype type
ownedStereotype
1
1 {subsets ownedMember} *
metaclassReference
ElementImport
(from Constructs)
0.. 1 {subsets elementImport} *
metamodelReference PackageImport
(from Constructs)
0.. 1 {subsets packageImport} *

Profiles: Notation
! E.g., specializing the standard Component concept
Extension
Extension
«profile»
«profile» SimpleEJB
SimpleEJB
«metaclass»
«metaclass» «stereotype»
«stereotype»
Component
Component Bean
Bean
«stereotype»
«stereotype» «stereotype»
«stereotype»
Entity
Entity Session
Session

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Templates
! More precise model than UML 1.x
! Limited to Classifiers, Packages, and Operations
Template
parameter Template
signature
T > Number, k : IntegerExpression
NumericArray
Template
arrayElement : T [k] binding
Class(ifier)
template «bind» <T -> Integer, k -> 10> “Bound”
class
IntegerArray
arrayElement : Integer [10]
Collaboration Templates
! Useful for capturing design patterns
ObserverPattern
oType, sType
subject : sType observer : oType
Collaboration
template
«bind»
DeviceObserver
ObserverPattern <oType->DevicePoller, sType>Device>

Package Templates
! Based on simple string substitution
CustomerAccountTemplate customer : StringExpression,
CustomerAccountTemplate
kind : StringExpression
owner $<kind>Acct$ $<kind>

$<kind>
$<customer>$
$<customer>$
1..* 0..* Account$
Account$
«bind» <customer->Person, Name

kind -> Personal Expression
SavingsBank
SavingsBank
owner PersonalAcct Personal
Personal
Person
Person
1..* 0..* Account
Account

Contents

! Foundations
! Actions
! Activities
! Interactions
! Structures
! State machines
! Profiles
! Templates
! Summary

Summary: UML 2.0
! First major revision of UML
! Original standard had to be adjusted to deal with
" MDD requirements (precision, code generation, executability)
! UML 2.0 characterized by
" Small number of new features + consolidation of existing ones
" Scaleable to large software systems (architectural modeling
capabilities)
" Modular structure for easier adoption (core + optional specialized sub-
languages)
" Increased semantic precision and conceptual clarity
" Suitable foundation for MDA (executable models, full code generation)

QUESTIONS?
(bselic@ca.ibm.com)

Selic - An Overview of UML 2-0

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Selic - An Overview of UML 2-0

Загружено:

Авторское право:

Доступные форматы

®

IBM Software Group

An Overview of UML 2.0

The technical material described here is still

2 IBM Software Group |

3 IBM Software Group |

! A critique of UML 1.x

5 IBM Software Group |

UML 2.0 (MDA)

UML 1.1 (OMG Standard)

6 IBM Software Group |

7 IBM Software Group |

9 IBM Software Group |

«modeledBy» «modeledBy» «modeledBy»

11 IBM Software Group |

12 IBM Software Group |

13 IBM Software Group |

! A critique of UML 1.x

14 IBM Software Group |

1) Infrastructure – UML internals

16 IBM Software Group |

18 IBM Software Group |

19 IBM Software Group |

21 IBM Software Group |

! A critique of UML 1.x

22 IBM Software Group |

23 IBM Software Group |

24 IBM Software Group |

25 IBM Software Group |

26 IBM Software Group |

27 IBM Software Group |

! A critique of UML 1.x

28 IBM Software Group |

Formal (set theoretic) interpretation:

Set of all Set of all

29 IBM Software Group |

Set of all instances of

position : Point ... sp

Ellipse Polygon Spline

30 IBM Software Group |

31 IBM Software Group |

34 IBM Software Group |

Customer Slightly MyCustomer

36 IBM Software Group |

Basic Structural Concepts

38 IBM Software Group |

39 IBM Software Group |

42 IBM Software Group |

43 IBM Software Group |

45 IBM Software Group |

46 IBM Software Group |

! A critique of UML 1.x

47 IBM Software Group |

48 IBM Software Group |

49 IBM Software Group |

50 IBM Software Group |

51 IBM Software Group |

! A critique of UML 1.x

52 IBM Software Group |

53 IBM Software Group |

Order Processing «precondition»

Send Make Accept

54 IBM Software Group |