04 1 Selic Watson RT UML - Tutorial

The Real-Time UML Standard:
Real-Time
Theory and Application
Bran Selic Ben Watson
Rational Software Canada Tri-Pacific Software, Inc.
bselic@rational.com watson@tripac.com
Tutorial Objectives
To
To clarify the relationship between the object paradigm
and real -time systems
real-time

match or mismatch?
Describe
Describe and analyze UML from a real -time designers
real-time
perspective
To
To introduce the UML Profile for Schedulability,
Performance, and Time
To
To introduce an engineering -oriented design approach
engineering-oriented
for real -time systems
real-time
2
Tutorial Overview
Real-Time
Real-Time Systems and the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
3

Real-Time

Real-Time System Essentials
Real-Time
UML
Real-Time
The
Real-Time
Real-Time
Summary
4
Real-Time System
Systems
Systems that maintain an ongoing timely interaction with
its environment
environment
signal Real-Time
source System
inputs
(state) controlled
controlled
entities
entities
signal outputs = f (inputs, state) outputs
source coordination
inputs
5
Under the Hood
AA persistent structure that provides a framework for

behavior
environment
Concurrency
Concurrency conflict
conflict
signal Real-Time
source Agent
System
inputs
(state) controlled
controlled
Agent
entities
entities
signal outputs = f (inputs, state) outputs
source Agent
coordination
inputs
6
Classifications of RT Systems
Based
Based on nature of key inputs

time-driven: for continuous (synchronous) inputs
time-driven:

event -driven: for discrete (asynchronous) inputs
event-driven:
Based
Based on time criticality

hard RT systems: every input must have a timely response

soft RT systems: most inputs must have timely response
Based
Based on load:

static: fixed deterministic load

dynamic: variable (non -deterministic) load
(non-deterministic)
Many
Many practical systems are combinations of these
7
Sample Real-Time Application
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
GROUND SURFACES CONTROLS
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES
Which procedure(s) describe this system?

8
Classical Approach: Cyclical Executive
The miscellaneous procedural slices are executed
cyclically based on time resolution
AAA BBB ACC BDD AAE BBF A CG BDH
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
Problems with the Traditional Solution
The
The solution is adjusted to fit the implementation
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
Overwhelming complexity is by far the biggest hurdle in
most real -time software systems
real-time
reducing complexity is crucial to success
10

Real-Time

Real-Time

Essentials of the Object Paradigm
UML
Real-Time
The
Real-Time
Real-Time
Summary
11
The Essence of the Object Paradigm
Combines
Combines all the various features of a logical unit
(procedures and data) into a single package called
an object
Defines a software system as a structure of
collaborating objects
Airframe
Airframe
Control
Control
Atmosphere
Atmosphere Surfaces
Surfaces
12
Objects and Real-Time Systems
The
The structure of real -time systems tends to persist
real-time
through time because it reflects the physical entities of
the real world
This
This structure is the framework through which (infinitely)
many different behavior threads are executed
Hence,
Hence, the focus is on structure rather than behavior
The
The structural focus of the object paradigm is better
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
Modeling real -time specific phenomena?
real-time

time and timing mechanisms

resources (processors, networks, semaphores, etc.)
Exploiting
Exploiting current real -time system theory?
real-time

sschedulability
chedulability analysis (e.g., rate-monotnic theory)
rate-monotnic

performance analysis (queueing theory)
14
Performance of OO Technology
Hardware
Hardware is becoming ever faster ((Moores
Moores law)

previously unacceptable response times may now be
acceptable
OO
OO software technologies are becoming real -time aware
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:
void:offHook ();
busy : boolean {busy = true;
reqDialtone();
offHook()
};
Operations
Operations onHook ()
ring()
16
Conceptual Objects
Not
Not all objects necessarily require a physical
underpinning
For
For example, the telephone call object
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
In essence, an object is a server

generic object lifecycle:
Initialize
Initialize
Handling
Handling depends
depends Object
Object
on
on specific
specific request
request
type
type and
and object
object state
state
Wait
Waitfor
for
Invokes
Request
Request
Invokes
operations
operations on
on
other
other objects
objects void:offHook
void:offHook ();
(); Handle
{busy
{busy == true;
true;
Handle
obj.reqDialtone();
obj.reqDialtone();
Request
Request

};
};
Terminate
Terminate
Object
Object
18
Making Things Happen with Objects
Higher-level
Higher-level behavior emerges through the interactions
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
One of the main problems of many current OO
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
AA conflict between top -down and bottom

top-down -up design
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
More than one object can be constructed from the same
specification the class
specificationthe

A design environment concept
Objects
Objects created from some class specification are called
instances of that class

A run -time concept
run-time
Class
Class (Spec)
(Spec) Class
Class Instance
Instance
TelephoneClass Telephone1:TelephoneClass
busy : boolean
offHook()
Telephone2:TelephoneClass
onHook ()
ring()
21
Inheritance and Polymorphism
A generalization and re-use mechanism
GenericTelephone
busy : boolean Generalization

Generalization
(inheritance)
(inheritance)
offHook()
onHook () relationship
relationship
dialDigit()
TouchTone Polymorphism:
Polymorphism: RotaryDial
Telephone different
different realizations
realizations Telephone
busy : boolean of
of the
the same
same operation
operation busy : boolean
offHook() offHook()
onHook () onHook ()
dialDigit() dialDigit()
playTone()
22
Objects: Summary
The
The object paradigm is very well adapted to real -time
real-time
software systems because of its powerful structural
modeling capability

networks of collaborating objects
In
In addition, the object paradigm comes packaged with a
number of well -established techniques:
well-established

modularity

information hiding

generalization/refinement mechanisms (e.g., inheritance)

genericity
23

Real-Time

Real-Time

UML
Real-Time
The
Real-Time
Real-Time
Summary
24
The Unified Modeling Language
AA consolidation of proven ideas and practices based on

the object paradigm into a general -purpose OO modeling
general-purpose
language

Inititated by Rational Software ((Booch,
Booch, Rumbaugh, Jacobson)
Standardized
Standardized by the Object Management Group in 1997
Major
Major advantages:

widely adopted by software practitioners

widely taught in universities and technical seminars

supported by many software tool vendors
25
Evolution of UML
Planned major revision (2002) UML 2.0
Approved minor revision May 2001 UML 1.4
Current minor revision 1999 UML 1.3

Public
Feedback OMG Acceptance, Nov 1997
Final submission to OMG, Sept 1997 UML 1.1
First submission to OMG, Jan 1997
UML partners UML 1.0
Web - June 1996 UML 0.9
OOPSLA 95 Unified Method 0.8
Other methods OOSE Booch method OMT

Harel Statecharts
26
Components of UML
Basic
Basic set of (extensible) modeling concepts

used for modeling both problems and solutions (object, class,
association)

deep semantic roots
Formal
Formal rules of semantically meaningful composition
(well -formedness)
(well-formedness)
Graphical
Graphical notation for modeling concepts

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
UML uses a model-based approach rather than a view
model-based view--
based approach
View
View 22 View
View 22
w 33 w 33
i e
e w i e
e w
VVi VVi
View
View 11 View
View 11
Model-view consistency is enforced through the UML metamodel
29
UML Model Views
Requirements
Requirements (use case diagrams)
Static
Static structure (class diagrams)

kinds of objects and their relationships
Object
Object behavior (state machines)

possible life histories of an object
Inter-object
Inter-object behavior (activity, sequence, and
collaboration diagrams)

flow of control among objects to achieve system -level behavior
system-level
Physical
Physical implementation structures (component and
deployment diagrams)

software modules and deployment on physical nodes
30
Use Case Diagrams
Used
Used to capture functional requirements

useful as principal drivers of the overall development process
AircraftSimulator
AircraftSimulator
Use
Use case
case
Fail
Fail one
one
instructor
instructor engine
engine
actor
actor include
include
Prepare
Prepare flight
flight Run
Run checklist
checklist
trainee
trainee
Land
Land plane
plane
31
Use Cases and RT Systems
As
As useful as in any other domain

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.,
e.g., end-to-end delays,
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
Shows the entities in a system and their general
relationships
Association class Association class
designatedPlane
designatedPlane crew
crew
Airplane
Airplane Pilot
Pilot
11 1..*
1..*
0..*
0..*
Association
Association
Flight
Flight
route
route
start
start
duration
Captain
Captain First
First Officer
Officer
duration
0..*
0..*
owner
owner 0..*
0..* {ordered}
{ordered}
Airline
Airline 11
33
Object Instance Diagram
Shows
Shows object instances in a particular case
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
Class diagrams are very abstract and sometimes leave
out crucial system information (e.g., topology)

e.g., common class diagram for both systems
N2:Node
N2:Node
N1:Node
N1:Node N3:Node 0..2
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
Object (instance) diagrams do show topologies
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
Depict generic structural and behavioral patterns
Classifier
Classifier role
role
P2:TTSet
P2:TTSet
/CallProc
/CallProc
2.call()
2.call()
3.sendTone()
3.sendTone()
4.dialtone()
4.dialtone()
1.offHook()
P1:BusSet
P2:TTSet
/PhoneIF
P1:BusSet
/PhoneIF
P2:TTSet /ToneGen
/ToneGen
1.offHook()
NB:
NB: ItIt is
is possible
possible to
to have
have P1:BusSet
P1:BusSet
collaboration
collaboration diagrams
diagrams
without
without an an Interactions
Interactions
overlay
overlay (pure structure)
(pure structure)
37
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
Sequence diagrams are extremely useful for showing
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
Specifying constraints
master : Master d : DBaseServer cs : CommServer
read( )
register( )
{(register.receiveTime ( ) - read.sendTime( )) 2 ms}
40
Activity Diagrams
Different
Different focus compared to sequence diagrams
/Caller /Operator /Callee
activity
activity
Contact
Contact
Operator
Operator
Contact
Contact
swimlane
swimlane Callee
Callee
Respond
Respond
Notify
Notify
Parties
Parties
Acknowledge
Acknowledge Acknowledge
Acknowledge
41
Activity Diagrams and RT Systems
Better
Better than sequence diagrams for

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
well-suited -driven behavior
event-driven
42
State Machine Diagram
Each state corresponds to a selective receive action
Initial
Initial pseudostate
pseudostate State
State machine
machine
transition
transition
State
State
Initialize
Initialize
Object trigger
Object
created trigger
Wait
Waitfor
for
Event
Event start/^master.ready()
start/^master.ready()
Handle
Handle
Action
Action
Event ready expression
Event expression
stop/
stop/
Final
Final state
state
Terminate poll/^master.ack()
poll/^master.ack()
Terminate
Object
Object
43
Hierarchical States and Transitions
Allows step-wise refinement and viewing of complex
behavior
off/ group
group
OffLine transition
transition
default
default
transition
transition on/
OnLine
Ready done/
req/handle()
Busy composite
composite
state
state
44
State Machines and RT Systems
Many
Many real-time systems are event
real-time -driven
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
Periodic timers:

once initiated they repeatedly send TimeEvents at the
appropriate intervals until explicitly stopped or cancelled
In
In steady-state mode, active objects stimulated
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 Initialize
Initialize
Object
Object Object
Object
Wait
Waitfor
for Wait
Waitfor
for
Request
Request Request
Request
Handle
Handle Handle
Handle
Request
Request Request
Request
Terminate
Terminate Terminate
Terminate
Object
Object Object
Object
47
The Active Objects of UML
Single
Single thread of execution
Behavior
Behavior defined by state machines (event driven)
anActiveObject
#currentEvent : Eventpoll/defer
created
+ start ( )
start start/^master.ready() ready
+ poll ( )
+ stop ( )
ready
stop/
poll/^master.ack()
48
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
AA high priority event for another active object will preempt

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 mmayay
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 OSThreadN Lightweight
Lightweight
specialized
specialized
multitasking
multitasking
...
Active Active Heavyweight
Heavyweight
object object general
general--
scheduler scheduler purpose
purpose
multitasking
multitasking
Operating System
(schedules process and threads)
52
UML Concurrency Model and RT Systems
Active
Active objects are the major concurrency mechanism of
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
Scheduling approach undefined

Hints of event -based priorities (versus thread
event-based -based)
thread-based)

Timing events allow realization of time -triggered systems
time-triggered
The
The actual scheduling policy is unspecified

A semantic variation point

Can be customized to suit application requirements
54
The Model of Time in UML
Unbiased
Unbiased and uncommitted (i.e., it does not exist):

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
Related concepts:

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
Implementation focus Component
Component
:Scheduler
reservations
:Planner update Node

Node
Generally not sophisticated

:GUI
enough for complex real-time
system needs
56
Implementation Diagrams and RT Systems
Probably
Probably the weakest part of UML
Not
Not sophisticated enough to capture the various complex
aspects of deployment common to real -time systems
real-time

deferred mapping of software to hardware

mapping of software to software
No
No standard way to describe the quantitative
requirements/characteristics of hardware and software
(e.g., scheduling discipline)
..
..
57
UML Summary
An
An industry standard for analysis and design of object
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
Represented through 8 different diagram types

class, state machine, collaboration, use case, sequence,
activity, component, deployment
58
UML and RT Systems Summary
Using
Using UML for real -time systems automatically brings the
real-time
benefits of the object paradigm

structural focus, inheritance, strong encapsulation,
polymorphism,
However,
However, there are many open questions

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

Real-Time

UML
Real-Time
The
Real-Time
Real-Time
Summary
60
Semantic Variation in UML
Semantic
Semantic aspects that are:

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
The scope and semantic impact of semantic variation
choices must be strictly limited
61
Specialization of UML
Avoiding
Avoiding the PL/I syndrome (language bloat)

UML standard as a basis for a family of languages
Variations
Variations produced
produced
using
using built-in
built-in
UML Standard 1.4 extensibility
extensibility mechanisms:
mechanisms:
stereotypes,
stereotypes, tagged
tagged values,
values,
constraints
constraints
Real-Time UML
Real-Time UML for eCommerce ..etc.
62
How Do We Specialize UML?
Typically
Typically used to capture semantics that cannot be
specified using UML itself
Integer
Integer
But, how can we
specify a clock?
Counter
Counter Semantics:
ResetCounter ()
ResetCounter() an active counter whose
value changes
Specialization
Specialization synchronously with the
through
through regular
regular
inheritance
inheritance
progress of physical time
63
Stereotyping UML Concepts
Example:
Example: a clock stereotype based on the generic UML
Class concept
Semantics:
Semantics:
Integer
Integer 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
MyTimePiece
MyTimePiece
SetTime ()
SetTime()
64
UML Profiles
AA package of related specializations of general UML

concepts that capture domain -specific variations and
domain-specific
usage patterns
A domain-specific interpretation of UML
domain-specific
Fully
Fully conformant with the UML standard

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
The extensibility mechanisms of UML provide an
excellent opportunity to fill in the missing bits for real -time
real-time
applications
If
If we can define a standard set of extensions (real -time
(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
Bridges two domains: modeling and real -time
real-time
Analysis & Design

Real-Time SIG
PTF
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
Three principal areas of investigation:

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
real-time -03-13)
(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
The RFP does not ask for new real -time concepts or
real-time
methods
Instead,
Instead, the intent is to support existing and future
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
Require uncommon and highly -specialized skills
highly-specialized
Software
Software is notoriously difficult to model

highly non -linear (detail often matters)
non-linear

models are frequently severely inaccurate and not trustworthy

typical modeling process is highly manual:
System analysis
analysis
Model results
results
+
-
Actual
measurements
measurements
System
74
Desired Development Model
Seamless
Seamless integration of technologies and tools based on
standards for real -time modeling
real-time
Automated
Automated
model
model conversion
conversion
Model Editing
Tool Model Analysis
44
Tool
3.1
3.1
55
Inverse
Inverse
model
model conversion
conversion
75
Structure: Domain Model and Extensions
General Resource Model profile

RTresourceModeling
Client
Resource
etc.
import
profile
import
ADprofile
metaclass metaclass
Specialized Analysis Domain Model Class Object
Analysis
Client stereotype
Analysis stereotype
etc. Resource ADresource
etc.
Domain model Profile Packages (normative)

76
UML Real-Time Profile Structure
General Resource Modeling Framework
profile
RTresourceModeling
import import
profile profile
RTconcurrencyModeling RTtimeModeling
import import
import
Analysis Models Infrastructure Models
profile profile modelLibrary

SAProfile PAprofile RealTimeCORBAModel
import
profile
RSAprofile
77
Quality of Service Concepts
Quality
Quality of Service (QoS):
a specification (usually quantitative) of how a particular servi ce
service
is (to be) performed

e.g. throughput, capacity, response time
The
The specification of a model element can include:

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
These capacities are expressed through QoS attributes
of the service or resource
Resource
Resource Usage
S1
Usage
S1
Client S1
S1 Resource
RequiredQoS
RequiredQoS OfferedQoS
OfferedQoS
{RequiredQoS OfferedQoS}
{RequiredQoS 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
withh
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 StaticUsageModel
(from ResourceUsageModel) (from ResourceUs ageModel)
Resourc eManagement
CausalityModel ResourceTypes
CoreResourceModel
82
Core Resource Model
+type
Inst ance Descriptor
0..n 1..n
ResourceInstance +inst ance +type Resource

0..n 0..n
0..n 1..n
1..n +offeredService 1..n

ResourceServiceInst ance +instance +t ype ResourceService
0..n 1
0.. n 0..n
/ /
0..n +offeredQoS 0..n
QoSvalue QoScharacterist ic
+instance +type
0..n 1
0..n +offeredQoS 0..n
NB:
NB: This is a model of the domain concepts

(i.e., it is not a UML metamodel)
83
Basic Resource Usage Model
EventOccurence
(f rom Cau sali ty Mo del )
AnalysisContext
1 0..n
1
1..n
1..n 1..n +usedResourc es
0..1 1 ResourceInstance
UsageDemand ResourceUsage 0..n 1..n (from CoreResourceModel)
+workload
1..n
+us edServices
ResourceServiceInstance
0..n (from CoreResourceModel)
StaticUsage DynamicUsage
84
Basic Causality Loop
Used
Used in modeling dynamic scenarios
EventOccurence
+cause +effect
Stimulus
StimulusGeneration
1 1..n
+receiver
Instance
(from CoreResourceModel) 0..1 0..n
+effect 0..n 1 +cause
1..n +executionHost
+cause 1 0..n +methodExecution

Scenario
+cause +effect
StimulusReception
1 0..n
+effect
0..1
85
Dynamic Usage Model
DynamicUsage
(from ResourceUsageModel)
+usedResources
Scenario ResourceInstance
1..n / 1..n (from CoreResourceModel)
(from Caus ality Model)
1..n
{ordered}
+step /
1..n
1.. n
+successor ActionExecution +usedServices
ResourceServiceInstance
0..n 1..n (from CoreResourceModel)
0..n
+predecessor 0..n 0.. n
0..n
0..n +requiredQoS +offeredQoS
QoSvalue
(from CoreResourceModel)
86
Static Usage Model
StaticUsage Instance
(from ResourceUsageModel) (from CoreReso urceMode l)
+usedResources ResourceInstance
Client
1..n 1..n (from CoreResourceModel)
0..n 0..n
+requiredQoS 1..n
QoSvalue +offeredQoS /
0..n
+instance 0..n
+type 1
QoScharacteristic
87
Resource Categorizations
ResourceInstance
protectionKind activenes sKind
ProtectedResource UnprotectedResource PassiveResource ActiveResource
purposeKind
Device Processor CommunicationResource
88
Exclusive Use Resources and Actions
ResourceServiceInstance ActionExecution
(from CoreResourceModel) (from DynamicUsageModel)
1
Acces sControlPolicy
0..n
0..1
ExclusiveService AcquireService
/ / Releas eService
isBlocking : Boolean
1 0..n
0..n 1..n 0..n
ProtectedResource /
/
1
89
Resource Management Model
Instance
ResourceBroker ResourceManager
1 0..n 0..n 0..n

1
ResourceControlPolicy
1..n 1..n 1..n +managedResource

AccessControlPolicy Res ourceInst ance
(from ResourceTypes) (from CoreResourceModel)
90
Mapping to UML Extensions
Elements
Elements of the general resource model are represented
as stereotypes (with tags) of base UML concepts:
GRMresource
GRMresource
Resource
Resource BufferPool
BufferPool
Service 0..n
0..n
GRMresSrvc () {GRMexTime
GRMresSrvc GetBuffer()
GetBuffer
GetBuffer() {GRMexTime == 5}
5}
Stereotype UML base concepts Tags
Classifier,
GRMresource N/A
Instance
GRMresSrvc BehavioralFeature GRMexTime
GRMresource
GRMresource
aPool
aPool :: BufferPool
BufferPool
91
Example System
Periodic
Periodic concurrent tasks sharing resources
WCET
WCET == 22 ms
ms
Period
Period == 100
100 ms
ms
WCET = 20
WCET = 20 msms
1. read( )
master : Master
d : DBaseServer
Period
Period == 150
150 ms
ms
WCET
WCET == 4040 ms
ms 2. register( )
WCET
WCET == 20
20 ms
ms
dBadmin : Admin
sort( )
Period WCET
WCET == 10
10 ms
ms
Period == 350
350 ms
ms
WCET = 100
WCET = 100 ms ms
poller : Poller
invoke( )
cs : CommServer
WCET
WCET == 10
10 ms
ms
92
Standard Stereotypes
To
To allow an analysis tool to extract the necessary QoS
information, we define a set of standard stereotypes and
related tags*
Tags
Stereotype UML base concepts
Classifier, GRMperiod,
GRMclient
Instance GRMwcet
Classifier, N/A
GRMprotResource
Instance
GRMresService BehavioralFeature GRMwcet
Tag Tag Type
GRMperiod RTtimeString
GRMwcet RTtimeString
** The
The stereotypes
stereotypes and
and tags
tags have
have been
been simplified
simplified for
for this
this present ation
presentation
93
Example: QoS Annotations
Using
Using the standard stereotypes...
GRMclient 1. read( )
master : Master GRMprotResource
{GRMperiod = 100 ms} d : DBaseServer
{GRMwcet = 20 ms}
2. register( )
GRMclient
dBadmin : Admin
{GRMperiod = 150 ms}
sort( )
{GRMwcet = 40 ms}
GRMclient
poller : Poller
invoke( ) GRMprotResource
{GRMperiod = 350 ms}
cs : CommServer
{GRMwcet = 100 ms}
94
Example: Class Diagram
QoS
QoS annotations can be added to classes as well
GRMclient GRMprotResource GRMclient

Master DBaseServer Admin
0..n 1 1
GRMservread () {GRMwcet = 10ms} 0..n
GRMservsort () {GRMwcet = 20ms}
0..n
GRMprotResource
CommServer GRMclient
1 Poller
1 GRMserv invoke() {GRMwcet = 10ms} 0..n
GRMserv register() {GRMwcet = 20ms}
95
Example: Model Analysis
Result:
Result:
aa new
new model
model with
with
analysis
analysis variable
variable
values
values set
set
GRManalysisContext
GRManalysisContext GRManalysisContext
GRManalysisContext
{isSchedulable= .$?} {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 Clock
Time
(from TimingMechanisms)
1 +referen ceClock
{ordered} n 0..n
n +measurement TimeValue
PhysicalInstant
kind : {discrete, dense}
0..n
+start 1 1 +end 1 +s tart 1 +end
n n n n
Duration +measurement Tim eIn terval
0..n 0..n
98
Timing Mechanisms Model
ResourceInstance
+currentValue 0..n
TimeValue TimingMec hanism
(from TimeModel) 1 stability +origin TimedEvent
+max imalValue 0..n drift (from TimedEvents)
skew 1
1
set(time : TimeValue)
0..n
get() : TimeValue
reset()
start()
0..n pause()
1 +resolution
TimeInterval
(from Tim eModel)
1 +offset
1 +times tam p
+accuracy 1..n
1 +referenceClock
0..n
+duration TimeValue
Clock Timer (from Tim eModel)
isPeriodic : Boolean 0..n 1
0..n 1 1
+generatedInt errupts 0..n +generatedTimeouts 0..n

ClockInterrupt Timeout
(from TimedEvents) (from TimedEvents)
99
Example Timing Stereotype
Stereotype Base Class Tags
RTaction Action RTstart
ActionExecution RTend
RTduration
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 +effect Stimulus

(from CausalityModel) (from CausalityModel)
1 1.. n
+c ause 1 +cause 1 +time 0..n
0..n +start TimeValue

TimedStimulus
1.. n (from TimeModel)
+end
0..n 0..n
Timeout
1..n
/ ClockInterrupt
These two associations are 0..n

derived from the general
association between
EventOccurrence and Stimulus
101
Timed Events and Timed Actions
EventOccurence Scenario
(from CausalityModel) (from CausalityModel)
TimedAction
TimedEvent
0..n
Delay
1..n +start 1..n +end 1..n +duration 1
+timestamp
TimeInterval
TimeValue
(from TimeModel)
(from TimeModel)
102
Time Annotations
In
In various behavioral diagrams (sequence, activity, state)
PAclosedLoad PAcontext
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow
processSelection
PAstep
initialPlayout
More compact forms are also
initializePlayer {PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
PAstep
confirm
PAstep
{PAdemand=
sendFrame
possible:
{PArespTime= ('est','mean',1,'ms')}}
('req','percentile',95,500,'ms')}}
showFrame
InstanceA : InstanceB :
PAstep
{PArep=$N, *[$N]
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)} terminalPlayout
helloMsg
PAstep {0 ms}
{PAinterval= {1.5 ms}
{2 ms}
May be very sophisticated and express complex

2.7 ms
time values (instants and durations) including

{4.7 ms}
ackMsg
probability distributions, percentile values, etc. {10.2 ms}
{11 ms}
(NB: tools can help reduce visual clutter)
103
Notation: Timing Marks and Constraints
AA timing mark identifies the time of an event occurrence

On messages: Caller
call
Operator call.receiveTime()
sendTime()
receiveTime() callHandler.startTime()
ack
On action blocks (new):
callHandler.endTime()
startTime() ack.sendTime()
endTime()
{call.sendTime() - ack.receiveTime < 10 sec}
Timing constraint
104
Defined Stereotypes (1 of 3)
Stereotype Applies To Tags Description
RTaction Action, ActionExecution, RTstart [0..1] An action that takes time

Stimulus, Action, RTend [0..1]
Message, Method RTduration [0..1]
RTclkInterrupt Stimulus, Message RTtimestamp [0..1] A clock interrupt
(subclass of
RTstimulus)
RTclock (subclass of Instance, DataType, RTclockId [0..1] A clock mechanism
RTtimingMechanism) Classifier,
ClassifierRole
RTdelay Action, ActionExecution, RTduration [0..1] A pure delay activity
Stimulus, Action,
Message, Method
RTevent Action, ActionExecution, RTat [0..1] An event that occurs at a
Stimulus, Action, known time instant
Message, Method
RTinterval Instance, Object, RTintStart [0..1] A time interval
Classifier, DataType, RTintEnd [0..1]
DataValue RTintDuration [0..1]
105
RTnewClock Operation RTstart [0..1] An operation that creates a

RTend [0..1] new clock mechanism
RTduration [0..1]
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 RTtimePar [0..1] An operation that sets the
current value of a timing
mechanism
RTstart Operation An operation that starts a
timing mechanism
RTstimulus Stimulus, ActionExecution, RTstart [0..1] A timed stimulus
Action, ActionSequence, RTend [0..1]
Method
106
RTtime DataValue, Instance, Object, RTkind [0..1] A time value or a time

DataType, Classifier RTrefClk [0..1] object
RTtimeout (subclass Stimulus, ActionExecution, RTtimestamp [0..1] A timeout signal or a
of RTstimulus) Action, ActionSequence, timeout action
Method
RTtimer (subclass of DataValue, Instance, Object, RTduration [0..1] A timer mechanism
RTtimingMechanism) ClassifierRole, Classifier RTperiodic [0..1]
RTtimeService Instance, Object, A time service
ClassifierRole, Classifier
RTtimingMechanism DataValue, Instance, RTstability [0..1] A timing mechanism
Object,ClassifierRole, RTdrift [0..1]
RTskew [0..1]
Classifier, DataType
RTmaxValue [0..1]
RTorigin [0..1]
RTresolution [0..1]
RTaccuracy [0..1]
RTcurrentVal [0..1]
RToffset [0..1]
RTrefClk [0..1]
107
Specifying Time Values
Time
Time values can be represented by a special stereotype
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 P=0.3
0 ms 1 ms 2 ms 3 ms
108
Specifying Arrival Patterns
Method
Method for specifying standard arrival pattern values

Bounded: bounded, <min -interval>, <max
<min-interval>, -interval>
<max-interval>

Bursty
Bursty:: bursty,
bursty, <burst-interval> <max.no.events>
<burst-interval>

Irregular: irregular, <interarrival -time>, [<interarrival
<interarrival-time>, -time>]*
[<interarrival-time>]*

Periodic: periodic, <period> [, <max -deviation>]
<max-deviation>]

Unbounded: unbounded, <probability -distribution>
<probability-distribution>
Probability
Probability distributions supported:

Bernoulli, Binomial, Exponential, Gamma, Geometric,
Histogram, Normal, Poisson, Uniform
109
General Concurrency Modeling
ActiveResource
/ (from ResourceTypes)
1.. n
Res ourceServiceInst ance ConcurrentUnit

(from CoreResourceModel) 1
1
/ /
ProtectedResource
(from ResourceTypes)
+methodE xecution 0..n 1 +main 1..n
DeferredService Immediat eServic e Scenario StimuliQueue

threading (from CausalityModel)
0...
+step 1..n 0...

ActionExecution Stimulus
(from DynamicUsageModel) (from CausalityModel)
isAtomic : Boolean
+cause / +effect StimulusGeneration

MessageAction
1 1.. n (from CausalityModel)
SynchronousInvoke Asy nchronousInvoke
110
Defined Stereotypes
CRAction Action, ActionExecution, CRAtomic [0..1] An action execution

Stimulus, Action,
Message, Method
CRAsynch Action, ActionExecution An asynchronous invocation
CRConcurrent Node, Component, CRMain [0..1] A concurrent unit concept

Artifact, Class, Instance
CRContains Usage A generalized usage
dependency
CRDeferred Operation, Reception, A deferred receive
Message, Stimulus
CRImmediate Operation, Reception, {remote, local} [0..1] An instance of an immediate
Message, Stimulus service
CRmsgQ Instance, Object, Class, A stimuli queue
ClassifierRole
CRSynch Action, ActionExecution A synchronous invoke
111
Performance Analysis Concepts
PerformanceContext
1 0.. n
1
1..n
1..n
1..n
W orkload +resource PResource
PScenario
responseTime 1..n 0..n 0..n utilization
priority 1 hostExecutionDemand
responseTime schedulingPolicy
0..n throughput
1
<<deploys>>
{ordered}
ClosedWorkload OpenWorkload +root 1 1..n +host 0..1
population oc currencePat tern PStep PProcessingResource PPassiveResource
externalDelay
probabilty processingRate waitingTime
+successor repetition contextSwitchTime responseTime
delay priorityRange capacity
0..n operations isPreemptible accessTime
interval
executionTime
+predecessor 0..n
112
Relationship to General Resource Model
UsageDemand AnalysisContext Scenario
(from ResourceUsageModel) (from ResourceUsageModel) (from CausalityModel)
Workload PerformanceCont ext PScenario
PassiveResource ProtectedResource Act iveResource

(from ResourceTypes) (from ResourceTypes) (from ResourceTypes)
PPassiveResource PProcessingResource
waitingTime processingRate
responseTime contextSwitchTime
capacity priorityRange
accessTime isPreemptible
113
Example: Web Video Application
Engineering Instance Model
vp : VideoPlayer vw : VideoWindow b : Browser ws : WebServer vs : VideoServer
GRMdeploys GRMdeploys GRMdeploys
Logical Instance Model

:ClientWorkstation : WebServerNode : VideoServerNode
vw : VideoWindow b : Browser
: Internet
vp : VideoPlayer ws : WebServer
Usage Scenario
vs : VideoServer 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
PAclosedLoad PAcontext
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
processSelection
PAstep
initialPlayout {PAdemand=
initializePlayer
(('est','mean',15,'ms'),
confirm
PAstep
PAstep {PAdemand=
{PArespTime= sendFrame
('est','mean',1,'ms')}}
showFrame
PAstep
{PArep=$N, *[$N]
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)} terminalPlayout
PAstep
{PAinterval=
116
Example: More Annotations
PAcontext
vp : VideoPlayer vw : VideoWindow b : Browser ws : W ebServer vs : VideoServer
{PAschdPolicy=PR,
PArate=1, PAhost PAhost PAhost
PAutilization=$Util, :ClientWorkstation : WebServerNode : VideoServerNode
PActxtSwT=('est','mean',40,'us')}
PAcontext
vs : VideoServer vp : VideoPlayer vw : VideoW indow
: Internet
PAstep
{PAdemand=('est','mean',10,'ms'),
send PAextOp=('filesys',12),('network',65)}
frame
PAstep {PAdemand=
receive (('est','mean',15,'ms'),
frame
PAstep
{PAinterval=
('req','percentile',99,30,'ms')}} show
frame
117
PAclosedLoad Action, ActionExecution, PArespTime [0..*] A closed workload

Stimulus, Action, PApriority [0..1]
Message, Method PApopulation [0..1]
PAextDelay [0..1]
PAcontext Collaboration, A performance analysis
CollaborationInstanceSet, context
ActivityGraph
PAhost Classifier, Node, PAutilization [0..*] A deferred receive
ClassifierRole, Instance, PAschdPolicy [0..1]
Partition PArate [0..1]
PActxtSwT [0..1]
PAprioRange [0..1]
PApreemptible [0..1]
PAthroughput [0..1]
PAopenLoad Action, ActionExecution, PArespTime [0..*] An open workload
Stimulus, Action, PApriority [0..1]
Message, Method PAoccurrence [0..1]
118
PAresource Classifier, Node, PAutilization [0..*] A passive resource

ClassifierRole, Instance, PAschdPolicy [0..1]
Partition PAcapacity [0..1]
PAmaxTime [0..1]
PArespTime [0..1]
PAwaitTime [0..1]
PAthroughput [0..1]
PAstep Message, ActionState, PAdemand [0..1] A step in a scenario
Stimulus, SubactivityState PArespTime [0..1]
PAprob [0..1]
PArep [0..1]
PAdelay [0..1]
PAextOp [0..1]
PAinterval [0..1]
119
Specifying Performance Values
AA complex structured string with the following format

<kind-of-value> , <modifier> , <time
<kind-of-value> -value>
<time-value>
Where:
Where:

<kind -of-value> ::= req
<kind-of-value> req | assm
assm | pred
pred | msr
msr

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
Worst-case Completion Time 0..n
0..n
Delay Time
+precedents Preempted Time 0..n 1..n
Ready Time +usedResources SResource +ownedResource s ExecutionEngine
0..n
Release Time Capacity Priority Range
/
Blocking Time 0..n 0..n Acquisition Time
0..n 0..1 Processing Rate
Laxity Deacquisition Time Context Switch Time
Absolute Deadline isConsumable Utilization
Relative Deadline Priority Ceiling isPreemptible
isAtomic isPreemptible isSchedulable
0..n +host 1 0 ..n 1
<<deploys>> +host Schedulabl eR esource <<deploys>>

R espo nse
1 0..n 1
Utilization
Sche dulingPolicy 0..n 1..n
Spare Capacity
Overlaps SchedulingJob
Slack Time
+effect 1 1 1
/
+cause 1
Trigger
isSchedulable
0..n 1 1
121
Policies Supported
Scheduling
Scheduling Policies:

Rate Monotonic, Deadline Monotonic, HKL, Fixed Priority,
Minimum Laxity First, Maximize Accrued Utility, Minimum
Slack Time

may be extended in the future
Access
Access Control Policies:

FIFO, Priority Inheritance, No Preemption, Highest Lockers,
Priority Ceiling

may be extended in the future
122
Example
AA simple telemetry system with 3 cyclical tasks

A.1.1:main ( )
Sensors A.1:gatherData ( )
TelemetryGatherer TGClock : Clock
:SensorInterface
:DataGatherer
TGClock : Clock
A.1.1.1: writeStorage ( )
SensorData
C.1:displayData ( ) :RawDataStorage
B.1.1 : main ( )
C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( )
TelemetryDisplayer TelemetryProcessor
: DataDisplayer :DataProcessor
C.1.1 : main ( ) Display

:DisplayInterface B.1:filterData ( )
TGClock : Clock
123
Example: Schedulability Annotations
SAAction
SASituation {SAPriority=2,
A.1.1:main ( )
SAWorstCase=(93,'ms'), SATrigger
RTduration=(33.5,'ms')} {SASchedulable=$R1, Result
Result
RTat=('periodic',100,'ms')}
A.1:gatherData ( )
SAResponse
Sensors {SAAbsDeadline=(100,'ms')}
:SensorInterface
:DataGatherer
SASchedulable
TGClock : Clock SAAction

A.1.1.1: writeStorage ( )
{RTstart=(16.5,'ms'),
RTend=(33.5,'ms')}
SAResource
SATrigger
{SASchedulable=$R2, SensorData
{SACapacity=1,
RTat=('periodic',60,'ms')}
C.1:displayData ( ) :RawDataStorage
SAAccessControl=PriorityInheritance}
SAResponse
SAResponse
{SAPriority=3,
{SAAbsDeadline=(60,'ms')} B.1.1 : main ( )
SAWorstCase=(177,'ms'),
RTduration=(46.5,'ms')}
SAAction SAAction
{RTstart=(3,'ms'), {RTstart=(10,'ms'),
RTend=(5,'ms')} RTend=(31.5,'ms')}
: DataDisplayer
SASchedulable :DataProcessor
SASchedulable
Display SATrigger
{SASchedulable=$R3,
SAResponse :DisplayInterface RTat=('periodic',200,'ms')}
B.1:filterData ( )
{SAPriority=1, SAResponse
C.1.1 : main ( )
SAWorstCase=(50.5,'ms'), {SAAbsDeadline=(200,'ms')}
TGClock : Clock
124
Example: Deployment Specification
SASchedulable SASchedulable SASchedulable

TelemetryDisplayer TelemetryGatherer TelemetryProcessor
: DataDisplayer :DataGatherer :DataProcessor
GRMdeploys
SAEngine
SAOwns SAResource
{SARate=1,
SASchedulingPolicy=FixedPriority} SensorData
:Ix86Processor :RawDataStorage
125
Example: Analysis Results
SASituation
SAAction
{SAPriority=2,
SAWorstCase=(93,'ms'), SATrigger
RTduration=(33.5,'ms')} {SASchedulable=$true,
Additional
Additional A.1.1:main ( ) RTat=('periodic',100,'ms')}
SAResponse
tool-specific
tool-specific {SAAbsDeadline=(100,'ms')}
A.1:gatherData ( )
results
results encased
encased Sensors
SASchedulable
in
in UML
UML Notes
Notes :SensorInterface
:DataGatherer
SAAction
{RTstart=(16.5,'ms'),
RTend=(33.5,'ms')}
TGClock : Clock A.1.1.1: writeStorage ( )
SATrigger SAResource
{SASchedulable=$true {SACapacity=1,
RTat=('periodic',60,'ms')} SAAccessControl=PriorityInheritance}
SAResponse
SAResponse SensorData {SAPriority=3,
{SAAbsDeadline=(60,'ms')}
C.1:displayData ( ) :RawDataStorage SAWorstCase=(177,'ms'),
B.1.1 : main ( )
SAAction SAAction
{RTstart=(3,'ms'), {RTstart=(10,'ms'),
RTend=(5,'ms')} RTend=(31.5,'ms')}
SASchedulable SASchedulable
: DataDisplayer :DataProcessor
SATrigger
{SASchedulable=$true
SAResponse RTat=('periodic',200,'ms')}
{SAPriority=1, Display SAResponse
SAWorstCase=(50.5,'ms'), :DisplayInterface {SAAbsDeadline=(200,'ms')}
RTduration=(12.5,'ms')} B.1:filterData ( )
C.1.1 : main ( )
TGClock : Clock
126
SAAction Action, ActionExecution, SAPriority [0..1] An action

(subclass of RTaction Stimulus, Action, SAActualPty [0..1]
SABlocking [0..1] SAReady
and CRAction) Message, Method
[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]
SAEngine Node, Instance, Object, SASchedulingPolicy [0..1] An execution engine
Classifier, ClassifierRole SAAccessPolicy [0..1]
SARate [0..1]
SAContextSwitch [0..1]
SAPriorityRange [0..1]
SAPreemptible [0..1]
SAUtilization [0..1]
SASchedulable [0..1]
Saresources [0..1]
127
SAOwns Abstraction Identifies ownership of

(subclass of resources
GRMrealize)
SAPrecedes Usage A precedence relationship
between actions and triggers
SAResource Classifier, ClassifierRole, SAAccessControl [0..1] A resource of some kind
Instance, Object, Node SAConsumable [0..1]
SACapacity [0..1]
SAAcquisition [0..1]
SADeacquisition [0..1]
SAPtyCeiling [0..1]
SAPreemptible [0..1]
SAResponse (subclass Action, ActionExecution, SAUtilization [0..1] A response to a stimulus or
of SAAction) Stimulus, Action, SASpare [0..1] action
Message, Method SASlack [0..1]
SAOverlaps [0..1]
SASchedulable Classifier, ClassifierRole, A schedulable resource
(subclass of Instance, Object, Node
SAResource)
128
SAScheduler Classifier, ClassifierRole, SASchedulingPolicy [0..1] A scheduler

Instance, Object SAExecutionEngine [0..1]
SAPrecedes Usage A precedence
relationship between
actions and triggers
SASituation Collaboration, A schedulability analysis
CollaborationInstance, context
ActivityGraph
SATrigger (subclass of Message, Stimulus SASchedulable [0..1] A trigger
SAAction) SASAprecedents [0..1]
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 )
0.. n +usedResources +ownedResources

Response RTCmutex
(from SchedulingDomanModel) / 0..n
0.. n
+usedResources RTCserver
0..n 0.. n
serverPriority
/ 1..n
1
0..n +usedResources RTCconnection
/ isShared 0..n
1..n
hiPriority
0..n +clientScenario
loPriority /
/
SchedulableResourc e ExecutionEngine <<deploys>>

(from SchedulingDomanModel) (from SchedulingDomanModel)
1
RTCclient
timeout 1..n / +host
+hos t RTCorb
clientPriority
1
private <<deploys>> 1
130
Example: RT CORBA
SASituation
RSAserver
RTclock {SACapacity=10}
TGClock : Clock Sensor2
:SensorInterface
RSAclient
RSAserver
{RSAtimeout=(105,'ms),
{SACapacity=4}
RSAclPrio=12
Sensor1
TelemetryGatherer GRMdeploys
:SensorInterface
: DataGatherer
GRMdeploys GRMdeploys
GRMdeploys
RSAorb RSAorb RSAorb

{SASchedulingPolicy= {SASchedulingPolicy= {SASchedulingPolicy=
'RateMonotonic'} 'RateMonotonic'} 'RateMonotonic'}
TG-ORB: RTOrb S1-ORB: RTOrb S2-ORB: RTOrb
SAEngine SAEngine
{SASchedulingPolicy= {SASchedulingPolicy=
'RateMonotonic', 'RateMonotonic',
SARate=1} SARate=0.5}
P1 : I586 P2 : Ix86
131
Example: RT CORBA Usage Scenario
SASituation
RSAclient RSAserver RSAserver

RTclock
TelemetryGatherer Sensor1 Sensor2
TGClock
: DataGatherer :SensorInterface :SensorInterface
RTevent {RTat=('periodic', 100, 'ms')}

tick ( )
SAAction
{SAW orstCase=(15,'ms'),
RTduration=(10,'ms')}
SAresponse
readSensor ( )
{SAAbsDeadline
=(100,'ms')
SAAction
readSensor ( )
SAAction
compare ( )
132
Defined Stereotypes
RSAclient Classifier, ClassifierRole, RSAtimeout [0..1] An RT CORBA client

(subclass of Instance, Object, Node RSAclPrio [0..1]
SASchedulable) RSAprivate [0..1]
RSAhost [0..1]
RSAconnection Classifier, ClassifierRole, SAAccessControl [0..1] An RT CORBA
(subclass of Instance, Object, Node RSAshared [0..1] connection
SASchedulable and RSAhiPrio [0..1]
SAResource) RSAloPrio [0..1]
RSAserver [0..1]
RSAmutex Classifier, ClassifierRole, SAAccessControl [0..1] An RT CORBA mutex
(subclass of Instance, Object, Node RSAhost [0..1]
SAResource)
RSAorb Classifier, ClassifierRole, SAschedulingPolicy [0..1] An RT CORBA ORB
(subclass of Instance, Object, Node
SAResource )
RSAserver Classifier, ClassifierRole, RSAsrvPrio [0..1] An RT CORBA server
(subclass of Instance, Object, Node SACapacity [0..1]
SAResource )
133
Real Time CORBA: Infrastructure Model
<<CORBAModule>> <<CORBAModule> > <<CORBAModule>>

CORBA IOP PortableServer
<<CORBAModule>>
<<CORBAModule>> RTPortableServer
RTCORBA
<<CORBAModule>>
RTCosScheduling
134
Model Processing Paradigm and Tools
Configuration
Data Set
Model Processor
3 4 5
Configured
Model Model Domain
UML Model
Configurer Convertor Model
(XMI)
2 6
Parametrized Processing
Model
UML Model Control
(XMI) Analyzer Specification
1 7
10 9 8
Results
Model UML Model
Results Processing
Editor Convertor Results
(XMI)
135
The Tag Value Language
Tagged
Tagged value format:
{<tag-name> = <tag
{<tag-name> -value>}
<tag-value>}
Used
Used to specify complex (structured) tagged values
Based
Based on a small proper subset of the freeware Perl
language

Includes: variables, numbers, booleans
booleans,, strings, lists,
expressions (including conditionals), operators, and functions
Suitable
Suitable for:

expressing complex dependencies between values

writing processing scripts
136
Summary: The Real Time UML Profile
The
The RT UML Profile defines a set of extensions for
directly expressing real -time domain concepts in UML:
real-time

resources

concurrency mechanisms

time and timing mechanisms
Furthermore,
Furthermore, it allows the specification of quantitative
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

Real-Time

UML
Real-Time
The
Real-Time
Real-Time
Summary
138
Common Wisdom...
When
When designing software, we are instructed to ignore
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,
But, what about real-time systems?
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
Possibility of out -of-date state information due to lengthy
out-of-date
(and variable) transmission delays
Node1 (New York) Node2 (Tokyo)
observer
on off
on
on
State?
State?
on
on
Its
Its aa game
game of
of numbers!
numbers!
141
Real System Design Issues (2)
Inconsistent
Inconsistent views of system state:

different observers see different event orderings
clientA
clientA notifier1
notifier1 notifier2
notifier2 clientB
clientB
e2
e2
e1
e1
e1
e1
e2
e2
time
Its
Its aa game
game of
of numbers!
numbers!
142
Distributed System Characteristics
Key
Key characteristics:

concurrency and asynchrony

need for communication and synchronization between sites

communication delays

possibility of partial failure
Each
Each of these adds significant weight to the
programming problem
Distributed
Distributed programming is different from and much more
complex than conventional programming
143
Real-World Real-Time Design Issues
Much
Much of the complexity associated with these systems is
the result of the intrusion of the inherently complex
physical world into the idealized logical world of software
The
The real -time design dilemma:
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
AA technology -independent view of the software

technology-independent

a virtual mechanism realized by a computer
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES
145
Engineering (Realization) Viewpoint
The
The realization of a specific set of logical components
using facilities of the run -time environment
run-time
Processor
OS
OS process
process
Processor
stack
Ethernet LAN
OS
OS process
process TCP/IP
TCP/IP socket
socket
stack
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 PILOT
CONTROL
SURFACES PILOT
GROUND CONTROLS
MODEL
MODEL
ENGINES
ENGINES
Realization
Realization
mappings
mappings
Engineering
Engineering View
View
Processor
OS
OSprocess
process
Processor
Ethernet LAN stack
OS
OSprocess
process TCP/IP
TCP/IPsocket
socket
stack TCP/IP
TCP/IPsocket
socket
OS
OSprocess
process
stack
147
Realization Mappings
AA correspondence between elements of two distinct

models (logical and engineering)
Semantics:
Semantics: the logical elements are implemented by the
corresponding engineering model elements

logical elements can be viewed as residing on the
corresponding engineering elements
AIRFRAME
AIRFRAME OS
OS process1
process1
Processor
CONTROL OS
CONTROL OS process1
process1
SURFACES
SURFACES
Model
Model 11 Model
Model 22 Model
Model 33
148
Selecting a Level of Abstraction
Intermediate
Intermediate levels may be abstracted out

depends on the desired granularity of modeling

affects the semantics of the realization relationship
AIRFRAME
AIRFRAME OS
OS process1
process1
Processor
CONTROL OS
CONTROL OS process1
process1
SURFACES
SURFACES
Model
Model 11 Model
Model 22 Model
Model 33
AIRFRAME
AIRFRAME
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 client
client
Mem : CPU : Bandw.

Bandw. :
2MB 3 MIPs 70Mbit/s required
required QoS
QoS values
values
resource
resource usage
usage
20MB 3MIPs 100Mbit/s environment

environment services
services
(offered
(offered QoS
QoS values)
values)
CPU
CPU LAN
LAN
resources
resources
The
The same QoS framework can be used for quantifying
realization relationships
151
Two Interpretations of Resource Model
The
The peer interpretation
accesses
accesses
client
client resource
resource
The
The layered interpretation (the 22-viewpoint
-viewpoint model)
Logical
Logical View
View
realize
realize
Engineering
Engineering View
View
WinNT
WinNT WinNT
WinNT
Process
Process Process
Process
152
Example: Realization Relationships
For
For sophisticated multi -layer deployment modeling
multi-layer
TSensor: TemperatueSensor instPanel: Register injector: FIControl

{cycle = 20 msec} {cycle = 40 msec} {cycle = 20 msec}
GRMdeploys
temp : Temperature
GRMdeploys
GRMdeploys
LWT
GRMdeploys OSprocess Thread1 : T
HostProcess: P {ctxtSw = 10usec}
LWT
{ctxtSw = 80usec;
Thread2 : T
heap = 30 kB}
{ctxtSw = 10usec}
LWT
Thread3 : T
{ctxtSw = 10usec}
153
Forms of Realization
154
Modeling Realization in UML
An
An association between models with explicit realization
mappings between model elements
Logical
Logical Model
Model Engineering
Engineering Model
Model
GRMrealizes X Y
asc GRMrealizes
A
B Z
Source element Dest. elements

A X, Y
asc Y AA stereotype
stereotype of
of the
the
B Z UML
UML realizes
realizes relationship
relationship
Compact
Compact tabular
tabular form
form
deployment table
155
Specifying Realization Mappings
Captures
Captures the specifics of the realization mapping

Either as a string (tag value) or as a table
Logical Engineering Mode Linkage Additional
Elements Elements Constraints
<List of logical <List of <If there are multiple <Interaction mode <Any additional
model corresponding engineering elements, between levels, one constraints that
elements> engineering one of:> of:> apply to the
model elements> {inclusive, {sync, mapping>
exclusiveStatic, async,
exclusiveDynamic} replace}
L1 L
sync = SW to SW
async = SW to SW
replace = SW to HW
E1 En E
156
Engineering-Oriented Design (EOD)
Analysis
Analysis and design of software systems based on use of

Models

QoS specifications (accounting for physical properties)

Quantitative analysis techniques and simulation
Complements
Complements any model -based development method
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:
Dilemma: How can we account for the engineering
aspects of the system without prematurely and possibly
unnecessarily committing to a particular technology?
Approach:
Approach: Provide an abstract technology -independent
technology-independent
but quantified specification of the required characteristics
of the engineering model as part of the logical model
158
Viewpoint Separation
Required
Required Environment
Environment:: a technology -neutral environment
technology-neutral
specification required by the logical elements of a model
Logical
Logical View
View
Required
Environment
Engineering
Engineering View
View (alternative
(alternative A)
A) Engineering
Engineering View
View (alternative
(alternative B)
B)
UNIX
UNIX UNIX
UNIX WinNT
WinNT WinNT
WinNT
Process
Process Process
Process Process
Process Process
Process
159
Required Environment Partitions
Logical
Logical elements often share common QoS requirements
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES QoS
QoS domain
domain
(e.g.,failure
(e.g.,failure unit,
unit,
uniform
uniform comm
comm properties)
properties)
160
QoS Domains
Specify
Specify a domain in which certain QoS values apply
universally:

failure characteristics (failure modes, availability, reliabilit y)
reliability)

CPU performance

communications characteristics (delay, throughput, capacity)

etc.
The
The QoS values of a domain can be compared against
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
Similar to realization: mapping of logical elements to a
desired (required) engineering environment
Logical
Logical View
View
GRMrequires:
GRMrequires:
aa specialization
specialization of
of the
the
realizes
realizes relationship
relationship
Required
Environment
QoS1
QoS1 QoS2
QoS2 QoS3
QoS3
UML base
Stereotype Tags
AA local
local engineering
engineering model
model concepts
GRM requires GRM realizes N/A
162
Example: QoS Domain for an Active Object
Using
Using a stereotype of Node

in conjunction with the required environment relationship
Active
Active class
class
R
R
UML base
readObj
readObj ()
() Stereotype Tags
concepts
priority [0..1] : Integer
Node,
GRMthreadEnv heap [0..1] : Real
Instance
stack [0..1] : Real
GRMrequires
GRMrequires
GRMthreadEnv
ThreadForR
{priority = 3; heap = 20 KB; Environment
Environment expected
expected
stack = 3 KB} by
by instances
instances of
of class
class RR
163
Example: Task Allocation
The
The allocation of logical model to engineering model
elements
Task1
master : Master d : DBaseServer
Task2
dBadmin : Admin
MainTask
Task3
poller : Poller cs : CommServer
164
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
dBadmin : Admin
GRMrequires
GRMrequires poller : Poller cs : CommServer GRMrequires
GRMrequires
GRMrequires
GRMrequires
GRMrequires
GRMrequires GRMrequires
GRMrequires
EngineeringPkgY
EngineeringPkgY
Task1 : Task Task2 : Task Task3 : Task MainTask : Task
import
import
EngineeringPkgZ
EngineeringPkgZ
GRMschedulableEntity
Task
165
Example: Completing the Mapping
Mapping
Mapping to hardware
EngineeringPkgY
EngineeringPkgY
GRMrealize
GRMrealize GRMrealize
GRMrealize
EngineeringPkgD
EngineeringPkgD
SAProcessingResource
Proc1
166
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
dBadmin : Admin
GRMrealize
GRMrealize poller : Poller cs : CommServer GRMrealize
GRMrealize
GRMrealize
GRMrealize
GRMrealize
GRMrealize
EngineeringPkgY
EngineeringPkgY
import
import
EngineeringPkgZ
EngineeringPkgZ
GRMschedulableEntity
Task
167
Example: Completing the Mapping
Mapping
Mapping to hardware
EngineeringPkgY
EngineeringPkgY
GRMrealize
GRMrealize
EngineeringPkgD
EngineeringPkgD
SAProcessingResource
Proc1
168
Summary: RT Design and Engineering
In
In complex RT systems, the logical design is strongly
influenced by the characteristics of the engineering
environment
In
In such systems, it is often crucial to formally determine if
a system will meet its non -functional requirements
non-functional
(throughput, response time, availability, etc.)
The
The QoS -based approach described here can serve as a
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

Real-Time

UML
Real-Time
The
Real-Time
Real-Time
Summary
170
Summary: The Problem
Complexity!
Complexity!
The
The design of real -time systems is influenced significantly
real-time
by the physical properties of:

the environment in which the system exists

the implementation technology
Most
Most of them stem from the physical world

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
The object paradigm

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
Engineering-oriented design

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
UML provides a common and standardized underpinning
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,
Furthermore, as a standard, it enables model interchange
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
Cooper,
Cooper, R.,
R., Introduction
Introduction to
to Queueing
Queueing Theory,
Theory, The
The Macmillan
Macmillan Compa ny, 1972.
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.
Klein,
Klein, M.M. et
et al.,
al., AA Practitioners
Practitioners Handbook
Handbook for
for Real -Time Analysis:
Real-Time Analysis: Guide
Guide to
to Rate
Rate Monotonic
Monotonic
Analysis
Analysis forfor Real -Time Systems,
Real-Time Systems, Kluwer
Kluwer Academic
Academic Publishers,
Publishers, 1993.
1993.
OMG,
OMG, The
The Unified
Unified Modeling
Modeling Language
Language version
version 1.3,
1.3, The
The Object
Object Man agement Group,
Management Group,
August
August 1999.
1999.
OMG,
OMG, UML
UML Profile
Profile for
for Scheduling,
Scheduling, Performance,
Performance, and and Time
Time -- Request
Request forfor Proposal,
Proposal, The
The
Object
Object Management
Management Group,
Group, March
March 1999
1999 (doc
(doc ad/99 -03-13).
ad/99-03-13).
UML
UML Real -Time Consortium,
Real-Time Consortium, Response
Response toto the
the OMG
OMG RFPRFP for
for Schedulability,
Schedulability, Pe rformance,
Performance,
and
and Time,
Time, August,
August, 2000
2000 (OMG
(OMG document
document ad/2000 -08-04).
ad/2000-08-04).
J.
J. Rumbaugh
Rumbaugh,, I.I. Jacobson,
Jacobson, andand G.
G. Booch
Booch,, The
The Unified
Unified Modeling
Modeling Language
Language Reference
Reference
Manual,,
Manual,, Addison -Wesley, 1999.
Addison-Wesley, 1999.
B.
B. Selic,
Selic, Turning
Turning Clockwise:
Clockwise: Using
Using UML
UML inin the
the Real -Time Domain,
Real-Time Domain, Communications
Communications of of the
the
ACM,
ACM, vol.42,
vol.42, no.10,
no.10, October
October 1999
1999 (pp.46 -54).
(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,
no.6, June
June 2000
2000 (pp.
(pp. 64 -69).
64-69).
B.
B. Selic
Selic and
and J.
J. Rumbaugh:
Rumbaugh: Using
Using UML
UML for
for Modeling
Modeling Complex
Complex Real -Time Systems,
Real-Time Systems,
ObjecTime
ObjecTime Limited
Limited and
and Rational
Rational Software
Software Corp.,
Corp., March
March 1998.
1998. (http ://www.rational.com)
(http://www.rational.com)
175

04 1 Selic Watson RT UML - Tutorial

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

04 1 Selic Watson RT UML - Tutorial

Hochgeladen von

Copyright:

Verfügbare Formate

The Real-Time UML Standard:

AA persistent structure that provides a framework for

Which procedure(s) describe this system?

AAA BBB ACC BDD AAE BBF A CG BDH

The crucially important system structure is almost

The object paradigm allows us to create our own (virtual)

AA conflict between top -down and bottom

busy : boolean Generalization

AA consolidation of proven ideas and practices based on

Approved minor revision May 2001 UML 1.4

Current minor revision 1999 UML 1.3

UML partners UML 1.0

Web - June 1996 UML 0.9

OOPSLA 95 Unified Method 0.8

Other methods OOSE Booch method OMT

Radio: Designer view

Radio: Radio: user view

Model-view consistency is enforced through the UML metamodel

/Caller /Operator /Callee

master : Master d : DBaseServer cs : CommServer

{(register.receiveTime ( ) - read.sendTime( )) 2 ms}

RTC eliminates potential

AA high priority event for another active object will preempt

:Planner update Node

Generally not sophisticated

AA package of related specializations of general UML

Analysis & Design

General Resource Model profile

Domain model Profile Packages (normative)

General Resource Modeling Framework

Analysis Models Infrastructure Models

profile profile modelLibrary

Practically all analysis methods are concerned with instance

Resourc eUs ageModel

ResourceInstance +inst ance +type Resource

1..n +offeredService 1..n

+cause 1 0..n +methodExecution

protectionKind activenes sKind

ProtectedResource UnprotectedResource PassiveResource ActiveResource

Device Processor CommunicationResource

1 0..n 0..n 0..n

1..n 1..n 1..n +managedResource

Stereotype UML base concepts Tags

Tag Tag Type

GRMclient GRMprotResource GRMclient

GRMserv register() {GRMwcet = 20ms}

{isSchedulable= .$?} {isSchedulable= True}

+generatedInt errupts 0..n +generatedTimeouts 0..n

Tag Tag Type Multiplicity Domain Name

StimulusGeneration +cause +effect Stimulus

0..n +start TimeValue

These two associations are 0..n

b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow

May be very sophisticated and express complex

time values (instants and durations) including

AA timing mark identifies the time of an event occurrence

{call.sendTime() - ack.receiveTime < 10 sec}

RTaction Action, ActionExecution, RTstart [0..1] An action that takes time

RTnewClock Operation RTstart [0..1] An operation that creates a

RTtime DataValue, Instance, Object, RTkind [0..1] A time value or a time

Res ourceServiceInst ance ConcurrentUnit

DeferredService Immediat eServic e Scenario StimuliQueue

+step 1..n 0...