The Real- -Time UML Standard: Time UML Standard: The Real The - - PowerPoint PPT Presentation

the real time uml standard time uml standard the real the
SMART_READER_LITE
LIVE PREVIEW

The Real- -Time UML Standard: Time UML Standard: The Real The - - PowerPoint PPT Presentation

The Real- -Time UML Standard: Time UML Standard: The Real The Real-Time UML Standard: Theory and Application Theory and Application Theory and Application Bran Selic Ben Watson Bran Selic Ben Watson Rational Software Canada Tri-


slide-1
SLIDE 1

The Real-Time UML Standard: Theory and Application The Real The Real-

  • Time UML Standard:

Time UML Standard: Theory and Application Theory and Application

Ben Watson Ben Watson Tri Tri-

  • Pacific Software, Inc.

Pacific Software, Inc. watson@tripac.com watson@tripac.com Bran Selic Bran Selic Rational Software Canada Rational Software Canada bselic bselic@rational.com @rational.com

slide-2
SLIDE 2

2

Tutorial Objectives Tutorial Objectives

♦To clarify the relationship between the object paradigm and real-time systems

■ match or mismatch?

♦Describe and analyze UML from a real-time designer’s perspective ♦To introduce the “UML Profile for Schedulability, Performance, and Time” ♦To introduce an engineering-oriented design approach for real-time systems ♦ ♦To clarify the relationship between the object paradigm To clarify the relationship between the object paradigm and real and real-

  • time systems

time systems

■ ■ match or mismatch?

match or mismatch?

♦ ♦Describe and analyze UML from a real Describe and analyze UML from a real-

  • time designer’s

time designer’s perspective perspective ♦ ♦To introduce the To introduce the “UML Profile for Schedulability, “UML Profile for Schedulability, Performance, and Time” Performance, and Time” ♦ ♦To introduce an To introduce an engineering engineering-

  • oriented design
  • riented design approach

approach for real for real-

  • time systems

time systems

slide-3
SLIDE 3

3

Tutorial Overview Tutorial Overview

♦Real-Time Systems and the Object Paradigm ♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm ♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-4
SLIDE 4

4

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-5
SLIDE 5

5

environment environment

Real Real-

  • Time System

Time System

Real Real-

  • Time

Time System System (state) (state) signal signal source source controlled entities controlled controlled entities entities

  • utputs
  • utputs

inputs inputs signal signal source source inputs inputs

  • outputs = f (inputs, state)
  • utputs = f (inputs, state)

♦Systems that maintain an ongoing timely interaction with its environment ♦ ♦Systems that maintain an Systems that maintain an ongoing timely

  • ngoing timely interaction with

interaction with its environment its environment

  • coordination

coordination

slide-6
SLIDE 6

6

Under the Hood Under the Hood

♦A persistent structure that provides a framework for behavior ♦ ♦A persistent structure that provides a framework for A persistent structure that provides a framework for behavior behavior

environment environment Real Real-

  • Time

Time System System (state) (state) signal signal source source controlled entities controlled controlled entities entities

  • utputs
  • utputs

inputs inputs signal signal source source inputs inputs

  • outputs = f (inputs, state)
  • utputs = f (inputs, state)
  • coordination

coordination

Agent Agent Agent Agent Agent Agent

Concurrency conflict Concurrency conflict Concurrency conflict

slide-7
SLIDE 7

7

Classifications of RT Systems Classifications of RT Systems

♦Based on nature of key inputs

■ time-driven: for continuous (synchronous) inputs ■ event-driven: for discrete (asynchronous) inputs

♦Based on time criticality

■ hard RT systems: every input must have a timely response ■ soft RT systems: most inputs must have timely response

♦Based on load:

■ static: fixed deterministic load ■ dynamic: variable (non-deterministic) load

♦Many practical systems are combinations of these ♦ ♦Based on nature of key inputs Based on nature of key inputs

■ ■ time

time-

  • driven:

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

■ ■ event

event-

  • driven:

driven: for discrete (asynchronous) inputs for discrete (asynchronous) inputs

♦ ♦Based on time criticality Based on time criticality

■ ■ hard RT systems:

hard RT systems: every input must have a timely response every input must have a timely response

■ ■ soft RT systems:

soft RT systems: most inputs must have timely response most inputs must have timely response

♦ ♦Based on load: Based on load:

■ ■ static:

static: fixed deterministic load fixed deterministic load

■ ■ dynamic:

dynamic: variable (non variable (non-

  • deterministic) load

deterministic) load

♦ ♦Many practical systems are combinations of these Many practical systems are combinations of these

slide-8
SLIDE 8

8

Which procedure(s) describe this system? Which procedure(s) describe this system?

INSTRUCTOR STATION INSTRUCTOR INSTRUCTOR STATION STATION AIRFRAME AIRFRAME AIRFRAME GROUND MODEL GROUND GROUND MODEL MODEL ATMOSPHERE MODEL ATMOSPHERE ATMOSPHERE MODEL MODEL ENGINES ENGINES ENGINES CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES PILOT CONTROLS PILOT PILOT CONTROLS CONTROLS

Sample Real Sample Real-

  • Time Application

Time Application

slide-9
SLIDE 9

9

Classical Approach: Cyclical Executive Classical Approach: Cyclical Executive

The miscellaneous procedural slices are executed cyclically based on time resolution The crucially important system structure is almost The crucially important system structure is almost completely obscured completely obscured

A A B B A A A A B B B B A A B B A A B B C C A A D D B B C C D D A B C E D F G H

= 50 msec band = 50 msec band = 100 msec band (2 parts: A and B) = 100 msec band (2 parts: A and B) = 200 msec band (4 parts: A, B, C, D) = 200 msec band (4 parts: A, B, C, D) = 400 msec band (8 parts: A, B, C, D, E, F, G, H) = 400 msec band (8 parts: A, B, C, D, E, F, G, H)

50msec 50msec

ENGINES ENGINES ENGINES

slide-10
SLIDE 10

10

Problems with the Traditional Solution Problems with the Traditional Solution

♦The solution is adjusted to fit the implementation technology (i.e., the step-at-a-time programming style of procedural programming) rather than human needs ⇒ In addition to the inherent complexity of the problem designers need to contend with the accidental complexity

  • f the implementation technology

♦Overwhelming complexity is by far the biggest hurdle in most real-time software systems reducing complexity is crucial to success ♦ ♦The solution is adjusted to fit the implementation The solution is adjusted to fit the implementation technology (i.e., the step technology (i.e., the step-

  • at

at-

  • a

a-

  • time programming style of

time programming style of procedural programming) rather than human needs procedural programming) rather than human needs ⇒ ⇒ In addition to the inherent complexity of the problem In addition to the inherent complexity of the problem designers need to contend with the accidental complexity designers need to contend with the accidental complexity

  • f the implementation technology
  • f the implementation technology

♦ ♦Overwhelming complexity is by far the biggest hurdle in Overwhelming complexity is by far the biggest hurdle in most real most real-

  • time software systems

time software systems reducing complexity is crucial to success reducing complexity is crucial to success

slide-11
SLIDE 11

11

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials ■ Essentials of the Object Paradigm

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

■ ■ Essentials of the Object Paradigm

Essentials of the Object Paradigm

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-12
SLIDE 12

12

The Essence of the Object Paradigm The Essence of the Object Paradigm

♦Combines all the various features of a logical unit (procedures and data) into a single package called an object ♦ ♦Combines all the various features of a logical unit Combines all the various features of a logical unit (procedures and data) into a single package called (procedures and data) into a single package called an an object

  • bject

Atmosphere Atmosphere Atmosphere Airframe Airframe Airframe Control Surfaces Control Control Surfaces Surfaces

♦Defines a software system as a structure of collaborating objects ♦Defines a software system as a structure of collaborating objects

slide-13
SLIDE 13

13

Objects and Real Objects and Real-

  • Time Systems

Time Systems

♦The structure of real-time systems tends to persist through time because it reflects the physical entities of the real world ♦This structure is the framework through which (infinitely) many different behavior threads are executed ♦Hence, the focus is on structure rather than behavior ♦The structural focus of the object paradigm is better suited to real-time systems than the procedural paradigm ♦ ♦The structure of real The structure of real-

  • time systems tends to persist

time systems tends to persist through time because it reflects the physical entities of through time because it reflects the physical entities of the real world the real world ♦ ♦This structure is the framework through which (infinitely) This structure is the framework through which (infinitely) many different behavior threads are executed many different behavior threads are executed ♦ ♦Hence, the focus is on structure rather than behavior Hence, the focus is on structure rather than behavior ♦ ♦The structural focus of the object paradigm is better The structural focus of the object paradigm is better suited to real suited to real-

  • time systems than the procedural paradigm

time systems than the procedural paradigm

slide-14
SLIDE 14

14

Yes, But What About... Yes, But What About...

♦Performance?

■ the cost of abstraction (encapsulation, automatic garbage

collection, dynamic binding, etc.)

♦Modeling real-time specific phenomena?

■ time and timing mechanisms ■ resources (processors, networks, semaphores, etc.)

♦Exploiting current real-time system theory?

■ schedulability analysis (e.g., rate-monotnic theory) ■ performance analysis (queueing theory)

♦ ♦Performance? Performance?

■ ■ the cost of abstraction (encapsulation, automatic garbage

the cost of abstraction (encapsulation, automatic garbage collection, dynamic binding, etc.) collection, dynamic binding, etc.)

♦ ♦Modeling real Modeling real-

  • time specific phenomena?

time specific phenomena?

■ ■ time and timing mechanisms

time and timing mechanisms

■ ■ resources (processors, networks, semaphores, etc.)

resources (processors, networks, semaphores, etc.)

♦ ♦Exploiting current real Exploiting current real-

  • time system theory?

time system theory?

■ ■ s

schedulability chedulability analysis (e.g., rate analysis (e.g., rate-

  • monotnic

monotnic theory) theory)

■ ■ performance analysis (queueing theory)

performance analysis (queueing theory)

slide-15
SLIDE 15

15

Performance of OO Technology Performance of OO Technology

♦Hardware is becoming ever faster (Moore’s law)

■ previously unacceptable response times may now be

acceptable

♦OO software technologies are becoming real-time aware

■ bounded dynamic binding techniques ■ tunable automatic garbage collection (bounded latency) ■ real-time variants of popular OO languages (e.g., EC++, RT

Java)

♦ ♦Hardware is becoming ever faster ( Hardware is becoming ever faster (Moore’s Moore’s law) law)

■ ■ previously unacceptable response times may now be

previously unacceptable response times may now be acceptable acceptable

♦ ♦OO software technologies are becoming real OO software technologies are becoming real-

  • time aware

time aware

■ ■ bounded dynamic binding techniques

bounded dynamic binding techniques

■ ■ tunable automatic garbage collection (bounded latency)

tunable automatic garbage collection (bounded latency)

■ ■ real

real-

  • time variants of popular OO languages (e.g., EC++, RT

time variants of popular OO languages (e.g., EC++, RT Java) Java)

slide-16
SLIDE 16

16

Objects Objects

♦ ♦Conceptual units with Conceptual units with

■ ■ a unique identity (dedicated memory)

a unique identity (dedicated memory)

Telephone1: busy : boolean

  • ffHook()
  • nHook ()

ring()

void:offHook (); {busy = true; reqDialtone(); … };

■ ■ a public interface

a public interface

■ ■ a hidden (encapsulated) implementation

a hidden (encapsulated) implementation

Data Attributes Data Attributes

Operations Operations

slide-17
SLIDE 17

17

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

Conceptual Objects Conceptual Objects

♦Not all objects necessarily require a physical underpinning ♦For example, the “telephone call” object ♦ ♦Not all objects necessarily require a physical Not all objects necessarily require a physical underpinning underpinning ♦ ♦For example, the “telephone call” object For example, the “telephone call” object

Telephone Call Object Telephone Call Object Telephone1 Telephone1 Telephone1 Telephone2 Telephone2 Telephone2

Telephone Call Telephone Call

abortCall abortCall () () addParty addParty (t:Telephone) (t:Telephone) reportDuration reportDuration () ()

slide-18
SLIDE 18

18

Object Behavior Object Behavior

♦In essence, an object is a server

■ generic object lifecycle:

♦ ♦In essence, an object is a In essence, an object is a server server

■ ■ generic object lifecycle:

generic object lifecycle:

Handle Request Handle Handle Request Request Initialize Object Initialize Initialize Object Object Terminate Object Terminate Terminate Object Object Wait for Request Wait for Wait for Request Request

void:offHook (); {busy = true;

  • bj.reqDialtone();

… }; void:offHook (); {busy = true;

  • bj.reqDialtone();

… };

Handling depends

  • n specific request

type and object state Handling depends

  • n specific request

type and object state Invokes

  • perations on
  • ther objects

Invokes

  • perations on
  • ther objects
slide-19
SLIDE 19

19

Making Things Happen with Objects Making Things Happen with Objects

♦Higher-level behavior “emerges” through the interactions

  • f individual objects

♦ ♦Higher Higher-

  • level behavior “emerges” through the interactions

level behavior “emerges” through the interactions

  • f individual objects
  • f individual objects

Atmosphere: Airframe: Spolier:

2.gust() 2.gust() 3.position() 3.position() 4.change() 4.change() 1.roughAir() 1.roughAir()

slide-20
SLIDE 20

20

Objects and Emergent Behavior Objects and Emergent Behavior

♦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

■ “keyhole” view of high-level behavior ■ difficult to ensure desired high-level behavior will necessarily

emerge

♦A conflict between top-down and bottom-up design approaches

■ re-usable component programming style defines objects

independently of the sequences in which they may participate

♦ ♦One of the main problems of many current OO One of the main problems of many current OO programming languages is that they do not provide a programming languages is that they do not provide a means for specifying high means for specifying high-

  • level emergent behavior

level emergent behavior

■ ■ “keyhole” view of high

“keyhole” view of high-

  • level behavior

level behavior

■ ■ difficult to ensure desired high

difficult to ensure desired high-

  • level behavior will necessarily

level behavior will necessarily emerge emerge

♦ ♦A conflict between top A conflict between top-

  • down and bottom

down and bottom-

  • up design

up design approaches approaches

■ ■ re

re-

  • usable component programming style defines objects

usable component programming style defines objects independently of the sequences in which they may participate independently of the sequences in which they may participate

slide-21
SLIDE 21

21

TelephoneClass busy : boolean

  • ffHook()
  • nHook ()

ring() Telephone1:TelephoneClass Telephone2:TelephoneClass Class (Spec) Class (Spec) Class Instance Class Instance

Classes and Instances Classes and Instances

♦More than one object can be constructed from the same specification–the class

■ A design environment concept

♦ ♦More than one object can be constructed from the same More than one object can be constructed from the same specification specification– –the class the class

■ ■ A design environment concept

A design environment concept

♦Objects created from some class specification are called instances of that class

■ A run-time concept

♦ ♦Objects created from some class specification are called Objects created from some class specification are called instances of that class instances of that class

■ ■ A run

A run-

  • time concept

time concept

slide-22
SLIDE 22

22

Inheritance and Polymorphism Inheritance and Polymorphism

♦ ♦A generalization and re A generalization and re-

  • use mechanism

use mechanism

GenericTelephone busy : boolean

  • ffHook()
  • nHook ()

dialDigit() RotaryDial Telephone busy : boolean

  • ffHook()
  • nHook ()

dialDigit() TouchTone Telephone busy : boolean

  • ffHook()
  • nHook ()

dialDigit() playTone()

Polymorphism: different realizations

  • f the same operation

Polymorphism: different realizations

  • f the same operation

Polymorphism: different realizations

  • f the same operation

Polymorphism: different realizations

  • f the same operation

Generalization (inheritance) relationship Generalization (inheritance) relationship

slide-23
SLIDE 23

23

Objects: Summary Objects: Summary

♦The object paradigm is very well adapted to real-time software systems because of its powerful structural modeling capability

■ networks of collaborating objects

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

■ modularity ■ information hiding ■ generalization/refinement mechanisms (e.g., inheritance) ■ genericity

♦ ♦The object paradigm is very well adapted to real The object paradigm is very well adapted to real-

  • time

time software systems because of its powerful structural software systems because of its powerful structural modeling capability modeling capability

■ ■ networks of collaborating objects

networks of collaborating objects

♦ ♦In addition, the object paradigm comes packaged with a In addition, the object paradigm comes packaged with a number of well number of well-

  • established techniques:

established techniques:

■ ■ modularity

modularity

■ ■ information hiding

information hiding

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

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

■ ■ genericity

genericity

slide-24
SLIDE 24

24

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials ■ Essentials of the Object Paradigm

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

■ ■ Essentials of the Object Paradigm

Essentials of the Object Paradigm

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-25
SLIDE 25

25

The Unified Modeling Language The Unified Modeling Language

♦A consolidation of proven ideas and practices based on the object paradigm into a general-purpose OO modeling language

■ Inititated by Rational Software (Booch, Rumbaugh, Jacobson)

♦Standardized by the Object Management Group in 1997 ♦Major advantages:

■ widely adopted by software practitioners ■ widely taught in universities and technical seminars ■ supported by many software tool vendors

♦ ♦A consolidation of proven ideas and practices based on A consolidation of proven ideas and practices based on the object paradigm into a general the object paradigm into a general-

  • purpose OO modeling

purpose OO modeling language language

■ ■ Inititated

Inititated by Rational Software ( by Rational Software (Booch Booch, Rumbaugh, Jacobson) , Rumbaugh, Jacobson)

♦ ♦Standardized by the Object Management Group in 1997 Standardized by the Object Management Group in 1997 ♦ ♦Major advantages: Major advantages:

■ ■ widely adopted by software practitioners

widely adopted by software practitioners

■ ■ widely taught in universities and technical seminars

widely taught in universities and technical seminars

■ ■ supported by many software tool vendors

supported by many software tool vendors

slide-26
SLIDE 26

26

UML 1.0 UML 1.0

UML partners UML partners OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997

UML 1.1 UML 1.1 UML 2.0 UML 2.0

Planned major revision (2002) Planned major revision (2002)

Public Feedback

Current minor revision 1999 Current minor revision 1999 UML 1.3 UML 1.3

Web - June 1996 Web - June 1996

UML 0.9 UML 0.9 Unified Method 0.8 Unified Method 0.8

OOPSLA 95 OOPSLA 95

OMT OMT Booch method Booch method OOSE OOSE Other methods Other methods Harel Statecharts

Evolution of UML Evolution of UML

Approved minor revision May 2001 Approved minor revision May 2001 UML 1.4 UML 1.4

slide-27
SLIDE 27

27

Components of UML Components of UML

♦Basic set of (extensible) modeling concepts

■ used for modeling both problems and solutions (object, class,

association)

■ deep semantic roots

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

■ 8 different diagram types (requirements, structure, behavior,

deployment)

♦ ♦Basic set of (extensible) modeling concepts Basic set of (extensible) modeling concepts

■ ■ used for modeling both problems and solutions (object, class,

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

■ ■ deep semantic roots

deep semantic roots

♦ ♦Formal rules of semantically meaningful composition Formal rules of semantically meaningful composition (well (well-

  • formedness)

formedness) ♦ ♦Graphical notation for modeling concepts Graphical notation for modeling concepts

■ ■ 8 different diagram types (requirements, structure, behavior,

8 different diagram types (requirements, structure, behavior, deployment) deployment)

slide-28
SLIDE 28

28

Introducing Views and Viewpoints 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

♦ ♦ Viewpoint: Viewpoint: a set of related concerns regarding some system a set of related concerns regarding some system ♦ ♦ View: View: a a model model of a system based on a particular viewpoint

  • f a system based on a particular viewpoint

■ ■ abstracts out detail that is irrelevant for that set of concerns

abstracts out detail that is irrelevant for that set of concerns Radio: Radio: user view Radio: Radio: user view Radio: Designer view Radio: Designer view

slide-29
SLIDE 29

29

View 2 View 2 V i e w 3 V i e w 3 View 1 View 1

Model Model-

  • Based and View

Based and View-

  • Based Approaches

Based Approaches

♦UML uses a model-based approach rather than a view- based approach ♦ ♦UML uses a model UML uses a model-

  • based approach rather than a view

based approach rather than a view-

  • based approach

based approach

View 2 View 2 V i e w 3 V i e w 3 View 1 View 1

? ? ?

Model Model-

  • view consistency is enforced through the UML metamodel

view consistency is enforced through the UML metamodel

slide-30
SLIDE 30

30

UML Model Views UML Model Views

♦Requirements (use case diagrams) ♦Static structure (class diagrams)

■ kinds of objects and their relationships

♦Object behavior (state machines)

■ possible life histories of an object

♦Inter-object behavior (activity, sequence, and collaboration diagrams)

■ flow of control among objects to achieve system-level behavior

♦Physical implementation structures (component and deployment diagrams)

■ software modules and deployment on physical nodes

♦ ♦Requirements (use case diagrams) Requirements (use case diagrams) ♦ ♦Static structure (class diagrams) Static structure (class diagrams)

■ ■ kinds of objects and their relationships

kinds of objects and their relationships

♦ ♦Object behavior (state machines) Object behavior (state machines)

■ ■ possible life histories of an object

possible life histories of an object

♦ ♦Inter Inter-

  • object behavior (activity, sequence, and
  • bject behavior (activity, sequence, and

collaboration diagrams) collaboration diagrams)

■ ■ flow of control among objects to achieve system

flow of control among objects to achieve system-

  • level behavior

level behavior

♦ ♦Physical implementation structures (component and Physical implementation structures (component and deployment diagrams) deployment diagrams)

■ ■ software modules and deployment on physical nodes

software modules and deployment on physical nodes

slide-31
SLIDE 31

31

AircraftSimulator AircraftSimulator AircraftSimulator

Use Case Diagrams Use Case Diagrams

♦Used to capture functional requirements

■ useful as principal drivers of the overall development process

♦ ♦Used to capture functional requirements Used to capture functional requirements

■ ■ useful as principal drivers of the overall development process

useful as principal drivers of the overall development process

instructor instructor instructor trainee trainee trainee

Run checklist Run checklist

«include» «include»

Prepare flight Prepare flight Land plane Land plane Fail one engine Fail one engine Use case Use case actor actor

slide-32
SLIDE 32

32

Use Cases and RT Systems Use Cases and RT Systems

♦As useful as in any other domain

■ fundamental drivers of definition, development, and testing

♦However….

■ Focus on function (functional requirements) ■ In RT systems, much focus on non-functional requirements

  • e.g., end-to-end delays, maximum response times,…

■ No standard way of associating such non-functional

requirements with use cases

■ Use cases do not deal with many important “ilities” (availability,

reliability, maintainability,…) that are critical in many real-time systems

♦ ♦As useful as in any other domain As useful as in any other domain

■ ■ fundamental drivers of definition, development, and testing

fundamental drivers of definition, development, and testing

♦ ♦However…. However….

■ ■ Focus on function (functional requirements)

Focus on function (functional requirements)

■ ■ In RT systems, much focus on non

In RT systems, much focus on non-

  • functional requirements

functional requirements

  • e.g., end

e.g., end-

  • to

to-

  • end delays, maximum response times,…

end delays, maximum response times,…

■ ■ No standard way of associating such non

No standard way of associating such non-

  • functional

functional requirements with use cases requirements with use cases

■ ■ Use cases do not deal with many important “

Use cases do not deal with many important “ilities ilities” (availability, ” (availability, reliability, maintainability,…) that are critical in many real reliability, maintainability,…) that are critical in many real-

  • time

time systems systems

slide-33
SLIDE 33

33

designatedPlane designatedPlane crew crew 1..* 1..* 1 1

Pilot Pilot Airplane Airplane Airline Airline

  • wner
  • wner

0..* 0..* 0..* 0..*

Flight Flight

route start duration route start duration

{ordered} {ordered} 0..* 0..* 1 1

Captain Captain First Officer First Officer

Class Diagram Class Diagram

♦Shows the entities in a system and their general relationships ♦ ♦Shows the entities in a system and their general Shows the entities in a system and their general relationships relationships

Association Association Association class Association class

slide-34
SLIDE 34

34

Object Instance Diagram Object Instance Diagram

♦Shows object instances in a particular case ♦ ♦Shows object instances in a particular case Shows object instances in a particular case

DecrepitAir : Airline DecrepitAir : Airline

N1313:Airplane N1313:Airplane

CreakyAir : Airline CreakyAir : Airline CA345 : Flight CA345 : Flight Donald D. : Pilot Donald D. : Pilot Link Link CA123 : Flight CA123 : Flight Mickey M. : Pilot Mickey M. : Pilot

slide-35
SLIDE 35

35

Class Diagrams and RT Systems Class Diagrams and RT Systems

♦Class diagrams are very abstract and sometimes leave

  • ut crucial system information (e.g., topology)

■ e.g., common class diagram for both systems

♦ ♦Class diagrams are very abstract and sometimes leave Class diagrams are very abstract and sometimes leave

  • ut crucial system information (e.g., topology)
  • ut crucial system information (e.g., topology)

■ ■ e.g., common class diagram for both systems

e.g., common class diagram for both systems

N1:Node N1:Node N3:Node N3:Node N4:Node N4:Node N2:Node N2:Node N2:Node N2:Node N1:Node N1:Node N3:Node N3:Node Node Node

0..2 0..2

slide-36
SLIDE 36

36

Object Diagrams to the Rescue? Object Diagrams to the Rescue?

♦Object (instance) diagrams do show topologies ♦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

♦ ♦Object (instance) diagrams do show topologies Object (instance) diagrams do show topologies ♦ ♦However… However…

■ ■ in principle, object diagrams only represent “snapshots” of a

in principle, object diagrams only represent “snapshots” of a system at a particular point in time system at a particular point in time

■ ■ no guarantee that they hold throughout the lifetime of the

no guarantee that they hold throughout the lifetime of the system system

■ ■ need “prototypical” object diagrams

need “prototypical” object diagrams

■ ■ but, such semantics are not defined in the current standard

but, such semantics are not defined in the current standard

slide-37
SLIDE 37

37

Collaboration Diagram Collaboration Diagram

2.call() 2.call() 3.sendTone() 3.sendTone() 4.dialtone() 4.dialtone() 1.offHook() 1.offHook()

P1:BusSet P1:BusSet P2:TTSet P2:TTSet

♦Depict generic structural and behavioral patterns ♦ ♦Depict generic structural and behavioral patterns Depict generic structural and behavioral patterns

/PhoneIF /PhoneIF /CallProc /CallProc /ToneGen /ToneGen P1:BusSet P1:BusSet Classifier role Classifier role P2:TTSet P2:TTSet NB: It is possible to have collaboration diagrams without an Interactions

  • verlay (“pure” structure)

NB: It is possible to have collaboration diagrams without an Interactions

  • verlay (“pure” structure)
slide-38
SLIDE 38

38

/Caller /Caller /Operator /Operator / /Callee Callee time time call ack number call ack talk transfer

Sequence Diagrams Sequence Diagrams

♦ Show interactions between objects with a focus on communications (a different representation of a collaboration) ♦ ♦ Show interactions between objects with a focus on Show interactions between objects with a focus on communications (a different representation of a collaboration) communications (a different representation of a collaboration)

slide-39
SLIDE 39

39

Sequence Diagrams and RT Systems Sequence Diagrams and RT Systems

♦Sequence diagrams are extremely useful for showing

  • bject interactions

■ very common in many real-time systems ■ well suited for event-driven behavior ■ in telecom, many protocol standards are defined using

sequence diagrams

♦However…

■ No standard way of denoting timing information ■ UML sequence diagrams do not scale up very well for

modeling large systems with complex sequences

♦ ♦Sequence diagrams are extremely useful for showing Sequence diagrams are extremely useful for showing

  • bject interactions
  • bject interactions

■ ■ very common in many real

very common in many real-

  • time systems

time systems

■ ■ well suited for event

well suited for event-

  • driven behavior

driven behavior

■ ■ in telecom, many protocol standards are defined using

in telecom, many protocol standards are defined using sequence diagrams sequence diagrams

♦ ♦However… However…

■ ■ No standard way of denoting timing information

No standard way of denoting timing information

■ ■ UML sequence diagrams do not scale up very well for

UML sequence diagrams do not scale up very well for modeling large systems with complex sequences modeling large systems with complex sequences

slide-40
SLIDE 40

40

Using Timing Marks with Sequence Diagrams Using Timing Marks with Sequence Diagrams

♦Specifying constraints ♦ ♦Specifying constraints Specifying constraints

master : Master d : DBaseServer cs : CommServer read( ) register( )

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

slide-41
SLIDE 41

41

Activity Diagrams Activity Diagrams

♦Different focus compared to sequence diagrams ♦ ♦Different focus compared to sequence diagrams Different focus compared to sequence diagrams

/Caller /Operator /Callee

Contact Operator Contact Contact Operator Operator Contact Callee Contact Contact Callee Callee Respond Respond Respond Notify Parties Notify Notify Parties Parties Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge

activity activity swimlane swimlane

slide-42
SLIDE 42

42

Activity Diagrams and RT Systems Activity Diagrams and RT Systems

♦Better than sequence diagrams for

■ showing concurrency (forks and joins are explicit) ■ scaling up to complex systems

♦However…

■ No standard way of denoting timing information ■ Less well-suited for describing event-driven behavior

♦ ♦Better than sequence diagrams for Better than sequence diagrams for

■ ■ showing concurrency (forks and joins are explicit)

showing concurrency (forks and joins are explicit)

■ ■ scaling up to complex systems

scaling up to complex systems

♦ ♦However… However…

■ ■ No standard way of denoting timing information

No standard way of denoting timing information

■ ■ Less well

Less well-

  • suited for describing event

suited for describing event-

  • driven behavior

driven behavior

slide-43
SLIDE 43

43

State Machine Diagram State Machine Diagram

created created ready ready

♦ ♦Each state corresponds to a selective receive action Each state corresponds to a selective receive action

Handle Event Handle Handle Event Event Initialize Object Initialize Initialize Object Object Terminate Object Terminate Terminate Object Object Wait for Event Wait for Wait for Event Event

start/^master.ready() start/^master.ready() poll/^master.ack() poll/^master.ack() stop/ stop/

Initial pseudostate Initial pseudostate State machine State machine State State trigger trigger Action expression Action expression Final state Final state transition transition

slide-44
SLIDE 44

44

Hierarchical States and Transitions Hierarchical States and Transitions

♦Allows step-wise refinement and viewing of complex behavior ♦Allows step-wise refinement and viewing of complex behavior

OffLine OnLine

  • ff/
  • n/

Ready Busy

req/handle() done/

group transition group transition default transition default transition composite state composite state

slide-45
SLIDE 45

45

State Machines and RT Systems State Machines and RT Systems

♦Many real-time systems are event-driven

■ very well suited to those systems ■ scale up very nicely

♦However…

■ not directly connected to time (except for time events) ■ e.g., run-to-completion paradigm

♦ ♦Many real Many real-

  • time systems are event

time systems are event-

  • driven

driven

■ ■ very well suited to those systems

very well suited to those systems

■ ■ scale up very nicely

scale up very nicely

♦ ♦However… However…

■ ■ not directly connected to time (except for time events)

not directly connected to time (except for time events)

■ ■ e.g., run

e.g., run-

  • to

to-

  • completion paradigm

completion paradigm

slide-46
SLIDE 46

46

Implementing Time Implementing Time-

  • Triggered Systems

Triggered Systems

♦Periodic timers:

■ once initiated they repeatedly send TimeEvents at the

appropriate intervals until explicitly stopped or cancelled

♦In “steady-state” mode, active objects stimulated exclusively by periodic timers become periodic tasks

■ allows rate-monotonic scheduling policies ■ schedulers use the priorities of periodic timers to make

scheduling decisions

♦ ♦Periodic timers: Periodic timers:

■ ■ once initiated they repeatedly send

  • nce initiated they repeatedly send TimeEvents

TimeEvents at the at the appropriate intervals until explicitly stopped or cancelled appropriate intervals until explicitly stopped or cancelled

♦ ♦In “steady In “steady-

  • state” mode, active objects stimulated

state” mode, active objects stimulated exclusively by periodic timers become periodic tasks exclusively by periodic timers become periodic tasks

■ ■ allows rate

allows rate-

  • monotonic scheduling policies

monotonic scheduling policies

■ ■ schedulers use the priorities of periodic timers to make

schedulers use the priorities of periodic timers to make scheduling decisions scheduling decisions

slide-47
SLIDE 47

47

Handle Request Handle Handle Request Request Initialize Object Initialize Initialize Object Object Terminate Object Terminate Terminate Object Object Wait for Request Wait for Wait for Request Request Handle Request Handle Handle Request Request Initialize Object Initialize Initialize Object Object Terminate Object Terminate Terminate Object Object Wait for Request Wait for Wait for Request Request

Objects and Concurrency Objects and Concurrency

♦ Passive objects: have no control of their communications

■ Clients determine when to invoke an operation

♦ ♦ Passive objects: Passive objects: have no control of their communications have no control of their communications

■ ■ Clients determine when to invoke an operation

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

♦ ♦ Active objects: Active objects: can control when to respond to requests can control when to respond to requests

■ ■ Can avoid concurrency conflicts

Can avoid concurrency conflicts

■ ■ Require at least one independent engineering

Require at least one independent engineering-

  • level thread

level thread

slide-48
SLIDE 48

48

The Active Objects of UML The Active Objects of UML

♦Single thread of execution ♦Behavior defined by state machines (event driven) ♦ ♦Single thread of execution Single thread of execution ♦ ♦Behavior defined by state machines (event driven) Behavior defined by state machines (event driven)

anActiveObject anActiveObject # #currentEvent currentEvent : Event : Event + start ( ) + start ( ) + poll ( ) + poll ( ) + stop ( ) + stop ( ) created ready

start/^master.ready() poll/^master.ack() stop/ poll/defer

ready created start

start/^master.ready()

ready

slide-49
SLIDE 49

49

anActiveObject anActiveObject

created

ready

created

Active Object Semantics Active Object Semantics

RTC eliminates potential concurrency conflicts

♦ ♦Concurrent incoming events are queued and handled Concurrent incoming events are queued and handled

  • ne
  • ne-
  • at

at-

  • a

a-

  • time regardless of priority

time regardless of priority ♦ ♦run run-

  • to

to-

  • completion

completion (RTC) execution model (RTC) execution model

slide-50
SLIDE 50

50

Active1 Active1 Active1 Active2 Active2 Active2

RTC Semantics RTC Semantics

♦A high priority event for another active object will preempt an active object on the same processor that is handling a low-priority event

■ Limited priority inversion can occur

♦ ♦A high priority event for another active object will preempt A high priority event for another active object will preempt an active object on the same processor that is handling a an active object on the same processor that is handling a low low-

  • priority event

priority event

■ ■ Limited priority inversion can occur

Limited priority inversion can occur

hi hi lo (queued)

slide-51
SLIDE 51

51

RTC Analysis RTC Analysis

♦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

not need to be preserved)

♦Disadvantage:

■ Limited priority inversion can occur (higher priority activity may

have to wait for a lower-priority activity to complete)

■ Can be circumvented but at the expense of application-level

complexity

♦ ♦Advantages: Advantages:

■ ■ Eliminates concurrency conflicts for all passive objects

Eliminates concurrency conflicts for all passive objects encapsulated by active objects encapsulated by active objects

■ ■ No explicit synchronization code required

No explicit synchronization code required

■ ■ Low

Low-

  • overhead context switching (RTC implies that stack does
  • verhead context switching (RTC implies that stack does

not need to be preserved) not need to be preserved)

♦ ♦Disadvantage: Disadvantage:

■ ■ Limited priority inversion can occur (higher priority activity m

Limited priority inversion can occur (higher priority activity may ay have to wait for a lower have to wait for a lower-

  • priority activity to complete)

priority activity to complete)

■ ■ Can be circumvented but at the expense of application

Can be circumvented but at the expense of application-

  • level

level complexity complexity

slide-52
SLIDE 52

52

Example: Active Objects Example: Active Objects

♦Active object ≠ OS thread

■ two-tier scheduling scheme ■ event priorities vs thread priorities

♦ ♦Active object Active object ≠ ≠ OS thread OS thread

■ ■ two

two-

  • tier scheduling scheme

tier scheduling scheme

■ ■ event priorities vs thread priorities

event priorities vs thread priorities

OSProcess

OSThread1

Operating System Operating System (schedules process and threads) (schedules process and threads)

Active Active

  • bject
  • bject

scheduler scheduler

OSThreadN

Heavyweight general- purpose multitasking Heavyweight Heavyweight general general-

  • purpose

purpose multitasking multitasking

Active Active

  • bject
  • bject

scheduler scheduler

...

Lightweight specialized multitasking Lightweight Lightweight specialized specialized multitasking multitasking

slide-53
SLIDE 53

53

UML Concurrency Model and RT Systems UML Concurrency Model and RT Systems

♦Active objects are the major concurrency mechanism of UML

■ automatically resolve certain concurrency conflicts

♦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 scheduling methods, etc.)?

■ No clear way of exploiting real-time analyses methods (e.g.,

schedulability analysis)

♦ ♦Active objects are the major concurrency mechanism of Active objects are the major concurrency mechanism of UML UML

■ ■ automatically resolve certain concurrency conflicts

automatically resolve certain concurrency conflicts

♦ ♦However... However...

■ ■ The priority inversion inherent in RTC may be unacceptable in

The priority inversion inherent in RTC may be unacceptable in some cases some cases

■ ■ How does this map to concurrency mechanisms that are used

How does this map to concurrency mechanisms that are used in the real in the real-

  • time domain (processes, threads, semaphores,

time domain (processes, threads, semaphores, real real-

  • time scheduling methods, etc.)?

time scheduling methods, etc.)?

■ ■ No clear way of exploiting real

No clear way of exploiting real-

  • time analyses methods (e.g.,

time analyses methods (e.g., schedulability analysis) schedulability analysis)

slide-54
SLIDE 54

54

Scheduling in UML Scheduling in UML

♦Scheduling approach undefined

■ Hints of event-based priorities (versus thread-based) ■ Timing events allow realization of time-triggered systems

♦The actual scheduling policy is unspecified

■ A semantic variation point ■ Can be customized to suit application requirements

♦ ♦Scheduling approach undefined Scheduling approach undefined

■ ■ Hints of event

Hints of event-

  • based priorities (versus thread

based priorities (versus thread-

  • based)

based)

■ ■ Timing events allow realization of time

Timing events allow realization of time-

  • triggered systems

triggered systems

♦ ♦The actual scheduling policy is unspecified The actual scheduling policy is unspecified

■ ■ A

A semantic variation point semantic variation point

■ ■ Can be customized to suit application requirements

Can be customized to suit application requirements

slide-55
SLIDE 55

55

The Model of Time in UML The Model of Time in UML

♦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

modeling distributed systems)

♦Related concepts:

■ Time events: generated by the occurrence of a specific instant ■ Assumes some kind of run-time Timing Service

♦ ♦Unbiased and uncommitted (i.e., it does not exist): Unbiased and uncommitted (i.e., it does not exist):

■ ■ Time data type declared but not defined (could be either

Time data type declared but not defined (could be either continuous or discrete) continuous or discrete)

■ ■ No built

No built-

  • in assumptions about global time source (open to

in assumptions about global time source (open to modeling distributed systems) modeling distributed systems)

♦ ♦Related concepts: Related concepts:

■ ■ Time events: generated by the occurrence of a specific instant

Time events: generated by the occurrence of a specific instant

■ ■ Assumes some kind of run

Assumes some kind of run-

  • time Timing Service

time Timing Service

slide-56
SLIDE 56

56

:GUI :Scheduler :Scheduler

reservations reservations

:Planner :Planner

update update

Component and Deployment Diagrams Component and Deployment Diagrams

♦Implementation focus ♦ ♦Implementation focus Implementation focus

Component Component Node Node

Generally not sophisticated enough for complex real-time system needs Generally not sophisticated enough for complex real-time system needs

slide-57
SLIDE 57

57

Implementation Diagrams and RT Systems Implementation Diagrams and RT Systems

♦Probably the weakest part of UML ♦Not sophisticated enough to capture the various complex aspects of deployment common to real-time systems

■ deferred mapping of software to hardware ■ mapping of software to software

♦No standard way to describe the quantitative requirements/characteristics of hardware and software (e.g., scheduling discipline) ♦….. ♦ ♦Probably the weakest part of UML Probably the weakest part of UML ♦ ♦Not sophisticated enough to capture the various complex Not sophisticated enough to capture the various complex aspects of deployment common to real aspects of deployment common to real-

  • time systems

time systems

■ ■ deferred mapping of software to hardware

deferred mapping of software to hardware

■ ■ mapping of software to software

mapping of software to software

♦ ♦No standard way to describe the quantitative No standard way to describe the quantitative requirements/characteristics of hardware and software requirements/characteristics of hardware and software (e.g., scheduling discipline) (e.g., scheduling discipline) ♦ ♦….. …..

slide-58
SLIDE 58

58

UML Summary UML Summary

♦An industry standard for analysis and design of object-

  • riented systems

■ based on extensive experience and best practices ■ gaining rapid acceptance (training, tools, books)

♦Comprises:

■ set of modeling concepts ■ a standard graphical notation

♦Represented through 8 different diagram types

■ class, state machine, collaboration, use case, sequence,

activity, component, deployment

♦ ♦An industry standard for analysis and design of object An industry standard for analysis and design of object-

  • riented systems
  • riented systems

■ ■ based on extensive experience and best practices

based on extensive experience and best practices

■ ■ gaining rapid acceptance (training, tools, books)

gaining rapid acceptance (training, tools, books)

♦ ♦Comprises: Comprises:

■ ■ set of modeling concepts

set of modeling concepts

■ ■ a standard graphical notation

a standard graphical notation

♦ ♦Represented through 8 different diagram types Represented through 8 different diagram types

■ ■ class, state machine, collaboration, use case, sequence,

class, state machine, collaboration, use case, sequence, activity, component, deployment activity, component, deployment

slide-59
SLIDE 59

59

UML and RT Systems Summary UML and RT Systems Summary

♦Using UML for real-time systems automatically brings the benefits of the object paradigm

■ structural focus, inheritance, strong encapsulation,

polymorphism,…

♦However, there are many open questions

■ best ways of using UML in the real-time domain ■ missing or non-standard concepts ■ ability to create predictive models for real time

♦ ♦Using UML for real Using UML for real-

  • time systems automatically brings the

time systems automatically brings the benefits of the object paradigm benefits of the object paradigm

■ ■ structural focus, inheritance, strong encapsulation,

structural focus, inheritance, strong encapsulation, polymorphism,… polymorphism,…

♦ ♦However, there are many open questions However, there are many open questions

■ ■ best ways of using UML in the real

best ways of using UML in the real-

  • time domain

time domain

■ ■ missing or non

missing or non-

  • standard concepts

standard concepts

■ ■ ability to create predictive models for real time

ability to create predictive models for real time

slide-60
SLIDE 60

60

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials ■ Essentials of the Object Paradigm

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

■ ■ Essentials of the Object Paradigm

Essentials of the Object Paradigm

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-61
SLIDE 61

61

Semantic Variation in UML Semantic Variation in UML

♦Semantic aspects that are:

■ undefined (e.g., scheduling discipline), or ■ intentionally ambiguous (multiple, mutually-exclusive,

interpretations)

♦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 choices must be strictly limited ♦ ♦Semantic aspects that are: Semantic aspects that are:

■ ■ undefined (e.g., scheduling discipline), or

undefined (e.g., scheduling discipline), or

■ ■ intentionally ambiguous (multiple, mutually

intentionally ambiguous (multiple, mutually-

  • exclusive,

exclusive, interpretations) interpretations)

♦ ♦Why? Why?

■ ■ Different domains require different specializations

Different domains require different specializations

■ ■ The applicability and usefulness of UML would have been

The applicability and usefulness of UML would have been severely constrained if it could not support such diversity severely constrained if it could not support such diversity

♦ ♦The scope and semantic impact of semantic variation The scope and semantic impact of semantic variation choices must be strictly limited choices must be strictly limited

slide-62
SLIDE 62

62

Specialization of UML Specialization of UML

♦Avoiding the PL/I syndrome (“language bloat”)

■ UML standard as a basis for a “family of languages”

♦ ♦Avoiding the PL/I syndrome (“language bloat”) Avoiding the PL/I syndrome (“language bloat”)

■ ■ UML standard as a basis for a “family of languages”

UML standard as a basis for a “family of languages”

UML Standard 1.4 UML Standard 1.4 UML Standard 1.4 …..etc. Real-Time UML Real Real-

  • Time UML

Time UML UML for eCommerce UML for UML for eCommerce eCommerce

Variations produced using built-in extensibility mechanisms: stereotypes, tagged values, constraints Variations produced using built-in extensibility mechanisms: stereotypes, tagged values, constraints

slide-63
SLIDE 63

63

How Do We Specialize UML? How Do We Specialize UML?

♦Typically used to capture semantics that cannot be specified using UML itself ♦ ♦Typically used to capture semantics that cannot be Typically used to capture semantics that cannot be specified using UML itself specified using UML itself

Specialization through regular inheritance Specialization through regular inheritance

But, how can we specify a clock? But, how can we specify a clock? Semantics: an active counter whose value changes synchronously with the progress of physical time Semantics: an active counter whose value changes synchronously with the progress of physical time

Integer Integer Integer Counter Counter Counter

ResetCounter() ResetCounter ResetCounter() ()

slide-64
SLIDE 64

64

Stereotyping UML Concepts Stereotyping UML Concepts

♦Example: a “clock” stereotype based on the generic UML Class concept ♦ ♦Example: a “clock” stereotype based on the generic UML Example: a “clock” stereotype based on the generic UML Class concept Class concept

Integer Integer Integer MyTimePiece MyTimePiece MyTimePiece

SetTime() SetTime SetTime() () «clock» Semantics: an active counter whose value changes synchronously with the progress of physical time Semantics: an active counter whose value changes synchronously with the progress of physical time

slide-65
SLIDE 65

65

UML Profiles UML Profiles

♦A package of related specializations of general UML concepts that capture domain-specific variations and usage patterns

➪ A domain-specific interpretation of UML

♦Fully conformant with the UML standard

■ additional semantic constraints cannot contradict the general

UML semantics

■ within the “semantic envelope” defined by the standard

♦ ♦A package of related specializations of general UML A package of related specializations of general UML concepts that capture domain concepts that capture domain-

  • specific variations and

specific variations and usage patterns usage patterns

➪ ➪ A domain

A domain-

  • specific interpretation of UML

specific interpretation of UML

♦ ♦Fully conformant with the UML standard Fully conformant with the UML standard

■ ■ additional semantic constraints cannot contradict the general

additional semantic constraints cannot contradict the general UML semantics UML semantics

■ ■ within the “semantic envelope” defined by the standard

within the “semantic envelope” defined by the standard

Standard UML Semantics Standard UML Semantics Standard UML Semantics Profile X Profile X Profile X Profile Y Profile Y Profile Y

slide-66
SLIDE 66

66

UML Extensibility and RT Systems UML Extensibility and RT Systems

♦The extensibility mechanisms of UML provide an excellent opportunity to fill in the missing bits for real-time applications ♦If we can define a standard set of extensions (“real-time profile”) then these could provide a common facility for real-time UML modelers and tool builders ♦ ♦The extensibility mechanisms of UML provide an The extensibility mechanisms of UML provide an excellent opportunity to fill in the missing bits for real excellent opportunity to fill in the missing bits for real-

  • time

time applications applications ♦ ♦If we can define a standard set of extensions (“real If we can define a standard set of extensions (“real-

  • time

time profile”) then these could provide a common facility for profile”) then these could provide a common facility for real real-

  • time UML modelers and tool builders

time UML modelers and tool builders

slide-67
SLIDE 67

67

Real Real-

  • Time A&D WG (1 of 2)

Time A&D WG (1 of 2)

♦Bridges two domains: modeling and real-time ♦ ♦Bridges two domains: modeling and real Bridges two domains: modeling and real-

  • time

time

Real-Time SIG

RT RT-

  • AD WG

AD WG

Analysis & Design PTF

slide-68
SLIDE 68

68

Real Real-

  • Time A&D WG (2 of 2)

Time A&D WG (2 of 2)

♦Mission:

to investigate and issue requests (RFPs) for standard ways and means to apply UML to real-time problems

♦Three principal areas of investigation:

■ Time-related modeling ■ General quality of service modeling

(e.g., availability, reliability, security,…)

■ Real-time system architecture modeling

♦Status:

■ first RFP issued (April 1999) ■ second RFP drafted but not submitted

♦ ♦Mission: Mission:

to investigate and issue requests ( to investigate and issue requests (RFPs RFPs) for standard ways ) for standard ways and means to apply UML to real and means to apply UML to real-

  • time problems

time problems

♦ ♦Three principal areas of investigation: Three principal areas of investigation:

■ ■ Time

Time-

  • related modeling

related modeling

■ ■ General quality of service modeling

General quality of service modeling (e.g., availability, reliability, security,…) (e.g., availability, reliability, security,…)

■ ■ Real

Real-

  • time system architecture modeling

time system architecture modeling

♦ ♦Status: Status:

■ ■ first RFP issued (April 1999)

first RFP issued (April 1999)

■ ■ second RFP drafted but not submitted

second RFP drafted but not submitted

slide-69
SLIDE 69

69

The Real The Real-

  • Time UML RFP

Time UML RFP

♦ “UML profile for scheduling performance and time”

■ First in a series of real-time specific RFPs (ad/99-03-13) ■ Initial proposal submitted in August 2000 (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

♦ ♦ “ “UML profile for scheduling performance and time” UML profile for scheduling performance and time”

■ ■ First in a series of real

First in a series of real-

  • time specific

time specific RFPs RFPs (ad/99 (ad/99-

  • 03

03-

  • 13)

13)

■ ■ Initial proposal submitted in August 2000 (ad/2000

Initial proposal submitted in August 2000 (ad/2000-

  • 08

08-

  • 04)

04)

■ ■ Approved by the Analysis & Design Task Force and by the OMG

Approved by the Analysis & Design Task Force and by the OMG Architecture Board Sept. 2001 (final vote pending) Architecture Board Sept. 2001 (final vote pending)

♦ ♦ Standard methods for UML modeling of: Standard methods for UML modeling of:

■ ■ Physical time

Physical time

■ ■ Timing specifications

Timing specifications

■ ■ Timing services and mechanisms

Timing services and mechanisms

■ ■ Modeling resources (logical and physical)

Modeling resources (logical and physical)

■ ■ Concurrency and scheduling

Concurrency and scheduling

■ ■ Software and hardware infrastructure and their mapping

Software and hardware infrastructure and their mapping

■ ■ ..including specific notations for the above where necessary

..including specific notations for the above where necessary

slide-70
SLIDE 70

70

Important Caveat Important Caveat

♦The RFP does not ask for new real-time concepts or methods ♦Instead, the intent is to support existing and future modeling techniques and analysis methods in the context

  • f UML

⇒ response should not be biased towards any particular

technique or method

♦ ♦The RFP does The RFP does not not ask for new real ask for new real-

  • time concepts or

time concepts or methods methods ♦ ♦Instead, the intent is to support existing and future Instead, the intent is to support existing and future modeling techniques and analysis methods in the context modeling techniques and analysis methods in the context

  • f UML
  • f UML

⇒ ⇒ response should not be biased towards any particular

response should not be biased towards any particular technique or method technique or method

slide-71
SLIDE 71

71

Response to the RFP Response to the RFP

♦ Just one submission throughout ♦ Consortium team:

■ ARTiSAN (UML tool vendor) ■ I-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)

♦ In consultation with many of the top real-time system experts (toolbuilders, analysis technique experts, academics)

■ Prof. Murray Woodside and Prof. Dorina Petriu (Carleton U.) –

performance analysis profile

♦ ♦ Just one submission throughout Just one submission throughout ♦ ♦ Consortium team: Consortium team:

■ ■ ARTiSAN

ARTiSAN (UML tool vendor) (UML tool vendor)

■ ■ I

I-

  • Logix

Logix (UML tool vendor) (UML tool vendor)

■ ■ Rational (UML tool vendor)

Rational (UML tool vendor) -

  • lead

lead

■ ■ Telelogic

Telelogic (UML tool vendor) (UML tool vendor)

■ ■ TimeSys

TimeSys (RT tool and technology vendor) (RT tool and technology vendor)

■ ■ Tri

Tri-

  • Pacific Software (RT tool vendor)

Pacific Software (RT tool vendor)

♦ ♦ In consultation with many of the top real In consultation with many of the top real-

  • time system experts

time system experts ( (toolbuilders toolbuilders, analysis technique experts, academics) , analysis technique experts, academics)

■ ■ Prof. Murray Woodside and Prof.

  • Prof. Murray Woodside and Prof. Dorina Petriu

Dorina Petriu (Carleton U.) (Carleton U.) – – performance analysis profile performance analysis profile

slide-72
SLIDE 72

72

RT Profile: Guiding Principles RT Profile: Guiding Principles

♦ Ability to specify quantitative information directly in UML 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

♦ ♦ Ability to specify quantitative information directly in UML mode Ability to specify quantitative information directly in UML models ls

■ ■ key to quantitative analysis and predictive modeling

key to quantitative analysis and predictive modeling

♦ ♦ Flexibility: Flexibility:

■ ■ users can model their RT systems using modeling approaches and

users can model their RT systems using modeling approaches and styles of their own choosing styles of their own choosing

■ ■ open to existing and new analysis techniques

  • pen to existing and new analysis techniques

♦ ♦ Facilitate the use of analysis methods Facilitate the use of analysis methods

■ ■ eliminate the need for a deep understanding of analysis methods

eliminate the need for a deep understanding of analysis methods

■ ■ as much as possible, automate the generation of analysis models

as much as possible, automate the generation of analysis models and and the analysis process itself the analysis process itself

slide-73
SLIDE 73

73

Quantitative Methods for RT Systems 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?

♦ ♦ Once we have included QoS information in our models, we can Once we have included QoS information in our models, we can use use quantitative methods quantitative methods to: to:

■ ■ predict system characteristics (detect problems early)

predict system characteristics (detect problems early)

■ ■ analyze existing system

analyze existing system

■ ■ synthesize elements of the model

synthesize elements of the model

♦ ♦ Methods considered for the profile: Methods considered for the profile:

■ ■ Schedulability analysis

Schedulability analysis will the system meet all of its deadlines? will the system meet all of its deadlines?

■ ■ Performance analysis

Performance analysis based on queueing theory based on queueing theory what kind of response will the system have under load? what kind of response will the system have under load?

slide-74
SLIDE 74

74

Issues with Quantitative Methods Issues with Quantitative Methods

♦Require uncommon and highly-specialized skills ♦Software is notoriously difficult to model

■ highly non-linear (detail often matters) ■ models are frequently severely inaccurate and not trustworthy ■ typical modeling process is highly manual:

♦ ♦Require uncommon and highly Require uncommon and highly-

  • specialized skills

specialized skills ♦ ♦Software is notoriously difficult to model Software is notoriously difficult to model

■ ■ highly non

highly non-

  • linear (detail often matters)

linear (detail often matters)

■ ■ models are frequently severely inaccurate and not trustworthy

models are frequently severely inaccurate and not trustworthy

■ ■ typical modeling process is highly manual:

typical modeling process is highly manual:

Actual Actual System System System System Model Model

analysis results analysis analysis results results measurements measurements measurements

+ +

slide-75
SLIDE 75

75

Desired Development Model Desired Development Model

♦Seamless integration of technologies and tools based on standards for real-time modeling ♦ ♦Seamless integration of technologies and tools based on Seamless integration of technologies and tools based on standards for real standards for real-

  • time modeling

time modeling

Model Editing Model Editing Tool Tool

5 5 3.1 3.1 4 4

Model Analysis Model Analysis Tool Tool

Automated model conversion Automated Automated model conversion model conversion Inverse model conversion Inverse Inverse model conversion model conversion

slide-76
SLIDE 76

76

Structure: Domain Model and Extensions Structure: Domain Model and Extensions

General Resource Model Resource Client etc. Specialized Analysis Domain Model Analysis Resource Analysis Client etc. «import»

Domain model Domain model

«profile» RTresourceModeling «profile» ADprofile «stereotype» ADresource «import» «metaclass» Class «metaclass» Object «stereotype» etc.

Profile Packages (normative) Profile Packages (normative)

slide-77
SLIDE 77

77 Analysis Models Infrastructure Models General Resource Modeling Framework

UML Real UML Real-

  • Time Profile Structure

Time Profile Structure

«modelLibrary» RealTimeCORBAModel «profile» RTresourceModeling «profile» RTconcurrencyModeling «import» «profile» RSAprofile «import» «import» «profile» RTtimeModeling «profile» PAprofile «import» «profile» SAProfile «import» «import»

slide-78
SLIDE 78

78

Quality of Service Concepts Quality of Service Concepts

♦Quality of Service (QoS):

a specification (usually quantitative) of how a particular service is (to be) performed

■ e.g. throughput, capacity, response time

♦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

♦ ♦Quality of Service (QoS): Quality of Service (QoS):

a specification (usually quantitative) of how a particular servi a specification (usually quantitative) of how a particular service ce is (to be) performed is (to be) performed

■ ■ e.g. throughput, capacity, response time

e.g. throughput, capacity, response time

♦ ♦The specification of a model element can include: The specification of a model element can include:

■ ■ offered QoS:

  • ffered QoS: the QoS that it provides to its clients

the QoS that it provides to its clients

■ ■ required QoS:

required QoS: the QoS it requires from other components to the QoS it requires from other components to support its QoS obligations support its QoS obligations

slide-79
SLIDE 79

79

Resources and Quality of Service Resources and Quality of Service

♦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

  • f the service or resource

♦ ♦Resource: Resource:

an element whose service capacity is limited, directly or an element whose service capacity is limited, directly or indirectly, by the finite capacities of the underlying physical indirectly, by the finite capacities of the underlying physical computing environment computing environment

♦ ♦These capacities are expressed through QoS attributes These capacities are expressed through QoS attributes

  • f the service or resource
  • f the service or resource

Client Client Client

Resource Usage Resource Usage

S1 S1 S1 S1 S1 S1

Resource Resource Resource

{RequiredQoS ≤ ≤ ≤ ≤ OfferedQoS} {RequiredQoS ≤ ≤ ≤ ≤ OfferedQoS} RequiredQoS RequiredQoS OfferedQoS OfferedQoS

slide-80
SLIDE 80

80

Simple Example Simple Example

♦ Concurrent tasks accessing a monitor with known response time characteristics ♦ ♦ Concurrent tasks accessing a monitor with known response time Concurrent tasks accessing a monitor with known response time characteristics characteristics

access ( )

Client2

access ( )

Client1

{Deadline = 3 ms}

Required QoS Required QoS

{Deadline = 5 ms}

myMonitor

Offered QoS Offered QoS

{MaxExecutionTime = 4 ms}

slide-81
SLIDE 81

81

Instance Instance-

  • vs Class

vs Class-

  • Based Models

Based Models

♦ Practically all analysis methods are concerned with instance- based models ♦ However, it is often useful to associate QoS characteristics with classes

■ Used to define default values that may be overridden for specific

instances

♦ Need to apply a stereotype to both spec elements and instance elements ♦ ♦ Practically all analysis methods are concerned with instance Practically all analysis methods are concerned with instance-

  • based models

based models ♦ ♦ However, it is often useful to associate QoS characteristics wit However, it is often useful to associate QoS characteristics with h classes classes

■ ■ Used to define default values that may be overridden for specifi

Used to define default values that may be overridden for specific c instances instances

♦ ♦ Need to apply a stereotype to both spec elements and instance Need to apply a stereotype to both spec elements and instance elements elements

N1:Node N1:Node N3:Node N3:Node N4:Node N4:Node N2:Node N2:Node Node Node

1 1

slide-82
SLIDE 82

82

The General Resource Model The General Resource Model

CoreResourceModel ResourceUsageModel DynamicUsageModel (from ResourceUsageModel) StaticUsageModel (from ResourceUsageModel) CausalityModel ResourceTypes ResourceManagement RealizationModel

slide-83
SLIDE 83

83

Core Resource Model Core Resource Model

ResourceService QoScharacteristic 0..n 0..n 0..n 0..n ResourceServ iceInstance 1 0..n +type 1 +instance 0..n Resource 1..n +offeredService 1..n l 0..n 0..n 0..n 0..n / QoSvalue 0..n 0..n +offeredQoS 0..n 0..n 1 0..n +type 1 +instance 0..n ResourceInstance 1..n 1..n 1..n 0..n +type 1..n +instance 0..n 0..n 0..n +offeredQoS 0..n 0..n / Descriptor Instance 1..n 0..n +type 1..n 0..n

♦NB: This is a model of the domain concepts

■ (i.e., it is not a UML metamodel)

♦ ♦NB: This is a model of the domain concepts NB: This is a model of the domain concepts

■ ■ (i.e., it is not a UML metamodel)

(i.e., it is not a UML metamodel)

slide-84
SLIDE 84

84

Basic Resource Usage Model Basic Resource Usage Model

StaticUsage DynamicUsage UsageDemand ResourceServiceInstance (from CoreResourceModel) ResourceUsage 1 0..1 1 +workload 0..1 0..n +usedServices 0..n AnalysisContext 1 1..n 1 1..n 1 1..n 1 1..n ResourceInstance (from CoreResourceModel) 1..n 1..n 1..n 0..n +usedResources 1..n 0..n 0..n 1..n 0..n 1..n EventOccurence

(from Cau s ali tyModel )

slide-85
SLIDE 85

85

Basic Causality Loop Basic Causality Loop

♦Used in modeling dynamic scenarios ♦ ♦Used in modeling dynamic scenarios Used in modeling dynamic scenarios

0..1 1 +effect 0..1 +cause 1 Stimulus 1..n 1 +effect 1..n +cause 1 Scenario 0..n 1 +effect 0..n +cause 1 0..n 1 +effect 0..n +cause 1 Instance (from CoreResourceModel) 0..1 0..n +receiver 0..1 0..n 0..n 1..n +methodExecution 0..n +executionHost 1..n EventOccurence StimulusReception StimulusGeneration

slide-86
SLIDE 86

86

Dynamic Usage Model Dynamic Usage Model

+requiredQoS DynamicUsage (from ResourceUsageModel) QoSvalue (from CoreResourceModel) ResourceInstance (from CoreResourceModel) ResourceServiceInstance (from CoreResourceModel) 1..n 1..n 0..n 0..n 0..n +offeredQoS 0..n Scenario (from CausalityModel) 1..n 1..n +usedResources 1..n 1..n / 1..n 1..n +usedServices 1..n 1..n / ActionExecution 0..n 0..n 0..n 0..n 1..n +step 1..n 0..n 0..n 0..n +predecessor +successor 0..n {ordered}

slide-87
SLIDE 87

87

Static Usage Model Static Usage Model

StaticUsage (from ResourceUsageModel) ResourceInstance (from CoreResourceModel) Client 1..n 1..n +usedResources 1..n 1..n QoSvalue (from CoreResourceModel) 0..n 0..n 0..n +offeredQoS 0..n / 0..n 1..n 0..n +requiredQoS 1..n QoScharacteristic (from CoreResourceModel) 0..n 1 +instance 0..n +type 1 Instance

(from CoreRes

  • urceModel)
slide-88
SLIDE 88

88

Resource Categorizations Resource Categorizations

ActiveResource PassiveResource UnprotectedResource protectionKind activ enessKind ResourceInstance (from CoreResourceModel) ProtectedResource CommunicationResource Processor Device purposeKind

slide-89
SLIDE 89

89

Exclusive Use Resources and Actions Exclusive Use Resources and Actions

ActionExecution (from DynamicUsageModel) ResourceServiceInstance (from CoreResourceModel) AcquireService isBlocking : Boolean ReleaseService ExclusiveService 0..n 1 0..n 1 / 0..n 1 0..n 1 / AccessControlPolicy 1 0..n 1 0..n ProtectedResource 1..n 1..n / 0..n 0..1 / 0..1 0..n

slide-90
SLIDE 90

90

Resource Management Model Resource Management Model

Instance (from CoreResourceModel) ResourceInstance (from CoreResourceModel) ResourceBroker 1..n 0..n 1..n 0..n AccessControlPolicy (from ResourceTypes) 1..n 1 1..n ResourceManager 1..n 0..n +managedResource 1..n 0..n ResourceControlPolicy 1 0..n 1 0..n

slide-91
SLIDE 91

91

0..n 0..n 0..n 0..n Resource Resource Service Service Resource Resource

Stereotype UML base concepts Tags GRMresource Classifier, Instance N/A GRMresSrvc BehavioralFeature GRMexTime «GRMresource»

aPool : BufferPool

«GRMresource»

aPool aPool : : BufferPool BufferPool

Mapping to UML Extensions Mapping to UML Extensions

♦Elements of the general resource model are represented as stereotypes (with tags) of base UML concepts: ♦ ♦Elements of the general resource model are represented Elements of the general resource model are represented as stereotypes (with tags) of base UML concepts: as stereotypes (with tags) of base UML concepts:

«GRMresource»

BufferPool

«GRMresource»

BufferPool BufferPool

«GRMresSrvc» GetBuffer() {GRMexTime = 5} «GRMresSrvc» GetBuffer GetBuffer() () {GRMexTime = 5}

slide-92
SLIDE 92

92

master : Master poller : Poller d : DBaseServer cs : CommServer dBadmin : Admin

  • 1. read( )
  • 2. register( )

sort( ) invoke( )

Example System Example System

Period = 100 ms WCET = 20 ms Period = 100 ms WCET = 20 ms Period = 150 ms WCET = 40 ms Period = 150 ms WCET = 40 ms Period = 350 ms WCET = 100 ms Period = 350 ms WCET = 100 ms WCET = 2 ms WCET = 2 ms WCET = 20 ms WCET = 20 ms WCET = 10 ms WCET = 10 ms WCET = 10 ms WCET = 10 ms

♦Periodic concurrent tasks sharing resources ♦ ♦Periodic concurrent tasks sharing resources Periodic concurrent tasks sharing resources

slide-93
SLIDE 93

93

Standard Stereotypes Standard Stereotypes

♦To allow an analysis tool to extract the necessary QoS information, we define a set of standard stereotypes and related tags* ♦ ♦To allow an analysis tool to extract the necessary QoS To allow an analysis tool to extract the necessary QoS information, we define a set of standard stereotypes and information, we define a set of standard stereotypes and related tags* related tags*

Stereotype UML base concepts Tags GRMclient Classifier, Instance GRMperiod, GRMwcet GRMprotResource Classifier, Instance N/A GRMresService BehavioralFeature GRMwcet

Tag Tag Type GRMperiod RTtimeString GRMwcet RTtimeString

* The stereotypes and tags have been simplified for this presentation * The stereotypes and tags have been simplified for this present * The stereotypes and tags have been simplified for this presentation ation

slide-94
SLIDE 94

94

master : Master poller : Poller d : DBaseServer cs : CommServer dBadmin : Admin

  • 1. read( )
  • 2. register( )

sort( ) invoke( )

Example: QoS Annotations Example: QoS Annotations

♦Using the standard stereotypes... ♦ ♦Using the standard stereotypes... Using the standard stereotypes...

«GRMclient» {GRMperiod = 100 ms} {GRMwcet = 20 ms} «GRMclient» «GRMclient» {GRMperiod = 150 ms} {GRMwcet = 40 ms} {GRMperiod = 350 ms} {GRMwcet = 100 ms} «GRMprotResource» «GRMprotResource»

slide-95
SLIDE 95

95

Example: Class Diagram Example: Class Diagram

Master Admin Poller CommServer invoke() register()

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

«GRMclient» «GRMclient» «GRMclient» DBaseServer

1 1

read () sort () «GRMserv» {GRMwcet = 10ms} «GRMserv» {GRMwcet = 20ms} «GRMserv» {GRMwcet = 10ms} «GRMserv» {GRMwcet = 20ms} «GRMprotResource» «GRMprotResource»

♦QoS annotations can be added to classes as well ♦ ♦QoS annotations can be added to classes as well QoS annotations can be added to classes as well

slide-96
SLIDE 96

96

Example: Model Analysis Example: Model Analysis

« «GRManalysisContext GRManalysisContext» »

{ {isSchedulable isSchedulable= .$?} = .$?} Schedulability Schedulability Analyzer Analyzer (RMA) (RMA)

« «GRManalysisContext GRManalysisContext» »

{ {isSchedulable isSchedulable= = True True} } Result: a new model with analysis variable values set Result: a new model with analysis variable values set May include additional tool-specific results encased in UML Notes May include additional tool-specific results encased in UML Notes

slide-97
SLIDE 97

97

General Time Model General Time Model

TimeModel TimedEvents TimingMechanisms TimingServices

slide-98
SLIDE 98

98

Physical and Measured Time Physical and Measured Time

{ordered}

Physical Time Duration PhysicalInstant n 1 n +start 1 n 1 n +end 1 n Clock (from TimingMechanisms) TimeInterv al 0..n 0..n +measurement 0..n 0..n TimeValue kind : {discrete, dense} 0..n n +measurement 0..n n 1 n +s tart 1 n 1 n +end 1 n 1 0..n +referenceClock 1 0..n

slide-99
SLIDE 99

99

Timing Mechanisms Model Timing Mechanisms Model

ResourceInstance (from CoreResourceModel) Timeout (from TimedEvents) Timer isPeriodic : Boolean 1 0..n 1 +generatedTimeouts 0..n ClockInterrupt (from TimedEvents) TimeInterval (from TimeModel) Clock 1 0..n +offset 1 0..n 1 0..n +accuracy 1 0..n 0..n 1 +generatedInterrupts 0..n 1 TimeValue (from TimeModel) TimingMechanism stability drift skew set(time : TimeValue) get() : TimeValue reset() start() pause() 1 0..n +resolution 1 0..n 0..n 1 0..n +referenceClock 1 1 0..n +currentValue 1 0..n 1 0..n +maximalValue 1 0..n TimeValue (from TimeModel) 1 0..n +duration 1 0..n TimedEvent

(from TimedEvents)

1..n +timestamp 1..n 1 +origin 1

slide-100
SLIDE 100

100

Example Timing Stereotype Example Timing Stereotype

State Transition SubactivityState ActionState ActionSequence Method Stimulus Message ActionExecution

RTstart RTend RTduration

Action

«RTaction»

Tags Base Class Stereotype

TimedAction::duration TimedAction::end TimedAction::start

Domain Name

RTduration RTend RTstart

Tag

[0..1] [0..1] [0..1]

Multiplicity

RTtimeValue RTtimeValue RTtimeValue

Tag Type

slide-101
SLIDE 101

101

Timed Stimuli Timed Stimuli

These two associations are derived from the general association between EventOccurrence and Stimulus

Stimulus (from CausalityModel) Timeout ClockInterrupt StimulusGeneration (from CausalityModel) 1 1..n +cause 1 +effect 1..n 1 1..n +cause 1 1..n / 1 0..n +cause 1 0..n / TimedStimulus TimeValue (from TimeModel) 1..n 0..n +start 1..n 0..n 0..n 0..n +time 0..n 0..n 0..n 0..n +end 0..n 0..n

slide-102
SLIDE 102

102

Timed Events and Timed Actions Timed Events and Timed Actions

Delay EventOccurence (from CausalityModel) TimeValue (from TimeModel) TimedEvent 1..n +timestamp 1..n Scenario (from CausalityModel) TimedAction TimeInterval (from TimeModel) 1 0..n +duration 1 0..n 1..n +end 1..n 1..n +start 1..n

slide-103
SLIDE 103

103

Time Annotations Time Annotations

♦In various behavioral diagrams (sequence, activity, state) ♦ ♦In various behavioral diagrams (sequence, activity, state) In various behavioral diagrams (sequence, activity, state)

b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow processSelection initialPlayout initializePlayer sendFrame showFrame terminalPlayout confirm *[$N]

«PAclosedLoad» {PApopulation=$NUsers, PAextDelay=('mean','asgn',20,'ms')}}

«PAcontext»

«PAstep» {PArespTime= ('req','percentile',95,500,'ms')}} «PAstep» {PAdemand= ('est','mean',1,'ms')}} «PAstep» {PAdemand= (('est','mean',15,'ms'), ('est','sigma',10))} «PAstep» {PArep=$N, PAdemand=('est','mean',10,'ms'), PAextOp=('filesys',12),('network',65)} «PAstep» {PAinterval= ('req','percentile',99,30,'ms')}}

May be very sophisticated and express complex May be very sophisticated and express complex time values (instants and durations) including time values (instants and durations) including probability distributions, percentile values, etc. probability distributions, percentile values, etc. (NB: tools can help reduce visual clutter) (NB: tools can help reduce visual clutter) More compact forms are also More compact forms are also possible: possible:

{0 ms} {11 ms} {10.2 ms} {4.7 ms} {2 ms} {1.5 ms} InstanceA : InstanceB : helloMsg ackMsg 2.7 ms

slide-104
SLIDE 104

104

Caller Caller Operator Operator call ack

Notation: Timing Marks and Constraints Notation: Timing Marks and Constraints

♦A timing mark identifies the time of an event occurrence ♦ ♦A A timing mark timing mark identifies the time of an event occurrence identifies the time of an event occurrence

{call. {call.sendTime sendTime() () -

  • ack

ack. .receiveTime receiveTime < 10 sec} < 10 sec} Timing constraint Timing constraint ack ack. .sendTime sendTime() ()

  • On messages:

On messages: sendTime sendTime() () receiveTime receiveTime() ()

  • On action blocks (new):

On action blocks (new): startTime startTime() () endTime endTime() ()

call. call.receiveTime receiveTime() () callHandler callHandler. .startTime startTime() () callHandler callHandler. .endTime endTime() ()

slide-105
SLIDE 105

105

Defined Stereotypes (1 of 3) Defined Stereotypes (1 of 3)

A clock mechanism A clock mechanism RTclockId RTclockId [0..1] [0..1] Instance, Instance, DataType DataType, , Classifier, Classifier, ClassifierRole ClassifierRole… … « «RTclock RTclock» (subclass of » (subclass of « «RTtimingMechanism RTtimingMechanism») ») A time interval A time interval RTintStart RTintStart [0..1] [0..1] RTintEnd RTintEnd [0..1] [0..1] RTintDuration RTintDuration [0..1] [0..1] Instance, Object, Instance, Object, Classifier, Classifier, DataType DataType, , DataValue DataValue « «RTinterval RTinterval» » An event that occurs at a An event that occurs at a known time instant known time instant RTat RTat [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «RTevent RTevent» » A pure delay activity A pure delay activity RTduration RTduration [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «RTdelay RTdelay» » A clock interrupt A clock interrupt RTtimestamp RTtimestamp [0..1] [0..1] Stimulus, Message Stimulus, Message « «RTclkInterrupt RTclkInterrupt» » (subclass of (subclass of « «RTstimulus RTstimulus») ») An action that takes time An action that takes time RTstart RTstart [0..1] [0..1] RTend RTend [0..1] [0..1] RTduration RTduration [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «RTaction RTaction» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-106
SLIDE 106

106

Defined Stereotypes (2 of 3) Defined Stereotypes (2 of 3)

A timed stimulus A timed stimulus RTstart RTstart [0..1] [0..1] RTend RTend [0..1] [0..1] Stimulus, Stimulus, ActionExecution ActionExecution, , Action, Action, ActionSequence ActionSequence, , Method Method « «RTstimulus RTstimulus» » A pause operation on a timing A pause operation on a timing mechanism mechanism Operation Operation « «RTpause RTpause» » An operation that starts a An operation that starts a timing mechanism timing mechanism Operation Operation « «RTstart RTstart» » An operation that sets the An operation that sets the current value of a timing current value of a timing mechanism mechanism RTtimePar RTtimePar [0..1] [0..1] Operation Operation « «RTset RTset» » An operation that resets a An operation that resets a timing mechanism timing mechanism Operation Operation « «RTreset RTreset» » An operation that creates a An operation that creates a new timer new timer RTtimerPar RTtimerPar [0..1] [0..1] Operation Operation « «RTnewTimer RTnewTimer» » An operation that creates a An operation that creates a new clock mechanism new clock mechanism RTstart RTstart [0..1] [0..1] RTend RTend [0..1] [0..1] RTduration RTduration [0..1] [0..1] Operation Operation « «RTnewClock RTnewClock Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-107
SLIDE 107

107

Defined Stereotypes (3 of 3) Defined Stereotypes (3 of 3)

A timer mechanism A timer mechanism RTduration RTduration [0..1] [0..1] RTperiodic RTperiodic [0..1] [0..1] DataValue DataValue, Instance, Object, , Instance, Object, ClassifierRole ClassifierRole, Classifier… , Classifier… « «RTtimer RTtimer» (subclass of » (subclass of « «RTtimingMechanism RTtimingMechanism») ») A timing mechanism A timing mechanism

RTstability RTstability [0..1] [0..1] RTdrift RTdrift [0..1] [0..1] RTskew RTskew [0..1] [0..1] RTmaxValue RTmaxValue [0..1] [0..1] RTorigin RTorigin [0..1] [0..1] RTresolution RTresolution [0..1] [0..1] RTaccuracy RTaccuracy [0..1] [0..1] RTcurrentVal RTcurrentVal [0..1] [0..1] RToffset RToffset [0..1] [0..1] RTrefClk RTrefClk [0..1] [0..1]

DataValue DataValue, Instance, , Instance, Object, Object,ClassifierRole ClassifierRole, , Classifier, Classifier, DataType DataType « «RTtimingMechanism RTtimingMechanism» » A time service A time service Instance, Object, Instance, Object, ClassifierRole ClassifierRole, Classifier , Classifier « «RTtimeService RTtimeService» » A timeout signal or a A timeout signal or a timeout action timeout action RTtimestamp RTtimestamp [0..1] [0..1] Stimulus, Stimulus, ActionExecution ActionExecution, , Action, Action, ActionSequence ActionSequence, , Method Method « «RTtimeout RTtimeout» (subclass » (subclass

  • f «
  • f «RTstimulus

RTstimulus») ») A time value or a time A time value or a time

  • bject
  • bject

RTkind RTkind [0..1] [0..1] RTrefClk RTrefClk [0..1] [0..1] DataValue DataValue, Instance, Object, , Instance, Object, DataType DataType, Classifier , Classifier « «RTtime RTtime» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-108
SLIDE 108

108

Specifying Time Values Specifying Time Values

♦Time values can be represented by a special stereotype

  • f Value («RTtimeValue») in different formats; e.g.

■ 12:04 (time of day) ■ 5.3, ‘ms’ (time interval) ■ 2000/10/27 (date) ■ Wed (day of week) ■ $param, ‘ms’ (parameterized value) ■ ‘poisson’, 5.4, ‘sec’ (time value with a Poisson distribution) ■ ‘histogram’ 0, 0.3 1, 0.4 2, 0.3, 3, ‘ms’

♦ ♦Time values can be represented by a special stereotype Time values can be represented by a special stereotype

  • f Value («
  • f Value («RTtimeValue

RTtimeValue») in different formats; e.g. ») in different formats; e.g.

■ ■ 12:04 (time of day)

12:04 (time of day)

■ ■ 5.3, ‘ms’ (time interval)

5.3, ‘ms’ (time interval)

■ ■ 2000/10/27 (date)

2000/10/27 (date)

■ ■ Wed (day of week)

Wed (day of week)

■ ■ $

$param param, ‘ms’ (parameterized value) , ‘ms’ (parameterized value)

■ ■ ‘

‘poisson’ poisson’, 5.4, ‘sec’ (time value with a Poisson distribution) , 5.4, ‘sec’ (time value with a Poisson distribution)

■ ■ ‘histogram’ 0, 0.3 1, 0.4 2, 0.3, 3, ‘ms’

‘histogram’ 0, 0.3 1, 0.4 2, 0.3, 3, ‘ms’

P=0.3 P=0.3 P=0.4 P=0.4 P=0.3 P=0.3 0 ms 0 ms 1 ms 1 ms 2 ms 2 ms 3 ms 3 ms

slide-109
SLIDE 109

109

Specifying Arrival Patterns Specifying Arrival Patterns

♦Method for specifying standard arrival pattern values

■ Bounded: ‘bounded’, <min-interval>, <max-interval> ■ Bursty: ‘bursty’, <burst-interval> <max.no.events> ■ Irregular: ‘irregular’, <interarrival-time>, [<interarrival-time>]* ■ Periodic: ‘periodic’, <period> [, <max-deviation>] ■ Unbounded: ‘unbounded’, <probability-distribution>

♦Probability distributions supported:

■ Bernoulli, Binomial, Exponential, Gamma, Geometric,

Histogram, Normal, Poisson, Uniform

♦ ♦Method for specifying standard arrival pattern values Method for specifying standard arrival pattern values

■ ■ Bounded:

Bounded: ‘bounded’, <min ‘bounded’, <min-

  • interval>, <max

interval>, <max-

  • interval>

interval>

■ ■ Bursty

Bursty: : ‘ ‘bursty’ bursty’, <burst , <burst-

  • interval> <max.no.events>

interval> <max.no.events>

■ ■ Irregular:

Irregular: ‘irregular’, <interarrival ‘irregular’, <interarrival-

  • time>, [<interarrival

time>, [<interarrival-

  • time>]*

time>]*

■ ■ Periodic:

Periodic: ‘periodic’, <period> [, <max ‘periodic’, <period> [, <max-

  • deviation>]

deviation>]

■ ■ Unbounded:

Unbounded: ‘unbounded’, <probability ‘unbounded’, <probability-

  • distribution>

distribution>

♦ ♦Probability distributions supported: Probability distributions supported:

■ ■ Bernoulli, Binomial, Exponential, Gamma, Geometric,

Bernoulli, Binomial, Exponential, Gamma, Geometric, Histogram, Normal, Poisson, Uniform Histogram, Normal, Poisson, Uniform

slide-110
SLIDE 110

110

General Concurrency Modeling General Concurrency Modeling

SynchronousInvoke AsynchronousInv

  • ke

ImmediateService threading DeferredService Stimulus (from CausalityModel) StimuliQueue 0... 0... 0... 0... Scenario (from CausalityModel) ConcurrentUnit 1..n 1..n 1 1 +main 1 1 / StimulusGeneration (from CausalityModel) MessageAction 1..n 1 +effect 1..n +cause 1 / ActiveResource

(from ResourceTypes)

ResourceServiceInstance (from CoreResourceModel) 1 0..n 1 +methodExecution 0..n / 1..n 1..n / ActionExecution isAtomic : Boolean (from DynamicUsageModel) 1..n +step 1..n ProtectedResource

(from ResourceTypes)

slide-111
SLIDE 111

111

Defined Stereotypes Defined Stereotypes

A synchronous invoke A synchronous invoke Action, Action, ActionExecution ActionExecution « «CRSynch CRSynch» » A stimuli queue A stimuli queue Instance, Object, Class, Instance, Object, Class, ClassifierRole ClassifierRole « «CRmsgQ CRmsgQ» » A concurrent unit concept A concurrent unit concept CRMain CRMain [0..1] [0..1] Node, Component, Node, Component, Artifact, Class, Instance Artifact, Class, Instance « «CRConcurrent CRConcurrent» » An instance of an immediate An instance of an immediate service service {remote, local} [0..1] {remote, local} [0..1] Operation, Reception, Operation, Reception, Message, Stimulus Message, Stimulus « «CRImmediate CRImmediate» » A deferred receive A deferred receive Operation, Reception, Operation, Reception, Message, Stimulus Message, Stimulus « «CRDeferred CRDeferred» » A generalized usage A generalized usage dependency dependency Usage Usage « «CRContains CRContains» » An asynchronous invocation An asynchronous invocation Action, Action, ActionExecution ActionExecution « «CRAsynch CRAsynch» » An action execution An action execution CRAtomic CRAtomic [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «CRAction CRAction» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-112
SLIDE 112

112

Performance Analysis Concepts Performance Analysis Concepts

<<deploys>> ClosedWorkload population externalDelay OpenWorkload

  • ccurrencePattern

PResource utilization schedulingPolicy throughput PProcessingResource processingRate contextSwitchTime priorityRange isPreemptible PerformanceContext 1..n 0..n 1..n 0..n Workload responseTime priority 1..n 1 1..n 1 PStep probabilty repetition delay

  • perations

interval executionTime 0..n 0..n +successor 0..n +predecessor 0..n PScenario hostExecutionDemand responseTime 0..n 0..n +resource 0..n 0..n 0..1 0..n +host 0..1 0..n 1..n 1 1..n 1 1 1..n 1 1..n 1..n 1..n 1 1 +root 1 1 PPassiveResource waitingTime responseTime capacity accessTime {ordered}

slide-113
SLIDE 113

113

Relationship to General Resource Model Relationship to General Resource Model

UsageDemand (from ResourceUsageModel) AnalysisContext (from ResourceUsageModel) PerformanceContext Workload Scenario (from CausalityModel) PPassiveResource waitingTime responseTime capacity accessTime PProcessingResource processingRate contextSwitchTime priorityRange isPreemptible PScenario ActiveResource (from ResourceTypes) PassiveResource (from ResourceTypes) ProtectedResource (from ResourceTypes)

slide-114
SLIDE 114

114

Example: Web Video Application Example: Web Video Application

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

Logical Instance Model

b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow processSelection initialPlayout initializePlayer sendFrame showFrame terminalPlayout confirm *[$N]

Usage Scenario

b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow :ClientWorkstation : WebServerNode : VideoServerNode : Internet

«GRMdeploys» «GRMdeploys» «GRMdeploys»

Engineering Instance Model

slide-115
SLIDE 115

115

Example: Performance Requirements Example: Performance Requirements

■ Estimated video server processing demand per frame = 10 ms ■ Estimated viewer processing demand per frame = 15 ms (dev = 20 ms) ■ Assumed network delay distribution: exponential with mean = 10 ms ■ Measured packets per frame (LAN) = 65 ■ Measured video server file operations per frame = 12 ■ Max. number of concurrent users = $Nusers ■ Average inter-session times = 20 minutes ■ Frames in a video $N ■ Video frame intervval = 30 ms ■ Required confirmation delay: 95% < 500 ms ■ Required interval between frame displays = 99% < 30 ms ■ ■ Estimated video server processing demand per frame = 10 ms

Estimated video server processing demand per frame = 10 ms

■ ■ Estimated viewer processing demand per frame = 15 ms (dev = 20 m

Estimated viewer processing demand per frame = 15 ms (dev = 20 ms) s)

■ ■ Assumed network delay distribution: exponential with mean = 10 m

Assumed network delay distribution: exponential with mean = 10 ms s

■ ■ Measured packets per frame (LAN) = 65

Measured packets per frame (LAN) = 65

■ ■ Measured video server file operations per frame = 12

Measured video server file operations per frame = 12

■ ■ Max. number of concurrent users = $

  • Max. number of concurrent users = $Nusers

Nusers

■ ■ Average inter

Average inter-

  • session times = 20 minutes

session times = 20 minutes

■ ■ Frames in a video $N

Frames in a video $N

■ ■ Video frame

Video frame intervval intervval = 30 ms = 30 ms

■ ■ Required confirmation delay: 95% < 500 ms

Required confirmation delay: 95% < 500 ms

■ ■ Required interval between frame displays = 99% < 30 ms

Required interval between frame displays = 99% < 30 ms

slide-116
SLIDE 116

116 b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow processSelection initialPlayout initializePlayer sendFrame showFrame terminalPlayout confirm *[$N]

«PAclosedLoad» {PApopulation=$NUsers, PAextDelay=('mean','asgn',20,'ms')}}

«PAcontext»

«PAstep» {PArespTime= ('req','percentile',95,500,'ms')}} «PAstep» {PAdemand= ('est','mean',1,'ms')}} «PAstep» {PAdemand= (('est','mean',15,'ms'), ('est','sigma',10))} «PAstep» {PArep=$N, PAdemand=('est','mean',10,'ms'), PAextOp=('filesys',12),('network',65)} «PAstep» {PAinterval= ('req','percentile',99,30,'ms')}}

Example: Annotations for a Scenario Example: Annotations for a Scenario

slide-117
SLIDE 117

117

Example: More Annotations Example: More Annotations

b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow «PAhost» :ClientWorkstation «PAhost» : WebServerNode «PAhost» : VideoServerNode : Internet

«GRMdeploys» «GRMdeploys» «GRMdeploys»

«PAcontext»

{PAschdPolicy=PR, PArate=1, PAutilization=$Util, PActxtSwT=('est','mean',40,'us')}

«PAstep» send frame «PAstep» show frame «PAstep» receive frame vs : VideoServer vp : VideoPlayer vw : VideoWindow

{PAdemand= (('est','mean',15,'ms'), ('est','sigma',10))} {PAdemand=('est','mean',10,'ms'), PAextOp=('filesys',12),('network',65)} {PAinterval= ('req','percentile',99,30,'ms')}}

«PAcontext»

slide-118
SLIDE 118

118

Defined Stereotypes (1 of 2) Defined Stereotypes (1 of 2)

A deferred receive A deferred receive PAutilization PAutilization [0..*] [0..*] PAschdPolicy PAschdPolicy [0..1] [0..1] PArate PArate [0..1] [0..1] PActxtSwT PActxtSwT [0..1] [0..1] PAprioRange PAprioRange [0..1] [0..1] PApreemptible PApreemptible [0..1] [0..1] PAthroughput PAthroughput [0..1] [0..1] Classifier, Node, Classifier, Node, ClassifierRole ClassifierRole, Instance, , Instance, Partition Partition « «PAhost PAhost» » An open workload An open workload PArespTime PArespTime [0..*] [0..*] PApriority PApriority [0..1] [0..1] PAoccurrence PAoccurrence [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «PAopenLoad PAopenLoad» » A performance analysis A performance analysis context context Collaboration, Collaboration, CollaborationInstanceSet CollaborationInstanceSet, , ActivityGraph ActivityGraph « «PAcontext PAcontext» » A closed workload A closed workload PArespTime PArespTime [0..*] [0..*] PApriority PApriority [0..1] [0..1] PApopulation PApopulation [0..1] [0..1] PAextDelay PAextDelay [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «PAclosedLoad PAclosedLoad» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-119
SLIDE 119

119

Defined Stereotypes (2 of 2) Defined Stereotypes (2 of 2)

A step in a scenario A step in a scenario PAdemand PAdemand [0..1] [0..1] PArespTime PArespTime [0..1] [0..1] PAprob PAprob [0..1] [0..1] PArep PArep [0..1] [0..1] PAdelay PAdelay [0..1] [0..1] PAextOp PAextOp [0..1] [0..1] PAinterval PAinterval [0..1] [0..1] Message, Message, ActionState ActionState, , Stimulus, Stimulus, SubactivityState SubactivityState « «PAstep PAstep» » A passive resource A passive resource PAutilization PAutilization [0..*] [0..*] PAschdPolicy PAschdPolicy [0..1] [0..1] PAcapacity PAcapacity [0..1] [0..1] PAmaxTime PAmaxTime [0..1] [0..1] PArespTime PArespTime [0..1] [0..1] PAwaitTime PAwaitTime [0..1] [0..1] PAthroughput PAthroughput [0..1] [0..1] Classifier, Node, Classifier, Node, ClassifierRole ClassifierRole, Instance, , Instance, Partition Partition « «PAresource PAresource» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-120
SLIDE 120

120

Specifying Performance Values Specifying Performance Values

♦A complex structured string with the following format

■ <kind-of-value> , <modifier> , <time-value>

♦Where:

■ <kind-of-value> ::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’ ■ Required, assumed, predicted, measured ■ <modifier> ::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , <Integer> |

‘max’ | ‘percentile’ <Real> | ‘dist’

■ E.g.:

{PAdemand = (‘msr’, ‘mean’, (20, ‘ms’))}

♦ ♦A complex structured string with the following format A complex structured string with the following format

■ ■ <kind

<kind-

  • of
  • f-
  • value> , <modifier> , <time

value> , <modifier> , <time-

  • value>

value>

♦ ♦Where: Where:

■ ■ <kind

<kind-

  • of
  • f-
  • value> ::= ‘

value> ::= ‘req’ req’ | ‘ | ‘assm’ assm’ | ‘ | ‘pred’ pred’ | ‘ | ‘msr’ msr’

■ ■ Required, assumed, predicted, measured

Required, assumed, predicted, measured

■ ■ <modifier> ::= ‘mean’ | ‘sigma’ | ‘

<modifier> ::= ‘mean’ | ‘sigma’ | ‘kth kth-

  • mom’ , <Integer> |

mom’ , <Integer> | ‘max’ | ‘percentile’ <Real> | ‘dist’ ‘max’ | ‘percentile’ <Real> | ‘dist’

■ ■ E.g.:

E.g.: { {PAdemand PAdemand = (‘ = (‘msr’ msr’, ‘mean’, (20, ‘ms’))} , ‘mean’, (20, ‘ms’))}

slide-121
SLIDE 121

121

Schedulability Analysis Sub Schedulability Analysis Sub-

  • Profile

Profile

SAction Priority Worst-case Completion Time Delay Time Preempted Time Ready Time Release Time Blocking Time Laxity Absolute Deadline Relative Deadline isAtomic Response Utilization Spare Capacity Overlaps Slack Time Trigger isSchedulable 1 1 +effect 1 +cause 1 / 0..n 0..n +precedents 0..n 0..n RealTimeSituation SchedulableResource 1 0..n +host 1 0..n SchedulingPolicy SResource Capacity Acquisition Time Deacquisition Time isConsumable Priority Ceiling isPreemptible 0..n 0..n +usedResources 0..n 0..n / 0..n 0..n 0..n 0..n SchedulingJob 1..n 0..n 1..n 0..n 1 1 1 1 1 1 1 1 ExecutionEngine Priority Range Processing Rate Context Switch Time Utilization isPreemptible isSchedulable 1..n 0..n 1..n 0..n 1 0..n +host 1 0..n 1 0..n 1 0..n 0..n 0..1 +ownedResources 0..n 0..1 0..n 1 0..n 1 <<deploys>> <<deploys>>

slide-122
SLIDE 122

122

Policies Supported Policies Supported

♦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 Control Policies:

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

Priority Ceiling

■ …may be extended in the future

♦ ♦Scheduling Policies: Scheduling Policies:

■ ■ Rate Monotonic, Deadline Monotonic, HKL, Fixed Priority,

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

■ ■ …may be extended in the future

…may be extended in the future

♦ ♦Access Control Policies: Access Control Policies:

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

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

■ ■ …may be extended in the future

…may be extended in the future

slide-123
SLIDE 123

123

Example Example

♦A simple telemetry system with 3 cyclical tasks ♦ ♦A simple telemetry system with 3 cyclical tasks A simple telemetry system with 3 cyclical tasks

Sensors :SensorInterface TelemetryGatherer :DataGatherer SensorData :RawDataStorage TelemetryDisplayer : DataDisplayer TelemetryProcessor :DataProcessor Display :DisplayInterface TGClock : Clock TGClock : Clock TGClock : Clock

A.1:gatherData ( ) A.1.1:main ( ) A.1.1.1: writeStorage ( ) B.1:filterData ( ) B.1.1 : main ( ) B.1.1.1: readStorage ( ) C.1:displayData ( ) C.1.1.1: readStorage ( ) C.1.1 : main ( )

slide-124
SLIDE 124

124

Example: Schedulability Annotations Example: Schedulability Annotations

Sensors :SensorInterface TelemetryGatherer :DataGatherer

«SAResource»

SensorData :RawDataStorage TelemetryDisplayer : DataDisplayer TelemetryProcessor :DataProcessor Display :DisplayInterface TGClock : Clock TGClock : Clock

A.1:gatherData ( ) C.1:displayData ( ) B.1:filterData ( )

TGClock : Clock

A.1.1:main ( ) A.1.1.1: writeStorage ( ) B.1.1 : main ( ) B.1.1.1: readStorage ( ) C.1.1.1: readStorage ( ) C.1.1 : main ( ) {SACapacity=1, SAAccessControl=PriorityInheritance} «SASchedulable» «SASchedulable» «SASchedulable» «SATrigger» {SASchedulable=$R1, RTat=('periodic',100,'ms')} «SAResponse» {SAAbsDeadline=(100,'ms')}

«SASituation»

«SAAction» {SAPriority=2, SAWorstCase=(93,'ms'), RTduration=(33.5,'ms')} «SAAction» {RTstart=(16.5,'ms'), RTend=(33.5,'ms')} «SATrigger» {SASchedulable=$R2, RTat=('periodic',60,'ms')} «SAResponse» {SAAbsDeadline=(60,'ms')} «SATrigger» {SASchedulable=$R3, RTat=('periodic',200,'ms')} «SAResponse» {SAAbsDeadline=(200,'ms')} «SAResponse» {SAPriority=3, SAWorstCase=(177,'ms'), RTduration=(46.5,'ms')} «SAAction» {RTstart=(10,'ms'), RTend=(31.5,'ms')} «SAAction» {RTstart=(3,'ms'), RTend=(5,'ms')} «SAResponse» {SAPriority=1, SAWorstCase=(50.5,'ms'), RTduration=(12.5,'ms')}

Result Result

slide-125
SLIDE 125

125

«SAEngine» {SARate=1, SASchedulingPolicy=FixedPriority}

:Ix86Processor

«SASchedulable»

TelemetryGatherer :DataGatherer

«SASchedulable»

TelemetryDisplayer : DataDisplayer

«SASchedulable»

TelemetryProcessor :DataProcessor

Example: Deployment Specification Example: Deployment Specification

«SAResource»

SensorData :RawDataStorage

«SAOwns» «GRMdeploys»

slide-126
SLIDE 126

126

Example: Analysis Results Example: Analysis Results

Sensors :SensorInterface TelemetryGatherer :DataGatherer

«SAResource»

SensorData :RawDataStorage TelemetryDisplayer : DataDisplayer TelemetryProcessor :DataProcessor Display :DisplayInterface TGClock : Clock TGClock : Clock

A.1:gatherData ( ) C.1:displayData ( ) B.1:filterData ( )

TGClock : Clock

A.1.1:main ( ) A.1.1.1: writeStorage ( ) B.1.1 : main ( ) B.1.1.1: readStorage ( ) C.1.1.1: readStorage ( ) C.1.1 : main ( ) {SACapacity=1, SAAccessControl=PriorityInheritance} «SASchedulable» «SASchedulable» «SASchedulable» «SATrigger» RTat=('periodic',100,'ms')} «SAResponse» {SAAbsDeadline=(100,'ms')}

«SASituation»

«SAAction» {SAPriority=2, SAWorstCase=(93,'ms'), RTduration=(33.5,'ms')} «SAAction» {RTstart=(16.5,'ms'), RTend=(33.5,'ms')} «SATrigger» RTat=('periodic',60,'ms')} «SAResponse» {SAAbsDeadline=(60,'ms')} «SATrigger» RTat=('periodic',200,'ms')} «SAResponse» {SAAbsDeadline=(200,'ms')} «SAResponse» {SAPriority=3, SAWorstCase=(177,'ms'), RTduration=(46.5,'ms')} «SAAction» {RTstart=(10,'ms'), RTend=(31.5,'ms')} «SAAction» {RTstart=(3,'ms'), RTend=(5,'ms')} «SAResponse» {SAPriority=1, SAWorstCase=(50.5,'ms'), RTduration=(12.5,'ms')} {SASchedulable=$true, {SASchedulable=$true {SASchedulable=$true

Additional tool-specific results encased in UML Notes Additional tool-specific results encased in UML Notes

slide-127
SLIDE 127

127

Defined Stereotypes (1 of 3) Defined Stereotypes (1 of 3)

An execution engine An execution engine

SASchedulingPolicy SASchedulingPolicy [0..1] [0..1] SAAccessPolicy SAAccessPolicy [0..1] [0..1] SARate SARate [0..1] [0..1] SAContextSwitch SAContextSwitch [0..1] [0..1] SAPriorityRange SAPriorityRange [0..1] [0..1] SAPreemptible SAPreemptible [0..1] [0..1] SAUtilization SAUtilization [0..1] [0..1] SASchedulable SASchedulable [0..1] [0..1] Saresources Saresources [0..1] [0..1]

Node, Instance, Object, Node, Instance, Object, Classifier, Classifier, ClassifierRole ClassifierRole « «SAEngine SAEngine» » An action An action

SAPriority SAPriority [0..1] [0..1] SAActualPty SAActualPty [0..1] [0..1] SABlocking SABlocking [0..1] [0..1] SAReady SAReady [0..1] [0..1] SADelay SADelay [0..1] [0..1] SARelease SARelease [0..1] [0..1] SAPreempted SAPreempted [0..1] [0..1] SAWorstCase SAWorstCase [0..1] [0..1] SALaxity SALaxity [0..1] [0..1] SAPriority SAPriority [0..1] [0..1] SAAbsDeadline SAAbsDeadline [0..1] [0..1] SARelDeadline SARelDeadline [0..1] [0..1] SAusedResource SAusedResource [0..1] [0..1] SAhost SAhost [0..1] [0..1]

Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «SAAction SAAction» » (subclass of « (subclass of «RTaction RTaction» » and « and «CRAction CRAction») ») Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-128
SLIDE 128

128

Defined Stereotypes (2 of 3) Defined Stereotypes (2 of 3)

A resource of some kind A resource of some kind SAAccessControl SAAccessControl [0..1] [0..1] SAConsumable SAConsumable [0..1] [0..1] SACapacity SACapacity [0..1] [0..1] SAAcquisition SAAcquisition [0..1] [0..1] SADeacquisition SADeacquisition [0..1] [0..1] SAPtyCeiling SAPtyCeiling [0..1] [0..1] SAPreemptible SAPreemptible [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «SAResource SAResource» » A schedulable resource A schedulable resource Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «SASchedulable SASchedulable» » (subclass of (subclass of « «SAResource SAResource») ») A response to a stimulus or A response to a stimulus or action action SAUtilization SAUtilization [0..1] [0..1] SASpare SASpare [0..1] [0..1] SASlack SASlack [0..1] [0..1] SAOverlaps SAOverlaps [0..1] [0..1] Action, Action, ActionExecution ActionExecution, , Stimulus, Action, Stimulus, Action, Message, Method… Message, Method… « «SAResponse SAResponse» (subclass » (subclass

  • f «
  • f «SAAction

SAAction») ») A precedence relationship A precedence relationship between actions and triggers between actions and triggers Usage Usage « «SAPrecedes SAPrecedes» » Identifies ownership of Identifies ownership of resources resources Abstraction Abstraction « «SAOwns SAOwns» » (subclass of (subclass of « «GRMrealize GRMrealize») ») Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-129
SLIDE 129

129

Defined Stereotypes (3 of 3) Defined Stereotypes (3 of 3)

Identifies sharable Identifies sharable resources resources Usage Usage « «SAUses SAUses» » A schedulability analysis A schedulability analysis context context Collaboration, Collaboration, CollaborationInstance CollaborationInstance, , ActivityGraph ActivityGraph « «SASituation SASituation» » Identifies schedulable Identifies schedulable resources used for resources used for execution of actions execution of actions Usage Usage « «SAusedHost SAusedHost» » A trigger A trigger SASchedulable SASchedulable [0..1] [0..1] SASAprecedents SASAprecedents [0..1] [0..1] Message, Stimulus Message, Stimulus « «SATrigger SATrigger» (subclass of » (subclass of « «SAAction SAAction») ») A precedence A precedence relationship between relationship between actions and triggers actions and triggers Usage Usage « «SAPrecedes SAPrecedes» » A scheduler A scheduler SASchedulingPolicy SASchedulingPolicy [0..1] [0..1] SAExecutionEngine SAExecutionEngine [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object Instance, Object « «SAScheduler SAScheduler» » Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-130
SLIDE 130

130

Real Real-

  • Time CORBA: Schedulability Sub

Time CORBA: Schedulability Sub-

  • Profile

Profile

RTCconnection isShared hiPriority loPriority SResource

(from Sche dulin gDomanModel )

RTCserver serverPriority 0..n 1 0..n 1 RTCorb 0..n 1 RTCmutex 0..n <<deploys>> +host 0..n 0..n 1 RTCclient timeout clientPriority private 1 1..n 1 +host 1..n <<deploys>> Response

(from SchedulingDomanModel)

0..n 0..n +usedResources 0..n 0..n / 1..n 0..n +usedResources 1..n 0..n / 1..n 0..n 1..n +usedResources 0..n 1 0..n 1 0..n / ExecutionEngine

(from SchedulingDomanModel)

SchedulableResource

(from SchedulingDomanModel)

/ +clientScenario / +ownedResources /

slide-131
SLIDE 131

131

Example: RT CORBA Example: RT CORBA

«RTclock» TGClock : Clock «RSAclient» {RSAtimeout=(105,'ms), RSAclPrio=12 TelemetryGatherer : DataGatherer «RSAserver» {SACapacity=4} Sensor1 :SensorInterface «RSAserver» {SACapacity=10} Sensor2 :SensorInterface «RSAorb» {SASchedulingPolicy= 'RateMonotonic'} TG-ORB: RTOrb «GRMdeploys» «RSAorb» {SASchedulingPolicy= 'RateMonotonic'} S1-ORB: RTOrb «GRMdeploys» «RSAorb» {SASchedulingPolicy= 'RateMonotonic'} S2-ORB: RTOrb «GRMdeploys» «SAEngine» {SASchedulingPolicy= 'RateMonotonic', SARate=1} P1 : I586 «SAEngine» {SASchedulingPolicy= 'RateMonotonic', SARate=0.5} P2 : Ix86 «GRMdeploys» «GRMdeploys» «GRMdeploys» «GRMdeploys»

«SASituation»

slide-132
SLIDE 132

132

Example: RT CORBA Usage Scenario Example: RT CORBA Usage Scenario

«RTclock» TGClock «RSAclient» TelemetryGatherer : DataGatherer

«RTevent» {RTat=('periodic', 100, 'ms')} tick ( )

«RSAserver» Sensor1 :SensorInterface

«SAAction» {SAWorstCase=(15,'ms'), RTduration=(10,'ms')} readSensor ( ) «SAresponse» {SAAbsDeadline =(100,'ms')

«RSAserver» Sensor2 :SensorInterface

«SAAction» {SAWorstCase=(30,'ms'), RTduration=(20,'ms')} readSensor ( ) «SAAction» {SAWorstCase=(25,'ms'), RTduration=(5,'ms')} compare ( )

«SASituation»

slide-133
SLIDE 133

133

Defined Stereotypes Defined Stereotypes

An RT CORBA server An RT CORBA server RSAsrvPrio RSAsrvPrio [0..1] [0..1] SACapacity SACapacity [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «RSAserver RSAserver» » (subclass of (subclass of « «SAResource SAResource» ) » ) An RT CORBA An RT CORBA mutex mutex SAAccessControl SAAccessControl [0..1] [0..1] RSAhost RSAhost [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «RSAmutex RSAmutex» » (subclass of (subclass of « «SAResource SAResource») ») An RT CORBA ORB An RT CORBA ORB SAschedulingPolicy SAschedulingPolicy [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «RSAorb RSAorb» » (subclass of (subclass of « «SAResource SAResource» ) » ) An RT CORBA An RT CORBA connection connection SAAccessControl SAAccessControl [0..1] [0..1] RSAshared RSAshared [0..1] [0..1] RSAhiPrio RSAhiPrio [0..1] [0..1] RSAloPrio RSAloPrio [0..1] [0..1] RSAserver RSAserver [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «RSAconnection RSAconnection» » (subclass of (subclass of « «SASchedulable SASchedulable» and » and « «SAResource SAResource») ») An RT CORBA client An RT CORBA client RSAtimeout RSAtimeout [0..1] [0..1] RSAclPrio RSAclPrio [0..1] [0..1] RSAprivate RSAprivate [0..1] [0..1] RSAhost RSAhost [0..1] [0..1] Classifier, Classifier, ClassifierRole ClassifierRole, , Instance, Object, Node Instance, Object, Node « «RSAclient RSAclient» » (subclass of (subclass of « «SASchedulable SASchedulable») ») Description Description Tags Tags Applies To Applies To Stereotype Stereotype

slide-134
SLIDE 134

134

Real Time CORBA: Infrastructure Model Real Time CORBA: Infrastructure Model

RTCORBA <<CORBAModule>> RTPortableServer <<CORBAModule>> CORBA <<CORBAModule>> IOP <<CORBAModule>> PortableServer <<CORBAModule>> RTCosScheduling <<CORBAModule>>

slide-135
SLIDE 135

135

Model Processing Paradigm and Tools Model Processing Paradigm and Tools

Model Processor

Model Configurer

Parametrized UML Model (XMI) Configured UML Model (XMI)

Model Editor Results Convertor

Configuration Data Set

Model Convertor

Processing Control Specification Domain Model

Model Analyzer

Processing Results Results UML Model (XMI)

1 2 3 4 5 6 7 8 9

10

slide-136
SLIDE 136

136

The Tag Value Language The Tag Value Language

♦Tagged value format:

{<tag-name> = <tag-value>}

♦Used to specify complex (structured) tagged values ♦Based on a small proper subset of the freeware Perl language

■ Includes: variables, numbers, booleans, strings, lists,

expressions (including conditionals), operators, and functions

♦Suitable for:

■ expressing complex dependencies between values ■ writing processing scripts

♦ ♦Tagged value format: Tagged value format:

{<tag {<tag-

  • name> = <tag

name> = <tag-

  • value>}

value>}

♦ ♦Used to specify complex (structured) tagged values Used to specify complex (structured) tagged values ♦ ♦Based on a small proper subset of the freeware Based on a small proper subset of the freeware Perl Perl language language

■ ■ Includes: variables, numbers,

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

♦ ♦Suitable for: Suitable for:

■ ■ expressing complex dependencies between values

expressing complex dependencies between values

■ ■ writing processing scripts

writing processing scripts

slide-137
SLIDE 137

137

Summary: The Real Time UML Profile Summary: The Real Time UML Profile

♦The RT UML Profile defines a set of extensions for directly expressing real-time domain concepts in UML:

■ resources ■ concurrency mechanisms ■ time and timing mechanisms

♦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

♦ ♦The RT UML Profile defines a set of extensions for The RT UML Profile defines a set of extensions for directly expressing real directly expressing real-

  • time domain concepts in UML:

time domain concepts in UML:

■ ■ resources

resources

■ ■ concurrency mechanisms

concurrency mechanisms

■ ■ time and timing mechanisms

time and timing mechanisms

♦ ♦Furthermore, it allows the specification of quantitative Furthermore, it allows the specification of quantitative aspects in the same models such that the models can be aspects in the same models such that the models can be analyzed analyzed

■ ■ predictive models that can be used to validate (risky) design

predictive models that can be used to validate (risky) design approaches before major investments are made approaches before major investments are made

slide-138
SLIDE 138

138

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials ■ Essentials of the Object Paradigm

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

■ ■ Essentials of the Object Paradigm

Essentials of the Object Paradigm

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-139
SLIDE 139

139

Common Wisdom... Common Wisdom...

♦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, what about real-time systems? ♦ ♦When designing software, we are instructed to ignore When designing software, we are instructed to ignore details of the technology and similar “implementation” details of the technology and similar “implementation” issues until we have a sound logical solution to the issues until we have a sound logical solution to the problem problem

■ ■ simplifies the design problem (separation of concerns)

simplifies the design problem (separation of concerns)

■ ■ software is portable to new/different technologies

software is portable to new/different technologies

♦ ♦But, what about real But, what about real-

  • time systems?

time systems?

slide-140
SLIDE 140

140

The Ideal and the Real The Ideal and the Real

♦ ♦The idealized “forms” of pure logic acquire the finite The idealized “forms” of pure logic acquire the finite characteristics of the physical stuff out of which they are characteristics of the physical stuff out of which they are spun spun

■ ■ limited speed, limited capacity, limited availability,...

limited speed, limited capacity, limited availability,...

slide-141
SLIDE 141

141

Node1 (New York) Node2 (Tokyo)

  • bserver
  • n
  • ff
  • ff
  • n

State? State? “on” “on” “on” “on”

Real System Design Issues (1) Real System Design Issues (1)

♦Possibility of out-of-date state information due to lengthy (and variable) transmission delays ♦ ♦Possibility of out Possibility of out-

  • of
  • f-
  • date state information due to lengthy

date state information due to lengthy (and variable) transmission delays (and variable) transmission delays

It’s a game of numbers! It’s a game of numbers!

slide-142
SLIDE 142

142

clientA clientA clientA notifier1 notifier1 notifier1 notifier2 notifier2 notifier2 clientB clientB clientB

e1 e1 e1 e1 e2 e2 e2 e2

time time

Real System Design Issues (2) Real System Design Issues (2)

♦Inconsistent views of system state:

■ different observers see different event orderings

♦ ♦Inconsistent views of system state: Inconsistent views of system state:

■ ■ different observers see different event orderings

different observers see different event orderings

It’s a game of numbers! It’s a game of numbers!

slide-143
SLIDE 143

143

Distributed System Characteristics Distributed System Characteristics

♦Key characteristics:

■ concurrency and asynchrony ■ need for communication and synchronization between sites ■ communication delays ■ possibility of partial failure

♦Each of these adds significant “weight” to the programming problem ♦Distributed programming is different from and much more complex than conventional programming ♦ ♦Key characteristics: Key characteristics:

■ ■ concurrency and asynchrony

concurrency and asynchrony

■ ■ need for communication and synchronization between sites

need for communication and synchronization between sites

■ ■ communication delays

communication delays

■ ■ possibility of partial failure

possibility of partial failure

♦ ♦Each of these adds significant “weight” to the Each of these adds significant “weight” to the programming problem programming problem ♦ ♦Distributed programming is different from and much more Distributed programming is different from and much more complex than conventional programming complex than conventional programming

slide-144
SLIDE 144

144

Real Real-

  • World Real

World Real-

  • Time Design Issues

Time Design Issues

♦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 real-time design dilemma:

if the physical world intrudes on the logical world, how can we separate the “logical” world of design from the “physical” world

  • f implementation to achieve portability?

♦ ♦Much of the complexity associated with these systems is Much of the complexity associated with these systems is the result of the “intrusion” of the inherently complex the result of the “intrusion” of the inherently complex physical world into the idealized logical world of software physical world into the idealized logical world of software ♦ ♦The real The real-

  • time design dilemma:

time design dilemma:

if the physical world intrudes on the logical world, how can we if the physical world intrudes on the logical world, how can we separate the “logical” world of design from the “physical” world separate the “logical” world of design from the “physical” world

  • f implementation to achieve portability?
  • f implementation to achieve portability?
slide-145
SLIDE 145

145

Logical (Conceptual) Viewpoint Logical (Conceptual) Viewpoint

♦A technology-independent view of the software

■ a “virtual” mechanism realized by a computer

♦ ♦A technology A technology-

  • independent view of the software

independent view of the software

■ ■ a “virtual” mechanism realized by a computer

a “virtual” mechanism realized by a computer

INSTRUCTOR STATION INSTRUCTOR INSTRUCTOR STATION STATION AIRFRAME AIRFRAME AIRFRAME GROUND MODEL GROUND GROUND MODEL MODEL ATMOSPHERE MODEL ATMOSPHERE ATMOSPHERE MODEL MODEL ENGINES ENGINES ENGINES CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES PILOT CONTROLS PILOT PILOT CONTROLS CONTROLS

slide-146
SLIDE 146

146

Engineering (Realization) Viewpoint Engineering (Realization) Viewpoint

♦The realization of a specific set of logical components using facilities of the run-time environment ♦ ♦The realization of a specific set of logical components The realization of a specific set of logical components using facilities of the run using facilities of the run-

  • time environment

time environment

Processor Processor Ethernet LAN Ethernet LAN Processor Processor OS process OS OS process process

stack stack

OS process OS OS process process

stack stack

OS process OS OS process process

stack stack

TCP/IP socket TCP/IP socket TCP/IP socket TCP/IP socket

slide-147
SLIDE 147

147

Engineering View Engineering View Engineering View

Processor Processor Ethernet LAN Ethernet LAN Processor Processor OS process OS OS process process stack stack OS process OS OS process process stack stack OS process OS OS process process stack stack TCP/IP socket TCP/IP socket TCP/IP socket TCP/IP socket

Logical View Logical View Logical View

Views and Mappings Views and Mappings

INSTRUCTOR STATION INSTRUCTOR INSTRUCTOR STATION STATION AIRFRAME AIRFRAME AIRFRAME GROUND MODEL GROUND GROUND MODEL MODEL ATMOSPHERE MODEL ATMOSPHERE ATMOSPHERE MODEL MODEL ENGINES ENGINES ENGINES CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES PILOT CONTROLS PILOT PILOT CONTROLS CONTROLS

Realization mappings Realization mappings

slide-148
SLIDE 148

148

Realization Mappings Realization Mappings

♦A correspondence between elements of two distinct models (logical and engineering) ♦Semantics: the logical elements are implemented by the corresponding engineering model elements

■ logical elements can be viewed as “residing” on the

corresponding engineering elements

♦ ♦A correspondence between elements of two distinct A correspondence between elements of two distinct models (logical and engineering) models (logical and engineering) ♦ ♦Semantics: the logical elements are Semantics: the logical elements are implemented implemented by the by the corresponding engineering model elements corresponding engineering model elements

■ ■ logical elements can be viewed as “residing” on the

logical elements can be viewed as “residing” on the corresponding engineering elements corresponding engineering elements

AIRFRAME AIRFRAME AIRFRAME CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES Model 1 Model 1

OS process1 OS OS process1 process1 OS process1 OS OS process1 process1

Model 2 Model 2

Processor Processor

Model 3 Model 3

slide-149
SLIDE 149

149

Selecting a Level of Abstraction Selecting a Level of Abstraction

♦Intermediate levels may be abstracted out

■ depends on the desired granularity of modeling ■ affects the semantics of the realization relationship

♦ ♦Intermediate levels may be abstracted out Intermediate levels may be abstracted out

■ ■ depends on the desired granularity of modeling

depends on the desired granularity of modeling

■ ■ affects the semantics of the realization relationship

affects the semantics of the realization relationship

AIRFRAME AIRFRAME AIRFRAME CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES Model 1 Model 1 OS process1 OS OS process1 process1 OS process1 OS OS process1 process1 Model 2 Model 2 Processor Processor Model 3 Model 3 AIRFRAME AIRFRAME AIRFRAME CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES Model 1 Model 1 Processor Processor Model 3 Model 3

slide-150
SLIDE 150

150

The Engineering Viewpoint in RT Systems 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 crucial (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 design

■ Unfortunately, UML deployment diagrams are inadequate

♦ ♦ The engineering view represents the “raw material” out of which The engineering view represents the “raw material” out of which we construct the logical view we construct the logical view

■ ■ the quality of the outcome is only as good as the quality of the

the quality of the outcome is only as good as the quality of the ingredients that are put in ingredients that are put in

■ ■ as in all true engineering, the quantitative aspects are often c

as in all true engineering, the quantitative aspects are often crucial (How rucial (How long long will it take? How will it take? How much much will be required?…) will be required?…)

♦ ♦ The ability to accurately model the relationship between the The ability to accurately model the relationship between the engineering and logical models is crucial to real engineering and logical models is crucial to real-

  • time system

time system design design

■ ■ Unfortunately, UML deployment diagrams are inadequate

Unfortunately, UML deployment diagrams are inadequate

slide-151
SLIDE 151

151

The Resource Model and Realization The Resource Model and Realization

⇒The same QoS framework can be used for quantifying realization relationships ⇒ ⇒The same QoS framework can be used for quantifying The same QoS framework can be used for quantifying realization relationships realization relationships

20MB 20MB 3MIPs 3MIPs 100Mbit/s 100Mbit/s

environment “services” (offered QoS values) environment “services” environment “services” (offered QoS values) (offered QoS values) CPU CPU CPU LAN LAN LAN resources resources resources

CPU : CPU : 3 3 MIPs MIPs Bandw

  • Bandw. :

. : 70Mbit/s 70Mbit/s Mem Mem : : 2MB 2MB

required QoS values required QoS values required QoS values

Airframe Airframe Airframe

client client client resource “usage” resource “usage” resource “usage”

slide-152
SLIDE 152

152

Two Interpretations of Resource Model Two Interpretations of Resource Model

♦The peer interpretation ♦ ♦The The peer peer interpretation interpretation ♦The layered interpretation (the 2-viewpoint model) ♦ ♦The The layered layered interpretation (the 2 interpretation (the 2-

  • viewpoint model)

viewpoint model)

resource resource resource client client client accesses➨ accesses➨

Logical View Logical View Logical View

WinNT Process WinNT WinNT Process Process

Engineering View Engineering View Engineering View

WinNT Process WinNT WinNT Process Process

«realize» «realize»

slide-153
SLIDE 153

153

Example: Realization Relationships Example: Realization Relationships

♦For sophisticated multi-layer deployment modeling ♦ ♦For sophisticated multi For sophisticated multi-

  • layer deployment modeling

layer deployment modeling

«OSprocess» HostProcess: P {ctxtSw = “80 usec”; heap = “30 kB} «LWT» Thread1 : T {ctxtSw = “10 usec”} «LWT» Thread3 : T {ctxtSw = “10 usec”} «LWT» Thread2 : T {ctxtSw = “10 usec”} TSensor: TemperatueSensor {cycle = “20 msec”} injector: FIControl {cycle = “20 msec”} instPanel: Register {cycle = “40 msec”} temp : Temperature «GRMdeploys» «GRMdeploys» «GRMdeploys» «GRMdeploys»

slide-154
SLIDE 154

154

Forms of Realization Forms of Realization

slide-155
SLIDE 155

155

Modeling Realization in UML Modeling Realization in UML

♦An association between models with explicit realization mappings between model elements ♦ ♦An association between models with explicit realization An association between models with explicit realization mappings between model elements mappings between model elements

Logical Model Logical Model Logical Model A B

asc asc

Engineering Model Engineering Model Engineering Model X Y Z

«GRMrealizes» «GRMrealizes»

Source element Dest. elements A X, Y asc Y B Z

deployment table A stereotype of the UML realizes relationship A stereotype of the UML realizes relationship Compact tabular form Compact tabular form

slide-156
SLIDE 156

156

Specifying Realization Mappings Specifying Realization Mappings

♦Captures the specifics of the realization mapping

■ Either as a string (tag value) or as a table

♦ ♦Captures the specifics of the realization mapping Captures the specifics of the realization mapping

■ ■ Either as a string (tag value) or as a table

Either as a string (tag value) or as a table

<Any additional constraints that apply to the mapping> <Interaction mode between levels, one

  • f:>

{sync, async, replace} <If there are multiple engineering elements,

  • ne of:>

{inclusive, exclusiveStatic, exclusiveDynamic} <List of corresponding engineering model elements> <List of logical model elements> Additional Additional Constraints Constraints Linkage Linkage Mode Mode Engineering Engineering Elements Elements Logical Logical Elements Elements

E E L L

sync = SW to SW sync = SW to SW async async = SW to SW = SW to SW replace = SW to HW replace = SW to HW

E1 E1 En En L1 L1

slide-157
SLIDE 157

157

Engineering Engineering-

  • Oriented Design (EOD)

Oriented Design (EOD)

♦Analysis and design of software systems based on use of

■ Models ■ QoS specifications (accounting for physical properties) ■ Quantitative analysis techniques and simulation

♦Complements any model-based development method ♦Advantages:

■ Higher reliability (simplification due to modeling) ■ Ability to predict system characteristics (and major design

flaws) prior to full realization

■ Portability!

♦ ♦Analysis and design of software systems based on use of Analysis and design of software systems based on use of

■ ■ Models

Models

■ ■ QoS specifications (accounting for physical properties)

QoS specifications (accounting for physical properties)

■ ■ Quantitative analysis techniques and simulation

Quantitative analysis techniques and simulation

♦ ♦Complements any model Complements any model-

  • based development method

based development method ♦ ♦Advantages: Advantages:

■ ■ Higher reliability (simplification due to modeling)

Higher reliability (simplification due to modeling)

■ ■ Ability to predict system characteristics (and major design

Ability to predict system characteristics (and major design flaws) prior to full realization flaws) prior to full realization

■ ■ Portability!

Portability!

slide-158
SLIDE 158

158

Achieving Portability with EOD Achieving Portability with EOD

♦Dilemma: How can we account for the engineering aspects of the system without prematurely and possibly unnecessarily committing to a particular technology? ♦Approach: Provide an abstract technology-independent but quantified specification of the required characteristics

  • f the engineering model as part of the logical model

♦ ♦Dilemma: Dilemma: How can we account for the engineering How can we account for the engineering aspects of the system without prematurely and possibly aspects of the system without prematurely and possibly unnecessarily committing to a particular technology? unnecessarily committing to a particular technology? ♦ ♦Approach: Approach: Provide an abstract technology Provide an abstract technology-

  • independent

independent but quantified specification of the required characteristics but quantified specification of the required characteristics

  • f the engineering model as part of the logical model
  • f the engineering model as part of the logical model
slide-159
SLIDE 159

159

Viewpoint Separation Viewpoint Separation

♦Required Environment: a technology-neutral environment specification required by the logical elements of a model ♦ ♦Required Environment Required Environment: : a technology a technology-

  • neutral environment

neutral environment specification required by the logical elements of a model specification required by the logical elements of a model

Logical View Logical View Logical View Required Environment Required Environment Required Environment

UNIX Process UNIX UNIX Process Process

Engineering View (alternative A) Engineering View (alternative A) Engineering View (alternative A)

UNIX Process UNIX UNIX Process Process WinNT Process WinNT WinNT Process Process

Engineering View (alternative B) Engineering View (alternative B) Engineering View (alternative B)

WinNT Process WinNT WinNT Process Process

slide-160
SLIDE 160

160

Required Environment Partitions Required Environment Partitions

INSTRUCTOR STATION INSTRUCTOR INSTRUCTOR STATION STATION AIRFRAME AIRFRAME AIRFRAME GROUND MODEL GROUND GROUND MODEL MODEL ATMOSPHERE MODEL ATMOSPHERE ATMOSPHERE MODEL MODEL ENGINES ENGINES ENGINES CONTROL SURFACES CONTROL CONTROL SURFACES SURFACES PILOT CONTROLS PILOT PILOT CONTROLS CONTROLS

♦Logical elements often share common QoS requirements ♦ ♦Logical elements often share common QoS requirements Logical elements often share common QoS requirements

QoS domain (e.g.,failure unit, uniform comm properties) QoS domain (e.g.,failure unit, uniform comm properties)

slide-161
SLIDE 161

161

QoS Domains QoS Domains

♦Specify a domain in which certain QoS values apply universally:

■ failure characteristics (failure modes, availability, reliability) ■ CPU performance ■ communications characteristics (delay, throughput, capacity) ■ etc.

♦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 ♦ ♦Specify a domain in which certain QoS values apply Specify a domain in which certain QoS values apply universally: universally:

■ ■ failure characteristics (failure modes, availability, reliabilit

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

■ ■ CPU performance

CPU performance

■ ■ communications characteristics (delay, throughput, capacity)

communications characteristics (delay, throughput, capacity)

■ ■ etc.

etc.

♦ ♦The QoS values of a domain can be compared against The QoS values of a domain can be compared against those of a concrete engineering environment to see if a those of a concrete engineering environment to see if a given environment is adequate for a specific model given environment is adequate for a specific model

slide-162
SLIDE 162

162

Modeling QoS Domains in UML Modeling QoS Domains in UML

♦Similar to realization: mapping of logical elements to a desired (required) engineering environment ♦ ♦Similar to realization: mapping of logical elements to a Similar to realization: mapping of logical elements to a desired (required) engineering environment desired (required) engineering environment

Logical View Logical View Logical View Required Environment Required Environment Required Environment

QoS1 QoS1 QoS1 QoS2 QoS2 QoS2 QoS3 QoS3 QoS3 A local “engineering” model A local “engineering” model «GRMrequires»: a specialization of the “realizes” relationship «GRMrequires»: a specialization of the “realizes” relationship

Stereotype UML base concepts Tags GRMrequires GRMrealizes N/A

slide-163
SLIDE 163

163

Example: QoS Domain for an Active Object Example: QoS Domain for an Active Object

♦Using a stereotype of Node

■ in conjunction with the “required environment” relationship

♦ ♦Using a stereotype of Node Using a stereotype of Node

■ ■ in conjunction with the “required environment” relationship

in conjunction with the “required environment” relationship

R R readObj () readObj () «GRMthreadEnv» ThreadForR {priority = 3; heap = 20 KB; stack = 3 KB}

«GRMrequires» «GRMrequires»

Active class Active class Environment expected by instances of class R Environment expected by instances of class R

Stereotype UML base concepts Tags GRMthreadEnv Node, Instance priority [0..1] : Integer heap [0..1] : Real stack [0..1] : Real

slide-164
SLIDE 164

164

MainTask

Task1 Task2 Task3

Example: Task Allocation Example: Task Allocation

♦The allocation of logical model to engineering model elements ♦ ♦The allocation of logical model to engineering model The allocation of logical model to engineering model elements elements

master : Master poller : Poller d : DBaseServer cs : CommServer dBadmin : Admin

slide-165
SLIDE 165

165

Example: UML Model of Allocation Example: UML Model of Allocation

LogicalPkgX LogicalPkgX

master : Master poller : Poller d : DBaseServer cs : CommServer dBadmin : Admin

EngineeringPkgY EngineeringPkgY

Task1 : Task Task3 : Task Task2 : Task MainTask : Task

EngineeringPkgZ EngineeringPkgZ

«GRMschedulableEntity» Task

«import» «import» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires» «GRMrequires»

slide-166
SLIDE 166

166

EngineeringPkgY EngineeringPkgY

Task1 : Task Task3 : Task Task2 : Task MainTask : Task

Example: Completing the Mapping Example: Completing the Mapping

♦Mapping to hardware ♦ ♦Mapping to hardware Mapping to hardware

EngineeringPkgD EngineeringPkgD

«GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize»

«SAProcessingResource» Proc1

«GRMrealize» «GRMrealize»

slide-167
SLIDE 167

167

Example: UML Model of Allocation Example: UML Model of Allocation

LogicalPkgX LogicalPkgX

master : Master poller : Poller d : DBaseServer cs : CommServer dBadmin : Admin

EngineeringPkgY EngineeringPkgY

Task1 : Task Task3 : Task Task2 : Task MainTask : Task

EngineeringPkgZ EngineeringPkgZ

«GRMschedulableEntity» Task

«import» «import» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize»

slide-168
SLIDE 168

168

EngineeringPkgY EngineeringPkgY

Task1 : Task Task3 : Task Task2 : Task MainTask : Task

Example: Completing the Mapping Example: Completing the Mapping

♦Mapping to hardware ♦ ♦Mapping to hardware Mapping to hardware

EngineeringPkgD EngineeringPkgD

«GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize» «GRMrealize»

«SAProcessingResource» Proc1

«GRMrealize» «GRMrealize»

slide-169
SLIDE 169

169

Summary: RT Design and Engineering Summary: RT Design and Engineering

♦In complex RT systems, the logical design is strongly influenced by the characteristics of the engineering environment ♦In such systems, it is often crucial to formally determine if a system will meet its non-functional requirements (throughput, response time, availability, etc.) ♦The QoS-based approach described here can serve as a basis for:

■ quantitative analysis of UML-based models ■ a real-time modeling standard that will facilitate automated

exchange between design and analysis tools

♦ ♦In complex RT systems, the logical design is strongly In complex RT systems, the logical design is strongly influenced by the characteristics of the engineering influenced by the characteristics of the engineering environment environment ♦ ♦In such systems, it is often crucial to formally determine if In such systems, it is often crucial to formally determine if a system will meet its non a system will meet its non-

  • functional requirements

functional requirements (throughput, response time, availability, etc.) (throughput, response time, availability, etc.) ♦ ♦The QoS The QoS-

  • based approach described here can serve as a

based approach described here can serve as a basis for: basis for:

■ ■ quantitative analysis of UML

quantitative analysis of UML-

  • based models

based models

■ ■ a real

a real-

  • time modeling standard that will facilitate automated

time modeling standard that will facilitate automated exchange between design and analysis tools exchange between design and analysis tools

slide-170
SLIDE 170

170

♦Real-Time Systems and the Object Paradigm

■ Real-Time System Essentials ■ Essentials of the Object Paradigm

♦UML as a Real-Time Modeling Language ♦The Real-Time UML Profile ♦Engineering-Oriented Design of Real-Time Systems ♦Summary and Conclusions ♦ ♦Real Real-

  • Time Systems and the Object Paradigm

Time Systems and the Object Paradigm

■ ■ Real

Real-

  • Time System Essentials

Time System Essentials

■ ■ Essentials of the Object Paradigm

Essentials of the Object Paradigm

♦ ♦UML as a Real UML as a Real-

  • Time Modeling Language

Time Modeling Language ♦ ♦The Real The Real-

  • Time UML Profile

Time UML Profile ♦ ♦Engineering Engineering-

  • Oriented Design of Real

Oriented Design of Real-

  • Time Systems

Time Systems ♦ ♦Summary and Conclusions Summary and Conclusions

slide-171
SLIDE 171

171

Summary: The Problem Summary: The Problem

♦Complexity! ♦The design of real-time systems is influenced significantly by the physical properties of:

■ the environment in which the system exists ■ the implementation technology

♦Most of them stem from the physical world

■ the physical dimension plays a major role in the design of real-

time software since it imposes limitations on the logical design

♦ ♦Complexity! Complexity! ♦ ♦The design of real The design of real-

  • time systems is influenced significantly

time systems is influenced significantly by the physical properties of: by the physical properties of:

■ ■ the environment in which the system exists

the environment in which the system exists

■ ■ the implementation technology

the implementation technology

♦ ♦Most of them stem from the physical world Most of them stem from the physical world

■ ■ the physical dimension plays a major role in the design of real

the physical dimension plays a major role in the design of real-

  • time software since it imposes limitations on the logical design

time software since it imposes limitations on the logical design

slide-172
SLIDE 172

172

Summary: The Solution (1 of 2) Summary: The Solution (1 of 2)

♦The object paradigm

■ reduces incidental complexity ■ its structural bias is better suited to the real-time domain than

the procedural paradigm

■ additional key features (encapsulation, inheritance,

polymorphism, etc.) add further expressive power

♦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

(through required environment specifications)

■ suitable for analysis and synthesis ■ enables early detection of critical design flaws

♦ ♦The object paradigm The object paradigm

■ ■ reduces incidental complexity

reduces incidental complexity

■ ■ its structural bias is better suited to the real

its structural bias is better suited to the real-

  • time domain than

time domain than the procedural paradigm the procedural paradigm

■ ■ additional key features (encapsulation, inheritance,

additional key features (encapsulation, inheritance, polymorphism, etc.) add further expressive power polymorphism, etc.) add further expressive power

♦ ♦Engineering Engineering-

  • oriented design
  • riented design

■ ■ accounts for the physical dimension during logical design

accounts for the physical dimension during logical design

■ ■ based on a quality of service (QoS) framework as represented

based on a quality of service (QoS) framework as represented in the generic resource model in the generic resource model

■ ■ allows de

allows de-

  • coupling from actual implementation technologies

coupling from actual implementation technologies (through required environment specifications) (through required environment specifications)

■ ■ suitable for analysis and synthesis

suitable for analysis and synthesis

■ ■ enables early detection of critical design flaws

enables early detection of critical design flaws

slide-173
SLIDE 173

173

Summary: The Solution (2 of 2) Summary: The Solution (2 of 2)

♦UML provides a common and standardized underpinning that supports all the components of our solution

■ for object-oriented modeling ■ for predictive QoS modeling (via the real-time profile) ■ 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 between specialized tools and is a basis for significant automation of the RT software development process ♦ ♦UML provides a common and standardized underpinning UML provides a common and standardized underpinning that supports all the components of our solution that supports all the components of our solution

■ ■ for object

for object-

  • oriented modeling
  • riented modeling

■ ■ for predictive QoS modeling (via the real

for predictive QoS modeling (via the real-

  • time profile)

time profile)

■ ■ for design analysis and synthesis (tool interchange)

for design analysis and synthesis (tool interchange)

■ ■ for architectural definition

for architectural definition

■ ■ for implementation (through full automatic code generation)

for implementation (through full automatic code generation)

♦ ♦Furthermore, as a standard, it enables model interchange Furthermore, as a standard, it enables model interchange between specialized tools and is a basis for significant between specialized tools and is a basis for significant automation of the RT software development process automation of the RT software development process

slide-174
SLIDE 174

174

Where to Obtain the RT Profile Where to Obtain the RT Profile

A copy of the real-time standard submission can be

  • btained from the Object Management Group website at:

http://www.omg.org/cgi-bin/doc?ad/2001-06-14 A copy of the real A copy of the real-

  • time standard submission can be

time standard submission can be

  • btained from the Object Management Group website at:
  • btained from the Object Management Group website at:

http://www. http://www.omg

  • mg.org/

.org/cgi cgi-

  • bin/doc?ad/2001

bin/doc?ad/2001-

  • 06

06-

  • 14

14

slide-175
SLIDE 175

175

Bibliography Bibliography

♦ Cooper, R., Introduction to Queueing Theory, The Macmillan Company, 1972. ♦ I. Jacobson, G. Booch, and J. Rumbaugh, “The Unified Software Development Process,”, Addison-Wesley, 1999. ♦ Klein, M. et al., A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993. ♦ OMG, “The Unified Modeling Language” version 1.3, The Object Management Group, August 1999. ♦ OMG, “UML™ Profile for Scheduling, Performance, and Time - Request for Proposal”, The Object Management Group, March 1999 (doc ad/99-03-13). ♦ UML Real-Time Consortium, “Response to the OMG RFP for Schedulability, Performance, and Time,” August, 2000 (OMG document ad/2000-08-04). ♦ J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling Language Reference Manual,”, Addison-Wesley, 1999. ♦ B. Selic, “Turning Clockwise: Using UML in the Real-Time Domain”, Communications of the ACM, vol.42, no.10, October 1999 (pp.46-54). ♦ B. Selic, “A Generic Framework for Modeling Resources with UML,” IEEE Computer vol.33, no.6, June 2000 (pp. 64-69). ♦ B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real-Time Systems,” ObjecTime Limited and Rational Software Corp., March 1998. (http://www.rational.com) ♦ ♦ Cooper, R., Introduction to Queueing Theory, The Macmillan Compa Cooper, R., Introduction to Queueing Theory, The Macmillan Company, 1972. ny, 1972. ♦ ♦ I. Jacobson, G.

  • I. Jacobson, G. Booch

Booch, and J. , and J. Rumbaugh Rumbaugh, “The Unified Software Development Process,”, , “The Unified Software Development Process,”, Addison Addison-

  • Wesley, 1999.

Wesley, 1999. ♦ ♦ Klein, M. et al., A Practitioner’s Handbook for Real Klein, M. et al., A Practitioner’s Handbook for Real-

  • Time Analysis: Guide to Rate Monotonic

Time Analysis: Guide to Rate Monotonic Analysis for Real Analysis for Real-

  • Time Systems, Kluwer Academic Publishers, 1993.

Time Systems, Kluwer Academic Publishers, 1993. ♦ ♦ OMG, “The Unified Modeling Language” version 1.3, The Object Man OMG, “The Unified Modeling Language” version 1.3, The Object Management Group, agement Group, August 1999. August 1999. ♦ ♦ OMG, “ OMG, “UML™ Profile for Scheduling, Performance, and Time - Request for Proposal”, The The Object Management Group, March 1999 (doc ad/99 Object Management Group, March 1999 (doc ad/99-

  • 03

03-

  • 13).

13). ♦ ♦ UML Real UML Real-

  • Time Consortium, “Response to the OMG RFP for Schedulability, Pe

Time Consortium, “Response to the OMG RFP for Schedulability, Performance, rformance, and Time,” August, 2000 (OMG document ad/2000 and Time,” August, 2000 (OMG document ad/2000-

  • 08

08-

  • 04).

04). ♦ ♦ J.

  • J. Rumbaugh

Rumbaugh, I. Jacobson, and G. , I. Jacobson, and G. Booch Booch, “The Unified Modeling Language Reference , “The Unified Modeling Language Reference Manual,”, Addison Manual,”, Addison-

  • Wesley, 1999.

Wesley, 1999. ♦ ♦ B. Selic, “Turning Clockwise: Using UML in the Real

  • B. Selic, “Turning Clockwise: Using UML in the Real-
  • Time Domain”,

Time Domain”, Communications of the Communications of the ACM, ACM, vol.42, no.10, October 1999 (pp.46 vol.42, no.10, October 1999 (pp.46-

  • 54).

54). ♦ ♦ B. Selic, “A Generic Framework for Modeling Resources with UML,”

  • B. Selic, “A Generic Framework for Modeling Resources with UML,” IEEE Computer vol.33,

IEEE Computer vol.33, no.6, June 2000 (pp. 64 no.6, June 2000 (pp. 64-

  • 69).

69). ♦ ♦ B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real

  • B. Selic and J. Rumbaugh: “Using UML for Modeling Complex Real-
  • Time Systems,”

Time Systems,” ObjecTime Limited and Rational Software Corp., March 1998. (http ObjecTime Limited and Rational Software Corp., March 1998. (http://www.rational.com) ://www.rational.com)