The Real
-Time UML Standard:
Real-Time
Theory and Application
Bran Selic
Rational Software Canada
[email protected]
Ben Watson
Tri-Pacific Software, Inc.
[email protected]
Tutorial Objectives
♦
To clarify the relationship between the object paradigm
♦To
and real
-time systems
real-time
■
■
match or mismatch?
♦
Describe and analyze UML from a real
-time designer’s
♦Describe
real-time
perspective
♦
To introduce the “UML Profile for Schedulability,
♦To
Performance, and Time”
♦
To introduce an engineering
-oriented design approach
♦To
engineering-oriented
for real
-time systems
real-time
2
Tutorial Overview
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
3
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
Real
-Time System Essentials
Real-Time
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
4
Real-Time System
♦
Systems that maintain an ongoing timely interaction with
♦Systems
its environment
environment
signal
source
signal
source
inputs
inputs
Real-Time
System
(state)
•outputs = f (inputs, state) outputs
•coordination
5
controlled
controlled
entities
entities
Under the Hood
♦
A persistent structure that provides a framework for
♦A
behavior
environment
Concurrency
Concurrency conflict
conflict
signal
source
Real-Time
System
(state)
Agent
inputs
Agent
signal
source
inputs
•outputs = f (inputs, state) outputs
Agent
•coordination
6
controlled
controlled
entities
entities
Classifications of RT Systems
♦
Based on nature of key inputs
♦Based
■
■
■
■
time
-driven: for continuous (synchronous) inputs
time-driven:
event
-driven: for discrete (asynchronous) inputs
event-driven:
♦
Based on time criticality
♦Based
■
■
■
■
hard RT systems: every input must have a timely response
soft RT systems: most inputs must have timely response
♦
Based on load:
♦Based
■
■
■
■
static: fixed deterministic load
dynamic: variable (non
-deterministic) load
(non-deterministic)
♦
Many practical systems are combinations of these
♦Many
7
Sample Real-Time Application
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL
SURFACES
SURFACES
GROUND
GROUND
MODEL
MODEL
ENGINES
ENGINES
Which procedure(s) describe this system?
8
PILOT
PILOT
CONTROLS
CONTROLS
Classical Approach: Cyclical Executive
The miscellaneous procedural slices are executed
cyclically based on time resolution
AAA
BBB
ACC
BDD
AAE
BBF
A CG
50msec
= 50 msec band
ENGINES
ENGINES
= 100 msec band (2 parts: A and B)
= 200 msec band (4 parts: A, B, C, D)
= 400 msec band (8 parts: A, B, C, D, E, F, G, H)
The crucially important system structure is almost
completely obscured
9
BDH
Problems with the Traditional Solution
♦
The solution is adjusted to fit the implementation
♦The
technology (i.e., the step
-at-a-time programming style of
step-at-a-time
procedural programming) rather than human needs
⇒ In addition to the inherent complexity of the problem
designers need to contend with the accidental complexity
of the implementation technology
♦
Overwhelming complexity is by far the biggest hurdle in
♦Overwhelming
most real
-time software systems
real-time
reducing complexity is crucial to success
10
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
■
■
Real
-Time System Essentials
Real-Time
Essentials of the Object Paradigm
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
11
The Essence of the Object Paradigm
♦
Combines all the various features of a logical unit
♦Combines
(procedures and data) into a single package called
an object
♦Defines a software system as a structure of
collaborating objects
Airframe
Airframe
Control
Control
Surfaces
Surfaces
Atmosphere
Atmosphere
12
Objects and Real-Time Systems
♦
The structure of real
-time systems tends to persist
♦The
real-time
through time because it reflects the physical entities of
the real world
♦
This structure is the framework through which (infinitely)
♦This
many different behavior threads are executed
♦
Hence, the focus is on structure rather than behavior
♦Hence,
♦
The structural focus of the object paradigm is better
♦The
suited to real
-time systems than the procedural paradigm
real-time
13
Yes, But What About...
♦
Performance?
♦Performance?
■
■
the cost of abstraction (encapsulation, automatic garbage
collection, dynamic binding, etc.)
♦
Modeling real
-time specific phenomena?
♦Modeling
real-time
■
■
■
■
time and timing mechanisms
resources (processors, networks, semaphores, etc.)
♦
Exploiting current real
-time system theory?
♦Exploiting
real-time
■
■
sschedulability
chedulability analysis (e.g., rate
-monotnic theory)
rate-monotnic
■
■
performance analysis (queueing theory)
14
Performance of OO Technology
♦
Hardware is becoming ever faster ((Moore’s
Moore’s law)
♦Hardware
■
■
previously unacceptable response times may now be
acceptable
♦
OO software technologies are becoming real
-time aware
♦OO
real-time
■
■
bounded dynamic binding techniques
■
■
tunable automatic garbage collection (bounded latency)
■
■
real
-time variants of popular OO languages (e.g., EC++, RT
real-time
Java)
15
Objects
♦ Conceptual units with
■
■
■
a unique identity (dedicated memory)
a public interface
a hidden (encapsulated) implementation
Data
Attributes
Data Attributes
Telephone1:
busy : boolean
Operations
Operations
offHook()
onHook ()
ring()
16
void:offHook ();
{busy = true;
reqDialtone();
…
};
Conceptual Objects
♦
Not all objects necessarily require a physical
♦Not
underpinning
♦
For example, the “telephone call” object
♦For
Telephone1
Telephone1
Telephone2
Telephone2
Telephone
Telephone Call
Call
Telephone Call Object
abortCall ()
addParty (t:Telephone)
reportDuration ()
The object paradigm allows us to create our own (virtual)
reality!
17
Object Behavior
♦
In essence, an object is a server
♦In
■
■
generic object lifecycle:
Initialize
Initialize
Object
Object
Handling
Handling depends
depends
on
on specific
specific request
request
type
type and
and object
object state
state
Invokes
Invokes
operations
operations on
on
other
other objects
objects
Wait
Waitfor
for
Request
Request
void:offHook
void:offHook ();
();
{busy
{busy == true;
true;
obj.reqDialtone();
obj.reqDialtone();
…
…
};
};
Handle
Handle
Request
Request
Terminate
Terminate
Object
Object
18
Making Things Happen with Objects
♦
Higher-level behavior “emerges” through the interactions
♦Higher-level
of individual objects
Airframe:
3.position()
3.position()
2.gust()
2.gust()
Atmosphere:
Spolier:
1.roughAir()
1.roughAir()
4.change()
4.change()
19
Objects and Emergent Behavior
♦
One of the main problems of many current OO
♦One
programming languages is that they do not provide a
means for specifying high
-level emergent behavior
high-level
■
■
■
■
“keyhole” view of high
-level behavior
high-level
difficult to ensure desired high
-level behavior will necessarily
high-level
emerge
♦
A conflict between top
-down and bottom
-up design
♦A
top-down
bottom-up
approaches
■
■
re
-usable component programming style defines objects
re-usable
independently of the sequences in which they may participate
20
Classes and Instances
♦
More than one object can be constructed from the same
♦More
specification
–the class
specification–the
■
■
A design environment concept
♦
Objects created from some class specification are called
♦Objects
instances of that class
■
■
A run
-time concept
run-time
Class
Class (Spec)
(Spec)
Class
Class Instance
Instance
TelephoneClass
Telephone1:TelephoneClass
busy : boolean
offHook()
onHook ()
ring()
Telephone2:TelephoneClass
21
Inheritance and Polymorphism
♦ A generalization and re-use mechanism
GenericTelephone
busy : boolean
offHook()
onHook ()
dialDigit()
TouchTone
Telephone
busy : boolean
Polymorphism:
Polymorphism:
different
different realizations
realizations
of
of the
the same
same operation
operation
offHook()
onHook ()
dialDigit()
playTone()
Generalization
Generalization
(inheritance)
(inheritance)
relationship
relationship
RotaryDial
Telephone
busy : boolean
offHook()
onHook ()
dialDigit()
22
Objects: Summary
♦
The object paradigm is very well adapted to real
-time
♦The
real-time
software systems because of its powerful structural
modeling capability
■
■
networks of collaborating objects
♦
In addition, the object paradigm comes packaged with a
♦In
number of well
-established techniques:
well-established
■
■
■
■
■
■
■
■
modularity
information hiding
generalization/refinement mechanisms (e.g., inheritance)
genericity
23
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
■
■
Real
-Time System Essentials
Real-Time
Essentials of the Object Paradigm
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
24
The Unified Modeling Language
♦
A consolidation of proven ideas and practices based on
♦A
the object paradigm into a general
-purpose OO modeling
general-purpose
language
■
■
Inititated by Rational Software ((Booch,
Booch, Rumbaugh, Jacobson)
♦
Standardized by the Object Management Group in 1997
♦Standardized
♦
Major advantages:
♦Major
■
■
■
■
■
■
widely adopted by software practitioners
widely taught in universities and technical seminars
supported by many software tool vendors
25
Evolution of UML
Public
Feedback
Planned major revision (2002)
UML 2.0
Approved minor revision May 2001
UML 1.4
Current minor revision 1999
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sept 1997
First submission to OMG, Jan 1997
UML 1.1
UML partners
UML 1.0
Web - June 1996
UML 0.9
Unified Method 0.8
OOPSLA 95
Other methods
OOSE
26
Booch method
Harel Statecharts
OMT
Components of UML
♦
Basic set of (extensible) modeling concepts
♦Basic
■
■
■
■
used for modeling both problems and solutions (object, class,
association)
deep semantic roots
♦
Formal rules of semantically meaningful composition
♦Formal
(well
-formedness)
(well-formedness)
♦
Graphical notation for modeling concepts
♦Graphical
■
■
8 different diagram types (requirements, structure, behavior,
deployment)
27
Introducing Views and Viewpoints
♦ Viewpoint: a set of related concerns regarding some system
♦ View: a model of a system based on a particular viewpoint
■
■
abstracts out detail that is irrelevant for that set of concerns
Radio: Designer view
Radio: Radio: user view
28
Model-Based and View-Based Approaches
♦
UML uses a model
-based approach rather than a view
♦UML
model-based
view-based approach
View
View 22
33
w
w
e
i
e
VVi
33
w
w
e
i
e
VVi
View
View 22
?
View
View 11
View
View 11
Model-view consistency is enforced through the UML metamodel
29
UML Model Views
♦
Requirements (use case diagrams)
♦Requirements
♦
Static structure (class diagrams)
♦Static
■
■
kinds of objects and their relationships
♦
Object behavior (state machines)
♦Object
■
■
possible life histories of an object
♦
Inter-object behavior (activity, sequence, and
♦Inter-object
collaboration diagrams)
■
■
flow of control among objects to achieve system
-level behavior
system-level
♦
Physical implementation structures (component and
♦Physical
deployment diagrams)
■
■
software modules and deployment on physical nodes
30
Use Case Diagrams
♦
Used to capture functional requirements
♦Used
■
■
useful as principal drivers of the overall development process
AircraftSimulator
AircraftSimulator
instructor
instructor
actor
actor
Prepare
Prepare flight
flight
trainee
trainee
Use
Use case
case
Fail
Fail one
one
engine
engine
Land
Land plane
plane
31
«include»
«include»
Run
Run checklist
checklist
Use Cases and RT Systems
♦
As useful as in any other domain
♦As
■
■
fundamental drivers of definition, development, and testing
♦
However….
♦However….
■
■
■
■
Focus on function (functional requirements)
In RT systems, much focus on non
-functional requirements
non-functional
•• e.g.,
-to-end delays,
e.g., end
end-to-end
delays, maximum
maximum response
response times,…
times,…
■
■
■
■
No standard way of associating such non
-functional
non-functional
requirements with use cases
Use cases do not deal with many important ““ilities”
ilities” (availability,
reliability, maintainability,…) that are critical in many real
-time
real-time
systems
32
Class Diagram
♦
Shows the entities in a system and their general
♦Shows
relationships
Association class
Association class
Airplane
Airplane
designatedPlane
designatedPlane
crew
crew
11
1..*
1..*
Pilot
Pilot
0..*
0..*
Association
Association
Flight
Flight
route
route
start
start
duration
duration
owner
owner
0..*
0..*
{ordered}
{ordered}
0..*
0..*
Airline
Airline
Captain
Captain
11
33
First
First Officer
Officer
Object Instance Diagram
♦
Shows object instances in a particular case
♦Shows
Link
Link
Donald
Donald D.
D. :: Pilot
Pilot
N1313:Airplane
N1313:Airplane
Mickey
Mickey M.
M. :: Pilot
Pilot
CA345
CA345 :: Flight
Flight
CA123
CA123 :: Flight
Flight
DecrepitAir
DecrepitAir :: Airline
Airline
CreakyAir
CreakyAir :: Airline
Airline
34
Class Diagrams and RT Systems
♦
Class diagrams are very abstract and sometimes leave
♦Class
out crucial system information (e.g., topology)
■
■
e.g., common class diagram for both systems
N2:Node
N2:Node
N1:Node
N1:Node
0..2
N3:Node
N3:Node
Node
Node
N4:Node
N4:Node
0..2
N1:Node
N1:Node
N2:Node
N2:Node
N3:Node
N3:Node
35
Object Diagrams to the Rescue?
♦
Object (instance) diagrams do show topologies
♦Object
♦
However…
♦However…
■
■
■
■
in principle, object diagrams only represent “snapshots” of a
system at a particular point in time
no guarantee that they hold throughout the lifetime of the
system
■
■
need “prototypical” object diagrams
■
■
but, such semantics are not defined in the current standard
36
Collaboration Diagram
♦
Depict generic structural and behavioral patterns
♦Depict
Classifier
Classifier role
role
P2:TTSet
P2:TTSet
/CallProc
/CallProc
2.call()
2.call()
1.offHook()
1.offHook()
P1:BusSet
P2:TTSet
/PhoneIF
P1:BusSet
/PhoneIF
P2:TTSet
NB:
NB: ItIt is
is possible
possible to
to have
have
collaboration
collaboration diagrams
diagrams
without
without an
an Interactions
Interactions
overlay
(“pure”
overlay (“pure” structure)
structure)
3.sendTone()
3.sendTone()
4.dialtone()
4.dialtone()
P1:BusSet
P1:BusSet
37
/ToneGen
/ToneGen
Sequence Diagrams
♦ Show interactions between objects with a focus on
communications (a different representation of a collaboration)
/Caller
/Operator
/Callee
call
ack
number
call
ack
transfer
talk
time
time
38
Sequence Diagrams and RT Systems
♦
Sequence diagrams are extremely useful for showing
♦Sequence
object interactions
■
■
■
■
■
■
very common in many real
-time systems
real-time
well suited for event
-driven behavior
event-driven
in telecom, many protocol standards are defined using
sequence diagrams
♦
However…
♦However…
■
■
■
■
No standard way of denoting timing information
UML sequence diagrams do not scale up very well for
modeling large systems with complex sequences
39
Using Timing Marks with Sequence Diagrams
♦
Specifying constraints
♦Specifying
master : Master
d : DBaseServer
cs : CommServer
read( )
register( )
{(register.receiveTime ( ) - read.sendTime( )) ≤ 2 ms}
40
Activity Diagrams
♦
Different focus compared to sequence diagrams
♦Different
activity
activity
/Caller
/Operator
/Callee
Contact
Contact
Operator
Operator
Contact
Contact
Callee
Callee
swimlane
swimlane
Respond
Respond
Notify
Notify
Parties
Parties
Acknowledge
Acknowledge
Acknowledge
Acknowledge
41
Activity Diagrams and RT Systems
♦
Better than sequence diagrams for
♦Better
■
■
showing concurrency (forks and joins are explicit)
■
■
scaling up to complex systems
♦
However…
♦However…
■
■
No standard way of denoting timing information
■
■
Less well
-suited for describing event
-driven behavior
well-suited
event-driven
42
State Machine Diagram
♦ Each state corresponds to a selective receive action
transition
transition
Initialize
Initialize
Object
Object
Initial
Initial pseudostate
pseudostate
State
State
trigger
trigger
created
Wait
Waitfor
for
Event
Event
Handle
Handle
Event
Event
State
State machine
machine
start/^master.ready()
start/^master.ready()
Action
Action
expression
expression
ready
stop/
stop/
Final
Final state
state
Terminate
Terminate
Object
Object
poll/^master.ack()
poll/^master.ack()
43
Hierarchical States and Transitions
♦Allows step-wise refinement and viewing of complex
behavior
off/
OffLine
default
default
transition
transition
group
group
transition
transition
on/
OnLine
Ready
done/
req/handle()
composite
composite
state
state
Busy
44
State Machines and RT Systems
♦
Many real
-time systems are event
-driven
♦Many
real-time
event-driven
■
■
■
■
very well suited to those systems
scale up very nicely
♦
However…
♦However…
■
■
■
■
not directly connected to time (except for time events)
e.g., run
-to-completion paradigm
run-to-completion
45
Implementing Time-Triggered Systems
♦
Periodic timers:
♦Periodic
■
■
once initiated they repeatedly send TimeEvents at the
appropriate intervals until explicitly stopped or cancelled
♦
In “steady
-state” mode, active objects stimulated
♦In
“steady-state”
exclusively by periodic timers become periodic tasks
■
■
■
■
allows rate
-monotonic scheduling policies
rate-monotonic
schedulers use the priorities of periodic timers to make
scheduling decisions
46
Objects and Concurrency
♦ Passive objects: have no control of their communications
■
■
Clients determine when to invoke an operation
♦ Active objects: can control when to respond to requests
■
■
■
■
Can avoid concurrency conflicts
Require at least one independent engineering
-level thread
engineering-level
Initialize
Initialize
Object
Object
Initialize
Initialize
Object
Object
Wait
Waitfor
for
Request
Request
Wait
Waitfor
for
Request
Request
Handle
Handle
Request
Request
Handle
Handle
Request
Request
Terminate
Terminate
Object
Object
Terminate
Terminate
Object
Object
47
The Active Objects of UML
♦
Single thread of execution
♦Single
♦
Behavior defined by state machines (event driven)
♦Behavior
anActiveObject
#currentEvent : Eventpoll/defer
created
start
+ start ( )
+ poll ( )
+ stop ( )
start/^master.ready()
ready
stop/
poll/^master.ack()
48
ready
Active Object Semantics
♦ Concurrent incoming events are queued and handled
one-at-a-time regardless of priority
♦ run-to-completion (RTC) execution model
anActiveObject
created
ready
RTC eliminates potential
concurrency conflicts
49
RTC Semantics
♦
A high priority event for another active object will preempt
♦A
an active object on the same processor that is handling a
low
-priority event
low-priority
■
■
Limited priority inversion can occur
Active1
Active1
Active2
Active2
lo
hi (queued)
hi
50
RTC Analysis
♦
Advantages:
♦Advantages:
■
■
■
■
■
■
Eliminates concurrency conflicts for all passive objects
encapsulated by active objects
No explicit synchronization code required
Low
-overhead context switching (RTC implies that stack does
Low-overhead
not need to be preserved)
♦
Disadvantage:
♦Disadvantage:
■
■
■
■
Limited priority inversion can occur (higher priority activity m
ay
may
have to wait for a lower
-priority activity to complete)
lower-priority
Can be circumvented but at the expense of application
-level
application-level
complexity
51
Example: Active Objects
♦
Active object ≠ OS thread
♦Active
■
■
■
■
two
-tier scheduling scheme
two-tier
event priorities vs thread priorities
OSProcess
OSThread1
Active
object
scheduler
...
OSThreadN
Lightweight
Lightweight
specialized
specialized
multitasking
multitasking
Active
object
scheduler
Heavyweight
Heavyweight
general
general-purpose
purpose
multitasking
multitasking
Operating System
(schedules process and threads)
52
UML Concurrency Model and RT Systems
♦
Active objects are the major concurrency mechanism of
♦Active
UML
■
■
automatically resolve certain concurrency conflicts
♦
However...
♦However...
■
■
■
■
■
■
The priority inversion inherent in RTC may be unacceptable in
some cases
How does this map to concurrency mechanisms that are used
in the real
-time domain (processes, threads, semaphores,
real-time
real
-time scheduling methods, etc.)?
real-time
No clear way of exploiting real
-time analyses methods (e.g.,
real-time
schedulability analysis)
53
Scheduling in UML
♦
Scheduling approach undefined
♦Scheduling
■
■
Hints of event
-based priorities (versus thread
-based)
event-based
thread-based)
■
■
Timing events allow realization of time
-triggered systems
time-triggered
♦
The actual scheduling policy is unspecified
♦The
■
■
A semantic variation point
■
■
Can be customized to suit application requirements
54
The Model of Time in UML
♦
Unbiased and uncommitted (i.e., it does not exist):
♦Unbiased
■
■
■
■
Time data type declared but not defined (could be either
continuous or discrete)
No built
-in assumptions about global time source (open to
built-in
modeling distributed systems)
♦
Related concepts:
♦Related
■
■
Time events: generated by the occurrence of a specific instant
■
■
Assumes some kind of run
-time Timing Service
run-time
55
Component and Deployment Diagrams
♦
Implementation focus
♦Implementation
Component
Component
:Scheduler
:Planner
reservations
update
Generally not sophisticated
enough for complex real-time
system needs
Node
Node
:GUI
56
Implementation Diagrams and RT Systems
♦
Probably the weakest part of UML
♦Probably
♦
Not sophisticated enough to capture the various complex
♦Not
aspects of deployment common to real
-time systems
real-time
■
■
■
■
deferred mapping of software to hardware
mapping of software to software
♦
No standard way to describe the quantitative
♦No
requirements/characteristics of hardware and software
(e.g., scheduling discipline)
♦
…..
♦…..
57
UML Summary
♦
An industry standard for analysis and design of object
♦An
object-oriented systems
■
■
■
■
based on extensive experience and best practices
gaining rapid acceptance (training, tools, books)
♦
Comprises:
♦Comprises:
■
■
■
■
set of modeling concepts
a standard graphical notation
♦
Represented through 8 different diagram types
♦Represented
■
■
class, state machine, collaboration, use case, sequence,
activity, component, deployment
58
UML and RT Systems Summary
♦
Using UML for real
-time systems automatically brings the
♦Using
real-time
benefits of the object paradigm
■
■
structural focus, inheritance, strong encapsulation,
polymorphism,…
♦
However, there are many open questions
♦However,
■
■
■
■
■
■
best ways of using UML in the real
-time domain
real-time
missing or non
-standard concepts
non-standard
ability to create predictive models for real time
59
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
■
■
Real
-Time System Essentials
Real-Time
Essentials of the Object Paradigm
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
60
Semantic Variation in UML
♦
Semantic aspects that are:
♦Semantic
■
■
■
■
undefined (e.g., scheduling discipline), or
intentionally ambiguous (multiple, mutually
-exclusive,
mutually-exclusive,
interpretations)
♦
Why?
♦Why?
■
■
■
■
Different domains require different specializations
The applicability and usefulness of UML would have been
severely constrained if it could not support such diversity
♦
The scope and semantic impact of semantic variation
♦The
choices must be strictly limited
61
Specialization of UML
♦
Avoiding the PL/I syndrome (“language bloat”)
♦Avoiding
■
■
UML standard as a basis for a “family of languages”
UML Standard 1.4
Real
-Time UML
Real-Time
UML for eCommerce
62
Variations
Variations produced
produced
using
using built-in
built-in
extensibility
extensibility mechanisms:
mechanisms:
stereotypes,
stereotypes, tagged
tagged values,
values,
constraints
constraints
…..etc.
How Do We Specialize UML?
♦
Typically used to capture semantics that cannot be
♦Typically
specified using UML itself
Integer
Integer
But, how can we
specify a clock?
Counter
Counter
ResetCounter
()
ResetCounter()
Specialization
Specialization
through
through regular
regular
inheritance
inheritance
Semantics:
an active counter whose
value changes
synchronously with the
progress of physical time
63
Stereotyping UML Concepts
♦
Example: a “clock” stereotype based on the generic UML
♦Example:
Class concept
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
Integer
Integer
«clock»
MyTimePiece
MyTimePiece
SetTime
()
SetTime()
64
UML Profiles
♦
A package of related specializations of general UML
♦A
concepts that capture domain
-specific variations and
domain-specific
usage patterns
➪ A domain
-specific interpretation of UML
domain-specific
♦
Fully conformant with the UML standard
♦Fully
■
■
■
■
additional semantic constraints cannot contradict the general
UML semantics
within the “semantic envelope” defined by the standard
Standard
Standard UML
UML Semantics
Semantics
Profile
Profile Y
Y
Profile
Profile X
X
65
UML Extensibility and RT Systems
♦
The extensibility mechanisms of UML provide an
♦The
excellent opportunity to fill in the missing bits for real
-time
real-time
applications
♦
If we can define a standard set of extensions (“real
-time
♦If
(“real-time
profile”) then these could provide a common facility for
real
-time UML modelers and tool builders
real-time
66
Real-Time A&D WG (1 of 2)
♦
Bridges two domains: modeling and real
-time
♦Bridges
real-time
Analysis & Design
PTF
Real-Time SIG
RT-AD WG
67
Real-Time A&D WG (2 of 2)
♦
Mission:
♦Mission:
to investigate and issue requests ((RFPs)
RFPs) for standard ways
and means to apply UML to real
-time problems
real-time
♦
Three principal areas of investigation:
♦Three
■
■
■
■
■
■
Time
-related modeling
Time-related
General quality of service modeling
(e.g., availability, reliability, security,…)
Real
-time system architecture modeling
Real-time
♦
Status:
♦Status:
■
■
■
■
first RFP issued (April 1999)
second RFP drafted but not submitted
68
The Real-Time UML RFP
♦ ““UML
UML profile for scheduling performance and time”
■
■
■
■
■
■
First in a series of real
-time specific RFPs (ad/99
-03-13)
real-time
(ad/99-03-13)
Initial proposal submitted in August 2000 (ad/2000
-08-04)
(ad/2000-08-04)
Approved by the Analysis & Design Task Force and by the OMG
Architecture Board Sept. 2001 (final vote pending)
♦ Standard methods for UML modeling of:
■
■
■
■
■
■
■
■
■
■
■
■
■
■
Physical time
Timing specifications
Timing services and mechanisms
Modeling resources (logical and physical)
Concurrency and scheduling
Software and hardware infrastructure and their mapping
..including specific notations for the above where necessary
69
Important Caveat
♦
The RFP does not ask for new real
-time concepts or
♦The
real-time
methods
♦
Instead, the intent is to support existing and future
♦Instead,
modeling techniques and analysis methods in the context
of UML
⇒
⇒
response should not be biased towards any particular
technique or method
70
Response to the RFP
♦ Just one submission throughout
♦ Consortium team:
■
■
■
■
■
■
■
■
■
■
■
■
ARTiSAN (UML tool vendor)
II-Logix
-Logix (UML tool vendor)
Rational (UML tool vendor) - lead
Telelogic (UML tool vendor)
TimeSys (RT tool and technology vendor)
Tri
-Pacific Software (RT tool vendor)
Tri-Pacific
♦ In consultation with many of the top real
-time system experts
real-time
((toolbuilders,
toolbuilders, analysis technique experts, academics)
■
■
Prof. Murray Woodside and Prof. Dorina Petriu (Carleton U.) –
performance analysis profile
71
RT Profile: Guiding Principles
♦ Ability to specify quantitative information directly in UML mode
ls
models
■
■
key to quantitative analysis and predictive modeling
♦ Flexibility:
■
■
■
■
users can model their RT systems using modeling approaches and
styles of their own choosing
open to existing and new analysis techniques
♦ Facilitate the use of analysis methods
■
■
■
■
eliminate the need for a deep understanding of analysis methods
as much as possible, automate the generation of analysis models and
the analysis process itself
72
Quantitative Methods for RT Systems
♦ Once we have included QoS information in our models, we can
use quantitative methods to:
■
■
predict system characteristics (detect problems early)
analyze existing system
■
■
synthesize elements of the model
■
■
♦ Methods considered for the profile:
■
■
■
■
Schedulability analysis
will the system meet all of its deadlines?
Performance analysis based on queueing theory
what kind of response will the system have under load?
73
Issues with Quantitative Methods
♦
Require uncommon and highly
-specialized skills
♦Require
highly-specialized
♦
Software is notoriously difficult to model
♦Software
■
■
■
■
■
■
highly non
-linear (detail often matters)
non-linear
models are frequently severely inaccurate and not trustworthy
typical modeling process is highly manual:
System
Model
analysis
analysis
results
results
+
Actual
System
measurements
measurements
74
Desired Development Model
♦
Seamless integration of technologies and tools based on
♦Seamless
standards for real
-time modeling
real-time
Automated
Automated
model
model conversion
conversion
Model Editing
Tool
Model Analysis
Tool
44
3.1
3.1
55
Inverse
Inverse
model
model conversion
conversion
75
Structure: Domain Model and Extensions
«profile»
RTresourceModeling
General Resource Model
Client
etc.
Resource
«import»
«profile»
ADprofile
«import»
«metaclass»
Class
Specialized Analysis Domain Model
Analysis
Client
«metaclass»
Object
«stereotype»
etc.
«stereotype»
ADresource
Analysis
Resource
etc.
Domain model
Profile Packages (normative)
76
UML Real-Time Profile Structure
General Resource Modeling Framework
«profile»
RTresourceModeling
«import»
«import»
«profile»
RTconcurrencyModeling
«import»
«profile»
RTtimeModeling
«import»
«import»
Analysis Models
«profile»
SAProfile
Infrastructure Models
«profile»
PAprofile
«import»
«profile»
RSAprofile
77
«modelLibrary»
RealTimeCORBAModel
Quality of Service Concepts
♦
Quality of Service (QoS):
♦Quality
a specification (usually quantitative) of how a particular servi
ce
service
is (to be) performed
■
■
e.g. throughput, capacity, response time
♦
The specification of a model element can include:
♦The
■
■
■
■
offered QoS: the QoS that it provides to its clients
required QoS: the QoS it requires from other components to
support its QoS obligations
78
Resources and Quality of Service
♦
Resource:
♦Resource:
an element whose service capacity is limited, directly or
indirectly, by the finite capacities of the underlying physical
computing environment
♦
These capacities are expressed through QoS attributes
♦These
of the service or resource
Client
Resource
Resource Usage
Usage
S1
S1
S1
S1
Resource
OfferedQoS
OfferedQoS
RequiredQoS
RequiredQoS
{RequiredQoS
{RequiredQoS ≤≤ OfferedQoS}
OfferedQoS}
79
Simple Example
♦ Concurrent tasks accessing a monitor with known response time
characteristics
Required
Required QoS
QoS
Client1
Client2
access ( )
access ( )
{Deadline = 3 ms}
{Deadline = 5 ms}
myMonitor
{MaxExecutionTime = 4 ms}
Offered
Offered QoS
QoS
80
Instance- vs Class-Based Models
N2:Node
N2:Node
1
Node
Node
N1:Node
N1:Node
N3:Node
N3:Node
1
N4:Node
N4:Node
♦ Practically all analysis methods are concerned with instance
instance-based models
♦ However, it is often useful to associate QoS characteristics wit
h
with
classes
■
■
Used to define default values that may be overridden for specifi
specificc
instances
♦ Need to apply a stereotype to both spec elements and instance
elements
81
The General Resource Model
RealizationModel
Resourc eUs ageModel
DynamicUsageModel
(from ResourceUsageModel)
StaticUsageModel
(from ResourceUs ageModel)
Resourc eManagement
CausalityModel
ResourceTypes
CoreResourceModel
82
Core Resource Model
+type
Inst ance
0..n
0..n
ResourceInstance
Descriptor
1..n
+inst ance
+type
0..n
Resource
1..n
0..n
l
+offeredService
1..n
ResourceServiceInst ance +instance
1..n
+t ype ResourceService
0..n
1
0.. n
0..n
/
/
+offeredQoS
0..n
0..n
QoSvalue
QoScharacterist ic
+instance
0..n
0..n
+offeredQoS
+type
1
0..n
♦
NB: This is a model of the domain concepts
♦NB:
■
■
(i.e., it is not a UML metamodel)
83
Basic Resource Usage Model
EventOccurence
(f rom Cau sali ty Mo del )
AnalysisContext
1
1..n
1..n
1..n
UsageDemand
0..n
1
0..1
1
+usedResourc es
ResourceUsage
+workload
ResourceInstance
1..n (from CoreResourceModel)
0..n
+us edServices
1..n
ResourceServiceInstance
0..n (from CoreResourceModel)
StaticUsage
DynamicUsage
84
Basic Causality Loop
♦
Used in modeling dynamic scenarios
♦Used
EventOccurence
+cause
StimulusGeneration
1
+effect 0..n
+cause 1
+cause
StimulusReception
1
+effect
+effect
Stimulus
1..n
+receiver
Instance
0..n
(from CoreResourceModel) 0..1
1..n +executionHost
0..n +methodExecution
Scenario
0..n
+effect
0..1
85
1 +cause
Dynamic Usage Model
DynamicUsage
(from ResourceUsageModel)
Scenario
(from Caus ality Model)
1..n
+usedResources
/
1..n
ResourceInstance
(from CoreResourceModel)
1..n
+step
+successor
{ordered}
1..n
/
ActionExecution
1.. n
+usedServices
1..n
0..n
ResourceServiceInstance
(from CoreResourceModel)
0..n
+predecessor 0..n
0.. n
0..n
+requiredQoS
0..n
+offeredQoS
QoSvalue
(from CoreResourceModel)
86
Static Usage Model
StaticUsage
(from ResourceUsageModel)
Client
Instance
(from CoreReso urceMode l)
+usedResources
ResourceInstance
1..n (from CoreResourceModel)
1..n
0..n
+requiredQoS
0..n
1..n
QoSvalue
(from CoreResourceModel)
+offeredQoS
0..n
+instance 0..n
+type 1
QoScharacteristic
(from CoreResourceModel)
87
/
Resource Categorizations
ResourceInstance
(from CoreResourceModel)
protectionKind
ProtectedResource
activenes sKind
UnprotectedResource
PassiveResource
ActiveResource
purposeKind
Device
Processor
88
CommunicationResource
Exclusive Use Resources and Actions
ResourceServiceInstance
(from CoreResourceModel)
Acces sControlPolicy
ActionExecution
(from DynamicUsageModel)
1
0..n
0..1
ExclusiveService
/
/
1
0..n
ProtectedResource
0..n
AcquireService
isBlocking : Boolean
Releas eService
0..n
1..n
/
/
1
89
Resource Management Model
Instance
(from CoreResourceModel)
ResourceBroker
1
ResourceManager
0..n
0..n
0..n
1
ResourceControlPolicy
1..n
AccessControlPolicy
(from ResourceTypes)
1..n
1..n
+managedResource
Res ourceInst ance
(from CoreResourceModel)
90
Mapping to UML Extensions
♦
Elements of the general resource model are represented
♦Elements
as stereotypes (with tags) of base UML concepts:
Resource
Service
«GRMresource»
«GRMresource»
Resource
BufferPool
BufferPool
0..n
0..n
«GRMresSrvc»
() {GRMexTime
GetBuffer
«GRMresSrvc» GetBuffer()
GetBuffer()
{GRMexTime == 5}
5}
Stereotype
UML base concepts
Tags
GRMresource
Classifier,
Instance
N/A
GRMresSrvc
BehavioralFeature
GRMexTime
«GRMresource»
«GRMresource»
aPool
aPool :: BufferPool
BufferPool
91
Example System
♦
Periodic concurrent tasks sharing resources
♦Periodic
WCET
WCET == 22 ms
ms
Period
Period == 100
100 ms
ms
WCET
=
20
ms
WCET = 20 ms
1. read( )
master : Master
d : DBaseServer
Period
Period == 150
150 ms
ms
WCET
WCET == 40
40 ms
ms
2. register( )
WCET
WCET == 20
20 ms
ms
dBadmin : Admin
sort( )
WCET
WCET == 10
10 ms
ms
Period
Period == 350
350 ms
ms
WCET
=
100
ms
WCET = 100 ms
poller : Poller
invoke( )
cs : CommServer
WCET
WCET == 10
10 ms
ms
92
Standard Stereotypes
♦
To allow an analysis tool to extract the necessary QoS
♦To
information, we define a set of standard stereotypes and
related tags*
Stereotype
Tags
UML base concepts
GRMclient
Classifier,
Instance
GRMperiod,
GRMprotResource
Classifier,
Instance
N/A
GRMresService
BehavioralFeature
GRMwcet
Tag
GRMwcet
Tag Type
GRMperiod
RTtimeString
GRMwcet
RTtimeString
** The
ation
The stereotypes
stereotypes and
and tags
tags have
have been
been simplified
simplified for
for this
this present
presentation
93
Example: QoS Annotations
♦
Using the standard stereotypes...
♦Using
«GRMclient»
master : Master
1. read( )
«GRMprotResource»
{GRMperiod = 100 ms}
{GRMwcet = 20 ms}
d : DBaseServer
2. register( )
«GRMclient»
dBadmin : Admin
{GRMperiod = 150 ms}
{GRMwcet = 40 ms}
«GRMclient»
poller : Poller
{GRMperiod = 350 ms}
{GRMwcet = 100 ms}
sort( )
invoke( )
«GRMprotResource»
cs : CommServer
94
Example: Class Diagram
♦
QoS annotations can be added to classes as well
♦QoS
«GRMprotResource»
DBaseServer
«GRMclient»
Master
0..n
1
«GRMclient»
Admin
1
«GRMserv»read () {GRMwcet = 10ms}
«GRMserv»sort () {GRMwcet = 20ms}
0..n
0..n
«GRMprotResource»
CommServer
«GRMclient»
Poller
1
1
«GRMserv» invoke() {GRMwcet = 10ms}
«GRMserv» register() {GRMwcet = 20ms}
95
0..n
Example: Model Analysis
«GRManalysisContext»
GRManalysisContext»
Result:
Result:
aa new
new model
model with
with
analysis
analysis variable
variable
values
values set
set
{isSchedulable= .$?}
«GRManalysisContext»
GRManalysisContext»
{isSchedulable= True}
Schedulability
Analyzer
(RMA)
May
May include
include
additional
additional
tool-specific
tool-specific
results
results encased
encased
in
in UML
UML Notes
Notes
96
General Time Model
TimingServices
TimedEvents
TimeModel
TimingMechanisms
97
Physical and Measured Time
Physical
Time
Clock
(from TimingMechanisms)
1
{ordered}
0..n
n
n
PhysicalInstant
TimeValue
+measurement
kind : {discrete, dense}
0..n
+start
1
+referen ceClock
1
n
1
+end
n
+s tart
n
Duration
+measurement
0..n
0..n
98
1
+end
n
Tim eIn terval
Timing Mechanisms Model
ResourceInstance
(from CoreResourceModel)
+currentValue
TimeValue
(from TimeModel) 1
+max imalValue
0..n
TimingMec hanism
stability
0..n drift
skew
1
+origin
TimedEvent
(from TimedEvents)
1
set(time : TimeValue)
get() : TimeValue
reset()
start()
0..n pause()
0..n
1
+resolution
TimeInterval
(from Tim eModel)
+accuracy
1
1 +offset
+times tam p
1
0..n
+referenceClock
TimeValue
+duration
Timer
(from Tim eModel)
isPeriodic : Boolean 0..n
1
Clock
0..n
1
+generatedInt errupts
0..n
1..n
1
+generatedTimeouts 0..n
ClockInterrupt
(from TimedEvents)
Timeout
(from TimedEvents)
99
Example Timing Stereotype
Stereotype
«RTaction»
Base Class
Tags
RTstart
RTend
RTduration
Action
ActionExecution
Message
Stimulus
Method
ActionSequence
ActionState
SubactivityState
Transition
State
Tag
Tag Type
Multiplicity
Domain Name
RTstart
RTtimeValue
[0..1]
TimedAction::start
RTend
RTtimeValue
[0..1]
TimedAction::end
RTduration
RTtimeValue
[0..1]
TimedAction::duration
100
Timed Stimuli
0..n
StimulusGeneration +cause
(from CausalityModel)
1
+c ause 1 +cause 1
+effect
Stimulus
(from CausalityModel)
1.. n
+time
TimedStimulus
0..n
+start
1.. n
+end
0..n
/
1..n
Timeout
/
ClockInterrupt
0..n
These two associations are
derived from the general
association between
EventOccurrence and Stimulus
101
0..n
0..n
TimeValue
(from TimeModel)
Timed Events and Timed Actions
EventOccurence
(from CausalityModel)
Scenario
(from CausalityModel)
TimedAction
TimedEvent
0..n
Delay
+timestamp
1..n
+start
1..n +end 1..n
+duration
TimeInterval
(from TimeModel)
TimeValue
(from TimeModel)
102
1
Time Annotations
♦
In various behavioral diagrams (sequence, activity, state)
♦In
«PAcontext»
«PAclosedLoad»
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
b : Browser
ws : WebServer
vs : VideoServer
vp : VideoPlayer
vw : VideoWindow
processSelection
initialPlayout
confirm
«PAstep»
{PArespTime=
('req','percentile',95,500,'ms')}}
«PAstep»
{PAdemand=
('est','mean',1,'ms')}}
initializePlayer
«PAstep»
{PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
More compact forms are also
possible:
sendFrame
showFrame
«PAstep»
{PArep=$N,
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)}
InstanceA :
InstanceB :
*[$N]
terminalPlayout
«PAstep»
{PAinterval=
('req','percentile',99,30,'ms')}}
{0 ms}
{1.5 ms}
helloMsg
{2 ms}
May be very sophisticated and express complex
time values (instants and durations) including
probability distributions, percentile values, etc.
(NB: tools can help reduce visual clutter)
103
2.7 ms
{4.7 ms}
{10.2 ms}
{11 ms}
ackMsg
Notation: Timing Marks and Constraints
♦
A timing mark identifies the time of an event occurrence
♦A
• On messages:
Caller
call
Operator
sendTime()
receiveTime()
call.receiveTime()
callHandler.startTime()
ack
• On action blocks (new):
startTime()
endTime()
callHandler.endTime()
ack.sendTime()
{call.sendTime() - ack.receiveTime < 10 sec}
Timing constraint
104
Defined Stereotypes (1 of 3)
Stereotype
Applies To
Tags
Description
«RTaction»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
RTstart [0..1]
RTend [0..1]
RTduration [0..1]
An action that takes time
«RTclkInterrupt»
(subclass of
«RTstimulus»)
Stimulus, Message
RTtimestamp [0..1]
A clock interrupt
«RTclock» (subclass of
«RTtimingMechanism»)
Instance, DataType,
Classifier,
ClassifierRole…
RTclockId [0..1]
A clock mechanism
«RTdelay»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
RTduration [0..1]
A pure delay activity
«RTevent»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
RTat [0..1]
An event that occurs at a
known time instant
«RTinterval»
Instance, Object,
Classifier, DataType,
DataValue
RTintStart [0..1]
RTintEnd [0..1]
RTintDuration [0..1]
A time interval
105
Defined Stereotypes (2 of 3)
Stereotype
Applies To
Tags
Description
«RTnewClock
Operation
RTstart [0..1]
RTend [0..1]
RTduration [0..1]
An operation that creates a
new clock mechanism
«RTnewTimer»
Operation
RTtimerPar [0..1]
An operation that creates a
new timer
«RTpause»
Operation
A pause operation on a timing
mechanism
«RTreset»
Operation
An operation that resets a
timing mechanism
«RTset»
Operation
«RTstart»
Operation
«RTstimulus»
Stimulus, ActionExecution,
Action, ActionSequence,
Method
RTtimePar [0..1]
An operation that sets the
current value of a timing
mechanism
An operation that starts a
timing mechanism
RTstart [0..1]
RTend [0..1]
106
A timed stimulus
Defined Stereotypes (3 of 3)
Stereotype
Applies To
Tags
Description
«RTtime»
DataValue, Instance, Object,
DataType, Classifier
RTkind [0..1]
RTrefClk [0..1]
A time value or a time
object
«RTtimeout» (subclass
of «RTstimulus»)
Stimulus, ActionExecution,
Action, ActionSequence,
Method
RTtimestamp [0..1]
A timeout signal or a
timeout action
«RTtimer» (subclass of
«RTtimingMechanism»)
DataValue, Instance, Object,
ClassifierRole, Classifier…
RTduration [0..1]
RTperiodic [0..1]
A timer mechanism
«RTtimeService»
Instance, Object,
ClassifierRole, Classifier
«RTtimingMechanism»
DataValue, Instance,
Object,ClassifierRole,
Classifier, DataType
A time service
RTstability [0..1]
RTdrift [0..1]
RTskew [0..1]
RTmaxValue [0..1]
RTorigin [0..1]
RTresolution [0..1]
RTaccuracy [0..1]
RTcurrentVal [0..1]
RToffset [0..1]
RTrefClk [0..1]
107
A timing mechanism
Specifying Time Values
♦
Time values can be represented by a special stereotype
♦Time
of Value («
RTtimeValue») in different formats; e.g.
(«RTtimeValue»)
■
■
■
■
■
■
■
■
■
■
■
■
■
■
12:04
12:04 (time
(time of
of day)
day)
5.3,
5.3, ‘ms’
‘ms’ (time
(time interval)
interval)
2000/10/27
2000/10/27 (date)
(date)
Wed
Wed (day
(day of
of week)
week)
$$param,
param, ‘ms’ (parameterized
(parameterized value)
value)
‘‘poisson’,
poisson’, 5.4,
5.4, ‘sec’
‘sec’ (time
(time value
value with
with a Poisson distribution)
‘histogram’
‘histogram’ 0,
0, 0.3
0.3 1,
1, 0.4
0.4 2,
2, 0.3,
0.3, 3,
3, ‘ms’
‘ms’
P=0.4
P=0.3
0 ms
1 ms
P=0.3
2 ms
3 ms
108
Specifying Arrival Patterns
♦
Method for specifying standard arrival pattern values
♦Method
■
■
■
■
■
■
■
■
■
■
Bounded: ‘bounded’, <min
-interval>, <max
-interval>
<min-interval>,
<max-interval>
Bursty
bursty’, <burst
-interval> <max.no.events>
Bursty:: ‘‘bursty’,
<burst-interval>
Irregular: ‘irregular’, <interarrival
-time>, [<interarrival
-time>]*
<interarrival-time>,
[<interarrival-time>]*
Periodic: ‘periodic’, <period> [, <max
-deviation>]
<max-deviation>]
Unbounded: ‘unbounded’, <probability
-distribution>
<probability-distribution>
♦
Probability distributions supported:
♦Probability
■
■
Bernoulli, Binomial, Exponential, Gamma, Geometric,
Histogram, Normal, Poisson, Uniform
109
General Concurrency Modeling
ActiveResource
(from ResourceTypes)
/
1.. n
Res ourceServiceInst ance
(from CoreResourceModel)
ConcurrentUnit
1
1
/
/
ProtectedResource
(from ResourceTypes)
+methodE xecution 0..n
DeferredService
Immediat eServic e
1 +main
StimuliQueue
Scenario
(from CausalityModel)
threading
1..n
0...
+step 1..n
0...
ActionExecution
(from DynamicUsageModel)
isAtomic : Boolean
MessageAction
+cause / +effect
1
SynchronousInvoke
Stimulus
(from CausalityModel)
StimulusGeneration
(from
CausalityModel)
1.. n
Asy nchronousInvoke
110
Defined Stereotypes
Stereotype
Applies To
Tags
CRAtomic [0..1]
Description
«CRAction»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
An action execution
«CRAsynch»
Action, ActionExecution
«CRConcurrent»
Node, Component,
Artifact, Class, Instance
«CRContains»
Usage
A generalized usage
dependency
«CRDeferred»
Operation, Reception,
Message, Stimulus
A deferred receive
«CRImmediate»
Operation, Reception,
Message, Stimulus
«CRmsgQ»
Instance, Object, Class,
ClassifierRole
A stimuli queue
«CRSynch»
Action, ActionExecution
A synchronous invoke
An asynchronous invocation
CRMain [0..1]
{remote, local} [0..1]
111
A concurrent unit concept
An instance of an immediate
service
Performance Analysis Concepts
PerformanceContext
0.. n
1
1
1..n
1..n
1..n
W orkload
responseTime 1..n
priority
PScenario
1 hostExecutionDemand
responseTime
+resource
0..n
0..n
1
PResource
0..n utilization
schedulingPolicy
throughput
<<deploys>>
ClosedWorkload
population
externalDelay
OpenWorkload
+root
{ordered}
+host 0..1
1..n
1
oc currencePat tern
PStep
probabilty
+successor repetition
delay
0..n operations
interval
executionTime
+predecessor 0..n
112
PProcessingResource
processingRate
contextSwitchTime
priorityRange
isPreemptible
PPassiveResource
waitingTime
responseTime
capacity
accessTime
Relationship to General Resource Model
UsageDemand
AnalysisContext
(from ResourceUsageModel) (from ResourceUsageModel)
Workload
PerformanceCont ext
PassiveResource
ProtectedResource
(from ResourceTypes) (from ResourceTypes)
PPassiveResource
Scenario
(from CausalityModel)
PScenario
Act iveResource
(from ResourceTypes)
PProcessingResource
waitingTime
responseTime
capacity
accessTime
processingRate
contextSwitchTime
priorityRange
isPreemptible
113
Example: Web Video Application
Engineering Instance Model
vp : VideoPlayer
vw : VideoWindow
b : Browser
ws : WebServer
«GRMdeploys»
«GRMdeploys»
vs : VideoServer
«GRMdeploys»
Logical Instance Model
:ClientWorkstation
vw : VideoWindow
: WebServerNode
: VideoServerNode
b : Browser
: Internet
vp : VideoPlayer
ws : WebServer
Usage Scenario
b : Browser
vs : VideoServer
ws : WebServer
vs : VideoServer
vp : VideoPlayer
vw : VideoWindow
processSelection
initialPlayout
initializePlayer
confirm
sendFrame
showFrame
*[$N]
terminalPlayout
114
Example: Performance Requirements
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
Estimated video server processing demand per frame = 10 ms
Estimated viewer processing demand per frame = 15 ms (dev = 20 m
s)
ms)
Assumed network delay distribution: exponential with mean = 10 m
mss
Measured packets per frame (LAN) = 65
Measured video server file operations per frame = 12
Max. number of concurrent users = $$Nusers
Nusers
Average inter
-session times = 20 minutes
inter-session
Frames in a video $N
Video frame intervval = 30 ms
Required confirmation delay: 95% < 500 ms
Required interval between frame displays = 99% < 30 ms
115
Example: Annotations for a Scenario
«PAcontext»
«PAclosedLoad»
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
b : Browser
ws : WebServer
vs : VideoServer
vp : VideoPlayer
vw : VideoWindow
processSelection
initialPlayout
confirm
«PAstep»
{PArespTime=
('req','percentile',95,500,'ms')}}
initializePlayer
«PAstep»
{PAdemand=
('est','mean',1,'ms')}}
«PAstep»
{PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
sendFrame
showFrame
«PAstep»
{PArep=$N,
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)}
*[$N]
terminalPlayout
«PAstep»
{PAinterval=
('req','percentile',99,30,'ms')}}
116
Example: More Annotations
«PAcontext»
vp : VideoPlayer
vw : VideoWindow
«GRMdeploys»
{PAschdPolicy=PR,
PArate=1,
PAutilization=$Util,
PActxtSwT=('est','mean',40,'us')}
«PAhost»
:ClientWorkstation
b : Browser
ws : W ebServer
«GRMdeploys»
«PAhost»
: WebServerNode
vs : VideoServer
«GRMdeploys»
«PAhost»
: VideoServerNode
«PAcontext»
vs : VideoServer
vp : VideoPlayer
vw : VideoW indow
: Internet
«PAstep»
send
frame
{PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)}
«PAstep»
receive
frame
{PAinterval=
('req','percentile',99,30,'ms')}}
117
{PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
«PAstep»
show
frame
Defined Stereotypes (1 of 2)
Stereotype
Applies To
Tags
PArespTime [0..*]
PApriority [0..1]
PApopulation [0..1]
PAextDelay [0..1]
Description
«PAclosedLoad»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
A closed workload
«PAcontext»
Collaboration,
CollaborationInstanceSet,
ActivityGraph
«PAhost»
Classifier, Node,
ClassifierRole, Instance,
Partition
PAutilization [0..*]
PAschdPolicy [0..1]
PArate [0..1]
PActxtSwT [0..1]
PAprioRange [0..1]
PApreemptible [0..1]
PAthroughput [0..1]
A deferred receive
«PAopenLoad»
Action, ActionExecution,
Stimulus, Action,
Message, Method…
PArespTime [0..*]
PApriority [0..1]
PAoccurrence [0..1]
An open workload
A performance analysis
context
118
Defined Stereotypes (2 of 2)
Stereotype
Applies To
Tags
Description
«PAresource»
Classifier, Node,
ClassifierRole, Instance,
Partition
PAutilization [0..*]
PAschdPolicy [0..1]
PAcapacity [0..1]
PAmaxTime [0..1]
PArespTime [0..1]
PAwaitTime [0..1]
PAthroughput [0..1]
A passive resource
«PAstep»
Message, ActionState,
Stimulus, SubactivityState
PAdemand [0..1]
PArespTime [0..1]
PAprob [0..1]
PArep [0..1]
PAdelay [0..1]
PAextOp [0..1]
PAinterval [0..1]
A step in a scenario
119
Specifying Performance Values
♦
A complex structured string with the following format
♦A
■
■
<kind
-of-value> , <modifier> , <time
-value>
<kind-of-value>
<time-value>
♦
Where:
♦Where:
■
■
■
■
■
■
■
■
<kind
-of-value> ::= ‘‘req’
req’ | ‘‘assm’
assm’ | ‘‘pred’
pred’ | ‘‘msr’
msr’
<kind-of-value>
Required, assumed, predicted, measured
<modifier> ::= ‘mean’ | ‘sigma’ | ‘‘kth-mom’
kth-mom’ , <Integer> |
‘max’ | ‘percentile’ <Real> | ‘dist’
E.g.:
{{PAdemand
PAdemand = (‘(‘msr’,
msr’, ‘mean’, (20, ‘ms’))}
120
Schedulability Analysis Sub-Profile
SAction
0..n
RealTimeSituation
Priority
0..n
Worst-case Completion Time
0..n
Delay Time
1..n
0..n
+precedents Preempted Time
SResource
ExecutionEngine
Ready Time
+usedResources
+ownedResource s
0..n
Release Time
Capacity
Priority Range
/
0..n
0..n Acquisition Time
Blocking Time
0..1 Processing Rate
0..n
Laxity
Deacquisition Time
Context Switch Time
Absolute Deadline
isConsumable
Utilization
Relative Deadline
Priority Ceiling
isPreemptible
isAtomic
isPreemptible
isSchedulable
0..n
<<deploys>>
R espo nse
Utilization
Spare Capacity
Overlaps
Slack Time
+effect 1
+host 1
0..n
1
Sche dulingPolicy
1
1
1
Trigger
0..n
isSchedulable
0..n
1..n
SchedulingJob
/
+cause
1
<<deploys>>
+host Schedulabl eR esource
1
0 ..n
1
1
121
Policies Supported
♦
Scheduling Policies:
♦Scheduling
■
■
■
■
Rate Monotonic, Deadline Monotonic, HKL, Fixed Priority,
Minimum Laxity First, Maximize Accrued Utility, Minimum
Slack Time
…may be extended in the future
♦
Access Control Policies:
♦Access
■
■
■
■
FIFO, Priority Inheritance, No Preemption, Highest Lockers,
Priority Ceiling
…may be extended in the future
122
Example
♦
A simple telemetry system with 3 cyclical tasks
♦A
A.1.1:main ( )
Sensors
:SensorInterface
A.1:gatherData ( )
TelemetryGatherer
:DataGatherer
TGClock : Clock
TGClock : Clock
A.1.1.1: writeStorage ( )
C.1:displayData ( )
SensorData
:RawDataStorage
B.1.1 : main ( )
C.1.1.1: readStorage ( )
TelemetryDisplayer
: DataDisplayer
C.1.1 : main ( )
B.1.1.1: readStorage ( )
TelemetryProcessor
:DataProcessor
Display
:DisplayInterface
B.1:filterData ( )
TGClock : Clock
123
Example: Schedulability Annotations
«SASituation»
Sensors
:SensorInterface
«SAAction»
{SAPriority=2,
A.1.1:main ( )
SAWorstCase=(93,'ms'),
RTduration=(33.5,'ms')}
TelemetryGatherer
«SASchedulable»
:DataGatherer
TGClock : Clock
«SATrigger»
{SASchedulable=$R1,
RTat=('periodic',100,'ms')}
A.1:gatherData ( )
«SAResponse»
{SAAbsDeadline=(100,'ms')}
Result
Result
TGClock : Clock
«SAAction»
A.1.1.1: writeStorage ( )
{RTstart=(16.5,'ms'),
RTend=(33.5,'ms')}
«SAResource»
«SATrigger»
{SASchedulable=$R2,
RTat=('periodic',60,'ms')}
C.1:displayData ( )
«SAResponse»
{SAAbsDeadline=(60,'ms')}
TelemetryDisplayer
«SASchedulable»
: DataDisplayer
«SAResponse»
{SAPriority=1,
C.1.1 : main ( )
SAWorstCase=(50.5,'ms'),
RTduration=(12.5,'ms')}
{SACapacity=1,
SensorData
SAAccessControl=PriorityInheritance}
:RawDataStorage
«SAAction»
C.1.1.1: readStorage ( )
{RTstart=(3,'ms'),
RTend=(5,'ms')}
Display
:DisplayInterface
«SAResponse»
{SAPriority=3,
B.1.1 : main ( )
SAWorstCase=(177,'ms'),
RTduration=(46.5,'ms')}
«SAAction»
B.1.1.1: readStorage ( )
{RTstart=(10,'ms'),
RTend=(31.5,'ms')}
TelemetryProcessor
«SASchedulable»
:DataProcessor
«SATrigger»
{SASchedulable=$R3,
RTat=('periodic',200,'ms')}
B.1:filterData ( )
«SAResponse»
{SAAbsDeadline=(200,'ms')}
TGClock : Clock
124
Example: Deployment Specification
«SASchedulable»
«SASchedulable»
«SASchedulable»
TelemetryDisplayer
: DataDisplayer
TelemetryGatherer
:DataGatherer
TelemetryProcessor
:DataProcessor
«GRMdeploys»
«SAEngine»
{SARate=1,
SASchedulingPolicy=FixedPriority}
:Ix86Processor
125
«SAOwns»
«SAResource»
SensorData
:RawDataStorage
Example: Analysis Results
«SASituation»
Additional
Additional
tool-specific
tool-specific
results
results encased
encased
in
in UML
UML Notes
Notes
«SAAction»
{SAPriority=2,
SAWorstCase=(93,'ms'),
RTduration=(33.5,'ms')}
A.1.1:main ( )
Sensors
:SensorInterface
«SASchedulable»
TelemetryGatherer
:DataGatherer
TGClock : Clock
«SAAction»
{RTstart=(16.5,'ms'),
RTend=(33.5,'ms')}
A.1.1.1: writeStorage ( )
TGClock : Clock
«SATrigger»
{SASchedulable=$true
RTat=('periodic',60,'ms')}
«SAResponse»
{SAAbsDeadline=(60,'ms')}
C.1:displayData ( )
«SATrigger»
{SASchedulable=$true,
RTat=('periodic',100,'ms')}
«SAResponse»
{SAAbsDeadline=(100,'ms')}
A.1:gatherData ( )
«SAResource»
{SACapacity=1,
SAAccessControl=PriorityInheritance}
SensorData
:RawDataStorage
«SAAction»
{RTstart=(3,'ms'),
RTend=(5,'ms')}
C.1.1.1: readStorage ( )
«SAAction»
{RTstart=(10,'ms'),
RTend=(31.5,'ms')}
B.1.1.1: readStorage ( )
«SAResponse»
{SAPriority=3,
SAWorstCase=(177,'ms'),
RTduration=(46.5,'ms')}
B.1.1 : main ( )
«SASchedulable»
«SASchedulable»
TelemetryDisplayer
: DataDisplayer
TelemetryProcessor
:DataProcessor
«SAResponse»
{SAPriority=1,
SAWorstCase=(50.5,'ms'),
RTduration=(12.5,'ms')}
C.1.1 : main ( )
Display
:DisplayInterface
«SATrigger»
{SASchedulable=$true
RTat=('periodic',200,'ms')}
«SAResponse»
{SAAbsDeadline=(200,'ms')}
B.1:filterData ( )
TGClock : Clock
126
Defined Stereotypes (1 of 3)
Stereotype
Applies To
Tags
«SAAction»
(subclass of «RTaction»
and «CRAction»)
Action, ActionExecution,
Stimulus, Action,
Message, Method…
SAPriority [0..1]
SAActualPty [0..1]
SABlocking [0..1] SAReady
[0..1]
SADelay [0..1]
SARelease [0..1]
SAPreempted [0..1]
SAWorstCase [0..1]
SALaxity [0..1] SAPriority
[0..1]
SAAbsDeadline [0..1]
SARelDeadline [0..1]
SAusedResource [0..1]
SAhost [0..1]
An action
«SAEngine»
Node, Instance, Object,
Classifier, ClassifierRole
SASchedulingPolicy [0..1]
SAAccessPolicy [0..1]
SARate [0..1]
SAContextSwitch [0..1]
SAPriorityRange [0..1]
SAPreemptible [0..1]
SAUtilization [0..1]
SASchedulable [0..1]
Saresources [0..1]
An execution engine
127
Description
Defined Stereotypes (2 of 3)
Stereotype
Applies To
Tags
Description
«SAOwns»
(subclass of
«GRMrealize»)
Abstraction
Identifies ownership of
resources
«SAPrecedes»
Usage
A precedence relationship
between actions and triggers
«SAResource»
Classifier, ClassifierRole,
Instance, Object, Node
«SAResponse» (subclass Action, ActionExecution,
of «SAAction»)
Stimulus, Action,
Message, Method…
«SASchedulable»
(subclass of
«SAResource»)
SAAccessControl [0..1]
SAConsumable [0..1]
SACapacity [0..1]
SAAcquisition [0..1]
SADeacquisition [0..1]
SAPtyCeiling [0..1]
SAPreemptible [0..1]
A resource of some kind
SAUtilization [0..1]
SASpare [0..1]
SASlack [0..1]
SAOverlaps [0..1]
A response to a stimulus or
action
Classifier, ClassifierRole,
Instance, Object, Node
A schedulable resource
128
Defined Stereotypes (3 of 3)
Stereotype
Applies To
Tags
Description
«SAScheduler»
Classifier, ClassifierRole, SASchedulingPolicy [0..1]
Instance, Object
SAExecutionEngine [0..1]
A scheduler
«SAPrecedes»
Usage
A precedence
relationship between
actions and triggers
«SASituation»
Collaboration,
CollaborationInstance,
ActivityGraph
A schedulability analysis
context
«SATrigger» (subclass of Message, Stimulus
«SAAction»)
SASchedulable [0..1]
SASAprecedents [0..1]
A trigger
«SAusedHost»
Usage
Identifies schedulable
resources used for
execution of actions
«SAUses»
Usage
Identifies sharable
resources
129
Real-Time CORBA: Schedulability Sub-Profile
SResource
(from Sche dulin gDomanModel )
Response
0.. n
+usedResources
(from SchedulingDomanModel)
/
+ownedResources
RTCmutex
0..n
0.. n
+usedResources
0..n
/
1..n
RTCserver
0.. n
serverPriority
1
0..n
+usedResources
/
1..n
0..n +clientScenario
RTCconnection
isShared
hiPriority
loPriority
0..n
SchedulableResourc e
ExecutionEngine
(from SchedulingDomanModel)
(from SchedulingDomanModel)
1
RTCclient
timeout
1..n
clientPriority
private
/
+hos t
<<deploys>>
1
130
+host
RTCorb
1
/
<<deploys>>
/
Example: RT CORBA
«SASituation»
«RSAserver»
{SACapacity=10}
Sensor2
:SensorInterface
«RTclock»
TGClock : Clock
«RSAclient»
{RSAtimeout=(105,'ms),
RSAclPrio=12
TelemetryGatherer
: DataGatherer
«RSAserver»
{SACapacity=4}
Sensor1
:SensorInterface
«GRMdeploys»
«GRMdeploys»
«GRMdeploys»
«GRMdeploys»
«RSAorb»
{SASchedulingPolicy=
'RateMonotonic'}
TG-ORB: RTOrb
«GRMdeploys»
«RSAorb»
{SASchedulingPolicy=
'RateMonotonic'}
S1-ORB: RTOrb
«GRMdeploys»
«SAEngine»
{SASchedulingPolicy=
'RateMonotonic',
SARate=1}
P1 : I586
«RSAorb»
{SASchedulingPolicy=
'RateMonotonic'}
S2-ORB: RTOrb
«GRMdeploys»
«SAEngine»
{SASchedulingPolicy=
'RateMonotonic',
SARate=0.5}
P2 : Ix86
131
Example: RT CORBA Usage Scenario
«SASituation»
«RSAclient»
TelemetryGatherer
: DataGatherer
«RTclock»
TGClock
«RSAserver»
Sensor1
:SensorInterface
«RSAserver»
Sensor2
:SensorInterface
«RTevent» {RTat=('periodic', 100, 'ms')}
tick ( )
«SAAction»
{SAW orstCase=(15,'ms'),
RTduration=(10,'ms')}
readSensor ( )
«SAresponse»
{SAAbsDeadline
=(100,'ms')
«SAAction»
{SAW orstCase=(30,'ms'),
RTduration=(20,'ms')}
readSensor ( )
«SAAction»
{SAW orstCase=(25,'ms'),
RTduration=(5,'ms')}
compare ( )
132
Defined Stereotypes
Stereotype
Applies To
Tags
Description
«RSAclient»
(subclass of
«SASchedulable»)
Classifier, ClassifierRole, RSAtimeout [0..1]
Instance, Object, Node
RSAclPrio [0..1]
RSAprivate [0..1]
RSAhost [0..1]
An RT CORBA client
«RSAconnection»
(subclass of
«SASchedulable» and
«SAResource»)
Classifier, ClassifierRole, SAAccessControl [0..1]
Instance, Object, Node
RSAshared [0..1]
RSAhiPrio [0..1]
RSAloPrio [0..1]
RSAserver [0..1]
An RT CORBA
connection
«RSAmutex»
(subclass of
«SAResource»)
Classifier, ClassifierRole, SAAccessControl [0..1]
Instance, Object, Node
RSAhost [0..1]
An RT CORBA mutex
«RSAorb»
(subclass of
«SAResource» )
Classifier, ClassifierRole, SAschedulingPolicy [0..1]
Instance, Object, Node
An RT CORBA ORB
«RSAserver»
(subclass of
«SAResource» )
Classifier, ClassifierRole, RSAsrvPrio [0..1]
Instance, Object, Node
SACapacity [0..1]
An RT CORBA server
133
Real Time CORBA: Infrastructure Model
<<CORBAModule>>
CORBA
<<CORBAModule> >
IOP
<<CORBAModule>>
PortableServer
<<CORBAModule>>
RTPortableServer
<<CORBAModule>>
RTCORBA
<<CORBAModule>>
RTCosScheduling
134
Model Processing Paradigm and Tools
Configuration
Data Set
Model Processor
3
Model
Configurer
Configured
UML Model
(XMI)
4
5
Model
Convertor
Domain
Model
6
2
Parametrized
UML Model
(XMI)
Model
Analyzer
1
7
10
Model
Editor
Results
UML Model
(XMI)
9
Results
Convertor
135
8
Processing
Results
Processing
Control
Specification
The Tag Value Language
♦
Tagged value format:
♦Tagged
{<tag
-name> = <tag
-value>}
{<tag-name>
<tag-value>}
♦
Used to specify complex (structured) tagged values
♦Used
♦
Based on a small proper subset of the freeware Perl
♦Based
language
■
■
Includes: variables, numbers, booleans
booleans,, strings, lists,
expressions (including conditionals), operators, and functions
♦
Suitable for:
♦Suitable
■
■
■
■
expressing complex dependencies between values
writing processing scripts
136
Summary: The Real Time UML Profile
♦
The RT UML Profile defines a set of extensions for
♦The
directly expressing real
-time domain concepts in UML:
real-time
■
■
■
■
■
■
resources
concurrency mechanisms
time and timing mechanisms
♦
Furthermore, it allows the specification of quantitative
♦Furthermore,
aspects in the same models such that the models can be
analyzed
■
■
predictive models that can be used to validate (risky) design
approaches before major investments are made
137
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
■
■
Real
-Time System Essentials
Real-Time
Essentials of the Object Paradigm
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
138
Common Wisdom...
♦
When designing software, we are instructed to ignore
♦When
details of the technology and similar “implementation”
issues until we have a sound logical solution to the
problem
■
■
simplifies the design problem (separation of concerns)
■
■
software is portable to new/different technologies
♦
But, what about real
-time systems?
♦But,
real-time
139
The Ideal and the Real
♦ The idealized “forms” of pure logic acquire the finite
characteristics of the physical stuff out of which they are
spun
■
limited speed, limited capacity, limited availability,...
140
Real System Design Issues (1)
♦
Possibility of out
-of-date state information due to lengthy
♦Possibility
out-of-date
(and variable) transmission delays
Node1 (New York)
Node2 (Tokyo)
observer
on
“on”
“on”
State?
State?
“on”
“on”
It’s
It’s aa game
game of
of numbers!
numbers!
141
off
Real System Design Issues (2)
♦
Inconsistent views of system state:
♦Inconsistent
■
■
different observers see different event orderings
clientA
clientA
notifier1
notifier1
notifier2
notifier2
clientB
clientB
e2
e2
e1
e1
e1
e1
e2
e2
time
It’s
It’s aa game
game of
of numbers!
numbers!
142
Distributed System Characteristics
♦
Key characteristics:
♦Key
■
■
■
■
■
■
■
■
concurrency and asynchrony
need for communication and synchronization between sites
communication delays
possibility of partial failure
♦
Each of these adds significant “weight” to the
♦Each
programming problem
♦
Distributed programming is different from and much more
♦Distributed
complex than conventional programming
143
Real-World Real-Time Design Issues
♦
Much of the complexity associated with these systems is
♦Much
the result of the “intrusion” of the inherently complex
physical world into the idealized logical world of software
♦
The real
-time design dilemma:
♦The
real-time
if the physical world intrudes on the logical world, how can we
separate the “logical” world of design from the “physical” world
of implementation to achieve portability?
144
Logical (Conceptual) Viewpoint
♦
A technology
-independent view of the software
♦A
technology-independent
■
■
a “virtual” mechanism realized by a computer
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL
SURFACES
SURFACES
GROUND
GROUND
MODEL
MODEL
ENGINES
ENGINES
145
PILOT
PILOT
CONTROLS
CONTROLS
Engineering (Realization) Viewpoint
♦
The realization of a specific set of logical components
♦The
using facilities of the run
-time environment
run-time
Processor
OS
OS process
process
Processor
Ethernet LAN
OS
OS process
process
stack
stack
TCP/IP
TCP/IP socket
socket
TCP/IP
TCP/IP socket
socket
OS
OS process
process
stack
146
Views and Mappings
Logical
Logical View
View
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL
SURFACES
SURFACES
GROUND
GROUND
MODEL
MODEL
PILOT
PILOT
CONTROLS
CONTROLS
ENGINES
ENGINES
Realization
Realization
mappings
mappings
Engineering
Engineering View
View
Processor
OS
OSprocess
process
Processor
stack
Ethernet LAN
OS
OSprocess
process
stack
TCP/IP
TCP/IPsocket
socket
TCP/IP
TCP/IPsocket
socket
OS
OSprocess
process
stack
147
Realization Mappings
♦
A correspondence between elements of two distinct
♦A
models (logical and engineering)
♦
Semantics: the logical elements are implemented by the
♦Semantics:
corresponding engineering model elements
■
■
logical elements can be viewed as “residing” on the
corresponding engineering elements
AIRFRAME
AIRFRAME
CONTROL
CONTROL
SURFACES
SURFACES
Model
Model 11
OS
OS process1
process1
Processor
OS
OS process1
process1
Model
Model 22
148
Model
Model 33
Selecting a Level of Abstraction
♦
Intermediate levels may be abstracted out
♦Intermediate
■
■
■
■
depends on the desired granularity of modeling
affects the semantics of the realization relationship
AIRFRAME
AIRFRAME
OS
OS process1
process1
CONTROL
CONTROL
SURFACES
SURFACES
OS
OS process1
process1
Model
Model 11
Model
Model 22
AIRFRAME
AIRFRAME
Processor
Model
Model 33
Processor
CONTROL
CONTROL
SURFACES
SURFACES
Model
Model 11
Model
Model 33
149
The Engineering Viewpoint in RT Systems
♦ The engineering view represents the “raw material” out of which
we construct the logical view
■
■
■
■
the quality of the outcome is only as good as the quality of the
ingredients that are put in
as in all true engineering, the quantitative aspects are often ccrucial
rucial (How
long will it take? How much will be required?…)
♦ The ability to accurately model the relationship between the
engineering and logical models is crucial to real
-time system
real-time
design
■
■
Unfortunately, UML deployment diagrams are inadequate
150
The Resource Model and Realization
Airframe
CPU :
3 MIPs
Mem :
2MB
client
client
Bandw.
Bandw. :
70Mbit/s
required
required QoS
QoS values
values
resource
resource “usage”
“usage”
3MIPs
20MB
CPU
CPU
100Mbit/s
LAN
LAN
environment
environment “services”
“services”
(offered
(offered QoS
QoS values)
values)
resources
resources
⇒
The same QoS framework can be used for quantifying
⇒The
realization relationships
151
Two Interpretations of Resource Model
♦
The peer interpretation
♦The
client
client
accesses➨
accesses➨
resource
resource
♦
The layered interpretation (the 22-viewpoint
-viewpoint model)
♦The
Logical
Logical View
View
«realize»
«realize»
Engineering
Engineering View
View
WinNT
WinNT
Process
Process
152
WinNT
WinNT
Process
Process
Example: Realization Relationships
♦
For sophisticated multi
-layer deployment modeling
♦For
multi-layer
TSensor: TemperatueSensor
{cycle = “20 msec”}
instPanel: Register
{cycle = “40 msec”}
injector: FIControl
{cycle = “20 msec”}
«GRMdeploys»
temp : Temperature
«GRMdeploys»
«GRMdeploys»
«GRMdeploys»
«OSprocess»
HostProcess: P
«LWT»
Thread1 : T
{ctxtSw = “10usec”}
«LWT»
Thread2 : T
{ctxtSw = “10usec”}
{ctxtSw = “80usec”;
heap = “30 kB}
«LWT»
Thread3 : T
{ctxtSw = “10usec”}
153
Forms of Realization
154
Modeling Realization in UML
♦
An association between models with explicit realization
♦An
mappings between model elements
Logical
Logical Model
Model
A
Engineering
Engineering Model
Model
«GRMrealizes»
«GRMrealizes»
asc
X
Y
Z
B
Source element Dest. elements
Compact
Compact tabular
tabular form
form
A
X, Y
asc
Y
B
Z
deployment table
155
AA stereotype
stereotype of
of the
the
UML
UML realizes
realizes relationship
relationship
Specifying Realization Mappings
♦
Captures the specifics of the realization mapping
♦Captures
■
■
Either as a string (tag value) or as a table
Logical
Elements
<List of logical
model
elements>
Engineering
Elements
<List of
corresponding
engineering
model elements>
Mode
Linkage
<If there are multiple
engineering elements,
one of:>
{inclusive,
exclusiveStatic,
exclusiveDynamic}
L1
E1
…
156
<Interaction mode
between levels, one
of:>
{sync,
async,
replace}
Additional
Constraints
<Any additional
constraints that
apply to the
mapping>
L
sync = SW to SW
async = SW to SW
replace = SW to HW
En
E
Engineering-Oriented Design (EOD)
♦
Analysis and design of software systems based on use of
♦Analysis
■
■
■
■
■
■
Models
QoS specifications (accounting for physical properties)
Quantitative analysis techniques and simulation
♦
Complements any model
-based development method
♦Complements
model-based
♦
Advantages:
♦Advantages:
■
■
■
■
■
■
Higher reliability (simplification due to modeling)
Ability to predict system characteristics (and major design
flaws) prior to full realization
Portability!
157
Achieving Portability with EOD
♦
Dilemma: How can we account for the engineering
♦Dilemma:
aspects of the system without prematurely and possibly
unnecessarily committing to a particular technology?
-independent
♦
Approach: Provide an abstract technology
technology-independent
♦Approach:
but quantified specification of the required characteristics
of the engineering model as part of the logical model
158
Viewpoint Separation
♦
Required Environment
-neutral environment
♦Required
Environment:: a technology
technology-neutral
specification required by the logical elements of a model
Logical
Logical View
View
Required
Required Environment
Environment
Engineering
Engineering View
View (alternative
(alternative A)
A)
UNIX
UNIX
Process
Process
Engineering
Engineering View
View (alternative
(alternative B)
B)
UNIX
UNIX
Process
Process
WinNT
WinNT
Process
Process
159
WinNT
WinNT
Process
Process
Required Environment Partitions
♦
Logical elements often share common QoS requirements
♦Logical
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL
SURFACES
SURFACES
GROUND
GROUND
MODEL
MODEL
ENGINES
ENGINES
PILOT
PILOT
CONTROLS
CONTROLS
QoS
QoS domain
domain
(e.g.,failure
(e.g.,failure unit,
unit,
uniform
uniform comm
comm properties)
properties)
160
QoS Domains
♦
Specify a domain in which certain QoS values apply
♦Specify
universally:
■
■
■
■
■
■
■
■
failure characteristics (failure modes, availability, reliabilit
y)
reliability)
CPU performance
communications characteristics (delay, throughput, capacity)
etc.
♦
The QoS values of a domain can be compared against
♦The
those of a concrete engineering environment to see if a
given environment is adequate for a specific model
161
Modeling QoS Domains in UML
♦
Similar to realization: mapping of logical elements to a
♦Similar
desired (required) engineering environment
Logical
Logical View
View
«GRMrequires»:
«GRMrequires»:
aa specialization
specialization of
of the
the
“realizes”
“realizes” relationship
relationship
Required
Required Environment
Environment
AA local
local “engineering”
“engineering” model
model
QoS1
QoS1
QoS2
QoS2
Stereotype
UML base
concepts
GRM requires
GRM realizes
162
QoS3
QoS3
Tags
N/A
Example: QoS Domain for an Active Object
♦
Using a stereotype of Node
♦Using
■
■
in conjunction with the “required environment” relationship
Active
Active class
class
R
R
readObj
readObj ()
()
Stereotype
GRMthreadEnv
UML base
concepts
Node,
Instance
«GRMrequires»
«GRMrequires»
«GRMthreadEnv»
ThreadForR
{priority = 3; heap = 20 KB;
stack = 3 KB}
Environment
Environment expected
expected
by
by instances
instances of
of class
class RR
163
Tags
priority [0..1] : Integer
heap [0..1] : Real
stack [0..1] : Real
Example: Task Allocation
♦
The allocation of logical model to engineering model
♦The
elements
Task1
d : DBaseServer
master : Master
Task2
dBadmin : Admin
MainTask
Task3
poller : Poller
cs : CommServer
164
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
d : DBaseServer
master : Master
dBadmin : Admin
«GRMrequires»
«GRMrequires»
poller : Poller
cs : CommServer
«GRMrequires»
«GRMrequires»
EngineeringPkgY
EngineeringPkgY
Task1 : Task
«GRMrequires»
«GRMrequires»
«GRMrequires»
«GRMrequires»
Task3 : Task
Task2 : Task
EngineeringPkgZ
EngineeringPkgZ
MainTask : Task
«import»
«import»
«GRMschedulableEntity»
Task
165
«GRMrequires»
«GRMrequires»
Example: Completing the Mapping
♦
Mapping to hardware
♦Mapping
EngineeringPkgY
EngineeringPkgY
Task1 : Task
«GRMrealize»
«GRMrealize»
Task3 : Task
Task2 : Task
«GRMrealize»
«GRMrealize»
«GRMrealize»
«GRMrealize»
EngineeringPkgD
EngineeringPkgD
«SAProcessingResource»
Proc1
166
MainTask : Task
«GRMrealize»
«GRMrealize»
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
d : DBaseServer
master : Master
dBadmin : Admin
«GRMrealize»
«GRMrealize»
poller : Poller
cs : CommServer
«GRMrealize»
«GRMrealize»
EngineeringPkgY
EngineeringPkgY
Task1 : Task
«GRMrealize»
«GRMrealize»
Task3 : Task
Task2 : Task
EngineeringPkgZ
EngineeringPkgZ
«GRMrealize»
«GRMrealize»
MainTask : Task
«import»
«import»
«GRMschedulableEntity»
Task
167
«GRMrealize»
«GRMrealize»
Example: Completing the Mapping
♦
Mapping to hardware
♦Mapping
EngineeringPkgY
EngineeringPkgY
Task1 : Task
«GRMrealize»
«GRMrealize»
Task3 : Task
Task2 : Task
«GRMrealize»
«GRMrealize»
«GRMrealize»
«GRMrealize»
EngineeringPkgD
EngineeringPkgD
«SAProcessingResource»
Proc1
168
MainTask : Task
«GRMrealize»
«GRMrealize»
Summary: RT Design and Engineering
♦
In complex RT systems, the logical design is strongly
♦In
influenced by the characteristics of the engineering
environment
♦
In such systems, it is often crucial to formally determine if
♦In
a system will meet its non
-functional requirements
non-functional
(throughput, response time, availability, etc.)
♦
The QoS
-based approach described here can serve as a
♦The
QoS-based
basis for:
■
■
■
■
quantitative analysis of UML
-based models
UML-based
a real
-time modeling standard that will facilitate automated
real-time
exchange between design and analysis tools
169
♦
Real-Time Systems and the Object Paradigm
♦Real-Time
■
■
■
■
Real
-Time System Essentials
Real-Time
Essentials of the Object Paradigm
♦
UML as a Real
-Time Modeling Language
♦UML
Real-Time
♦
The Real
-Time UML Profile
♦The
Real-Time
♦
Engineering-Oriented Design of Real
-Time Systems
♦Engineering-Oriented
Real-Time
♦
Summary and Conclusions
♦Summary
170
Summary: The Problem
♦
Complexity!
♦Complexity!
♦
The design of real
-time systems is influenced significantly
♦The
real-time
by the physical properties of:
■
■
■
■
the environment in which the system exists
the implementation technology
♦
Most of them stem from the physical world
♦Most
■
■
the physical dimension plays a major role in the design of real
real-time software since it imposes limitations on the logical design
171
Summary: The Solution (1 of 2)
♦
The object paradigm
♦The
■
■
■
■
■
■
reduces incidental complexity
its structural bias is better suited to the real
-time domain than
real-time
the procedural paradigm
additional key features (encapsulation, inheritance,
polymorphism, etc.) add further expressive power
♦
Engineering-oriented design
♦Engineering-oriented
■
■
■
■
■
■
■
■
■
■
accounts for the physical dimension during logical design
based on a quality of service (QoS) framework as represented
in the generic resource model
allows de
-coupling from actual implementation technologies
de-coupling
(through required environment specifications)
suitable for analysis and synthesis
enables early detection of critical design flaws
172
Summary: The Solution (2 of 2)
♦
UML provides a common and standardized underpinning
♦UML
that supports all the components of our solution
■
■
■
■
■
■
■
■
■
■
for object
-oriented modeling
object-oriented
for predictive QoS modeling (via the real
-time profile)
real-time
for design analysis and synthesis (tool interchange)
for architectural definition
for implementation (through full automatic code generation)
♦
Furthermore, as a standard, it enables model interchange
♦Furthermore,
between specialized tools and is a basis for significant
automation of the RT software development process
173
Where to Obtain the RT Profile
A copy of the real
-time standard submission can be
real-time
obtained from the Object Management Group website at:
http://www.
omg.org/cgi-bin/doc?ad/2001-06-14
http://www.omg.org/cgi-bin/doc?ad/2001-06-14
174
Bibliography
♦
ny, 1972.
♦ Cooper,
Cooper, R.,
R., Introduction
Introduction to
to Queueing
Queueing Theory,
Theory, The
The Macmillan
Macmillan Compa
Company,
1972.
♦
♦ I.I. Jacobson,
Jacobson, G.
G. Booch
Booch,, and
and J.
J. Rumbaugh
Rumbaugh,, “The
“The Unified
Unified Software
Software Development
Development Process,”,
Process,”,
Addison
-Wesley, 1999.
Addison-Wesley,
1999.
♦
-Time Analysis:
♦ Klein,
Klein, M.
M. et
et al.,
al., AA Practitioner’s
Practitioner’s Handbook
Handbook for
for Real
Real-Time
Analysis: Guide
Guide to
to Rate
Rate Monotonic
Monotonic
Analysis
-Time Systems,
Analysis for
for Real
Real-Time
Systems, Kluwer
Kluwer Academic
Academic Publishers,
Publishers, 1993.
1993.
♦
agement Group,
♦ OMG,
OMG, “The
“The Unified
Unified Modeling
Modeling Language”
Language” version
version 1.3,
1.3, The
The Object
Object Man
Management
Group,
August
August 1999.
1999.
♦
““UML™ Profile
♦ OMG,
OMG, “UML™
Profile for
for Scheduling,
Scheduling, Performance,
Performance, and
and Time
Time -- Request
Request for
for Proposal”,
Proposal”, The
The
Object
-03-13).
Object Management
Management Group,
Group, March
March 1999
1999 (doc
(doc ad/99
ad/99-03-13).
♦
-Time Consortium,
rformance,
♦ UML
UML Real
Real-Time
Consortium, “Response
“Response to
to the
the OMG
OMG RFP
RFP for
for Schedulability,
Schedulability, Pe
Performance,
and
-08-04).
and Time,”
Time,” August,
August, 2000
2000 (OMG
(OMG document
document ad/2000
ad/2000-08-04).
♦
♦ J.
J. Rumbaugh
Rumbaugh,, I.I. Jacobson,
Jacobson, and
and G.
G. Booch
Booch,, “The
“The Unified
Unified Modeling
Modeling Language
Language Reference
Reference
Manual,”,
-Wesley, 1999.
Manual,”, Addison
Addison-Wesley,
1999.
♦
-Time Domain”,
♦ B.
B. Selic,
Selic, “Turning
“Turning Clockwise:
Clockwise: Using
Using UML
UML in
in the
the Real
Real-Time
Domain”, Communications
Communications of
of the
the
ACM,
-54).
ACM, vol.42,
vol.42, no.10,
no.10, October
October 1999
1999 (pp.46
(pp.46-54).
♦
♦ B.
B. Selic,
Selic, “A
“A Generic
Generic Framework
Framework for
for Modeling
Modeling Resources
Resources with
with UML,”
UML,” IEEE
IEEE Computer
Computer vol.33,
vol.33,
no.6,
-69).
no.6, June
June 2000
2000 (pp.
(pp. 64
64-69).
♦
-Time Systems,”
♦ B.
B. Selic
Selic and
and J.
J. Rumbaugh:
Rumbaugh: “Using
“Using UML
UML for
for Modeling
Modeling Complex
Complex Real
Real-Time
Systems,”
ObjecTime
://www.rational.com)
ObjecTime Limited
Limited and
and Rational
Rational Software
Software Corp.,
Corp., March
March 1998.
1998. (http
(http://www.rational.com)
175