UML and Real Time pdf – Cours et formation gratuit

UML and Real Time

• François Terrier, Sébastien Gérard

• DRT-LIST/DTSI/SLA/LLSP, CEA/Saclay, F-91191 Gif sur Yvette Cedex France

Phone: +33 1 69 08 62 59 ; Fax: +33 1 69 08 83 95

• [email protected] ; [email protected]

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

(TAU UML Suite, ARTiSAN Studio, Rhapsody ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

RT in UML 1.4

•Quantitative aspects

 TimeEvent in state-machine

 Timing mark in Sequence Diagram

 Qualitative aspects

 Concurrency : Active object, Concurrent state, …

 Discrete behavior via state machines

and activity diagrams

 Attempts of integrating continuous behavior

within activities of state-machines

Status of the UML2 proposals

 Two remaining main prop. for Infra/Super

 U2 group (www.u2-partners.org )

Infrastructure  latest version is v.2.0 beta R2 released 2002/06/02

 2U group (www.2uworks.org )

Infrastructure  latest version is v0.81 released 2002/07/02

 Helsinki meeting (End of September 2002)

 1st revised submission presentation for Superstructure

 2nd revised submission presentation for Infrastructure

 UML2 RFP split into 4 parts

 UML 2.0 OCL  UML 2.0 Diagram Interchange

 UML2 Infrastructure  core language of UML

 UML2 Superstructure  state-machine, sequence diag., …

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

(TAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

 Proposers and supporters

 ARTiSAN, I-Logix, Rational, Telelogic,

TimeSys, Tri-Pacific, CEA-LIST

 Main concepts

 resources & quality of service (QoS)

 uniform basis to attach quantitative information to UML specifications (e.g. required for RT analysis performing)

Client

Client _{S1 S1} ^{S1 S1} ResourceA ResourceA _{S2 S2} ^{S2 S2} ResourceB ResourceB ResourceB ResourceB

CPU CPU

CPU

Physical Processor Physical Processor

 Not THE Real Time UML profile… !

Scheduling, Performance & Time Profile

Current architecture of UML SPT profile

 General Resource Sub-profile

( Defines abstract concepts of Resource & QoS)

• Resource concept has been developed

• QoS concept remains abstract !

 General Time Sub-profile

 General Concurrency Sub-profile

Generic sub-profiles for real-time applications

Specific sub-profiles for dedicated activities

around real-time

application development

• Performance Sub-profile

• Schedulability Sub-profile

 Consists of 5 sub-profiles

SPT base concept  QoS

• Use example of the QoS concept in a model

ResourceService 0..n

0..n +offeredQoS

Resource 0..n

0..n ResourceUsage

0..n +requiredQoS 0..n 0..n

0..n

1..n

0..n 1..n

0..n

QoSCharacteristic (Abstract class !)

/:SRV

aDriver/:Driver regOutput/:Display

start

display

«RTaction»

{RTstart=(10, 'ms')}

Required QoS

display():

«SAAction»

{SAWorstCase=(25,'ms'), RTduration=(5,'ms')}

Offered QoS

Issues relating to QoS within SPT prof.

 QoS remains an abstract concept

 never concretized by other SPT sub-profiles

 Specific sub-profiles

(Schedulability, Performance, RT-CORBA)

• defines implicitly required QoS (eg. TVs SAPriority, SADelay, …)

• but no links with the QoScharacteristics concept !

 SPT does not proposes solutions to specify:

• domain specific QoS characteristics quantifiables with specific values (e.g. capacity of fligth plan manag

, antenna sign. accuracy)

• QoS contracts in subsystems, components and use cases

• QoS modes the systems supports: adaptations & QoS levels

• monitoring of QoS values and their impact in the architectures

<<metamodel>>

QoSCharacteristics

<<metamodel>>

QoSContracts

<<metamodel>>

QoSM odes

RTResourceM odeling

<<metamodel>>

QoSAdaptation

<<metamodel>>

QoSCharacteriscCore

<<metamodel>>

QoSContexts

CoreResourceM odel

Architecture of QoS (& Fault Toler.) prof.

What are you talking about?

1

What we need to take into account?

2

What can you do?

What do you want?

3

What happen when ...?

5

How can you execute?

4

RT refactoring in UML

Schedulability Analysis Performance Analysis Code Generation

Specific sub-profiles for dedicated activities around real-time application development

…

 3 points:

Generics for RT domain

QoS & Resource

Concurrency Time Throughput/Performance Lantency

...

1

<<metamodel>>

QoS & Resource MM

<<profile>>

QoS & Resource SP

MOF UML MM

<<instantiate>>

2

UML 2

RT package

?

3

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

 TAU UML Suite

ARTiSAN Studio, Rhapsody, ROSE RT, Esterel Studio

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

Passive objects  Abstract Data Types of SDL Active object declarations  SDL processes

ActuatorContr RegContr ol

ol [cmd

]

C1

SensorContr ol

[speed

C2 ]

ActuatorContr RegContr ol

ol

SensorContr ol

pRC 1

pAC 1

RegulatingLa w

pAC 1

Newtype RegulatingLaw Operators

calculate : Speed, Speed ->

TorqueVariation endnewtype:;

SpeedRegulator_Behavior

On

stopRegulating()

/ updateScreen(OFF);

Of

startRegulating()

targetSpeed / = returnValue;

Stoppe d

Runnin g

Stoppe d Runnin g stopRegulating

updateScreen(OFF)

startRegulating targetSpeed = returnvalue

TAU UML/SDL Suite

 UML modeling is used at the first modeling stage,

SDL used for design…

TAU UML/SDL Suite : conclusions

• How to ensure independency

between model and implementation ?

• Timing specifications:

 only with low level implementation mechanisms ( Timers, SDL priorities… )

 UML/SDL: mapping is under user responsibility

… he has to clarify the mapping of

 UML state machines  SDL specifications

 Use of shared passive objects in UML model  SDL

 Active object communication  SDL signal exchange

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

TAU UML Suite,

 ARTiSAN Studio

Rhapsody, ROSE RT, Esterel Studio

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

An explicit task model in a specific diagram

Actuator

control Motor

Actuator Control

calculation Speedmeter

control Channel1

Speedmeter PMH

Explicit modeling of concurrency features !!!

A logical model in usual class/object diagrams

 Concurrency diagram

::Regulator stopRegulating() startRegulating()

::RegulatingLaw calculate

* pRegLaw

ARTiSAN Real-time Studio

 two orthogonal models, weak integration

 making schedulable objects & scheduling them using tasks

 wrapping data and functions in object wrappers

A mapping stage  assignment of objects to tasks

Actuator

control Motor

Actuator Control

calculation Speedmeter

control Channel1

Speedmeter PMH

::Commande update

read

::RegulatingLaw calculate

* pRegLaw

regLaw:Commande update()

read() Actuator

control Motor

Actuator Control

calculation Speedmeter

control Channel1

Speedmeter PMH

 encapsulating tasks & their communications behind interf.

Three techniques

ARTiSAN Real-time Studio

Timing constraints must be translated on implement.

 Communication between objects of diferent tasks must be implemented by the user with low level RT concepts

ARTiSAN Real-time Studio: conclusions

Relation between task and object model is weak Task model has to be manually implemented

Concurrent diagram is out of the standard

A tool dedicated to high skill real-time developers with a lot

of things to be done by hand and at the standard borders.

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

TAU UML Suite, ARTiSAN Studio,

 Rhapsody,

ROSE RT, Esterel Studio

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

 Identify system task

 Populate tasks with objects of analysis and design stages

Rhapsody (RT-UML)

 two «orthogonal» but «integrated» models Explicit modelling of concurrency

 Inter tasks communication = Synchro. + data exchange

Rhapsody (RT-UML)

ActuatorControl

« reactive

»RegContr ol

SensorControl pRC 1

pAC 1

RegulatingLaw pAC

1

RegControlTask RegControl

ActControlTask

ActuatorControl

SpeedRegulator_Behavior

On

stopRegulating()

/ updateScreen(OFF);

Off

startRegulating()

/ targetSpeed = returnValue;

SpeedRegulator_Behavior

On

stopRegulating()

/ updateScreen(OFF);

Off

startRegulating()

/ targetSpeed = returnValue;

 Behavior specified by state machine of reactive

 obj. Reactive objects are assigned to active objects…

 Communication by message between reactive obj.

SensorControl

 Explicit tasking model (described & maintained by hand)

 Communication issues

 Triggered operation : concept between event & operation

 Only return value of operation call can be defined …

… but under responsibility of the caller ! (cf. conc. conflict)

 Complex semantic dif. between signals & operation calls

 Low level of Real Time specifications

 Priorities can be assigned to active objects

 Timing constraints must be implemented by hand

A tool dedicated to high skill real-time developers with animation opportunities but not really “real-time”.

Rhapsody (RT-UML) : conclusions

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

TAU UML Suite, ARTiSAN Studio, Rhapsody

 ROSE RT,

Esterel Studio

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

Rose Real-Time (UML-RT)

 attempt to integrate task and object paradigms

 «capsule» stereotype identifies active objects

 They will be assigned to task at implementation stage

 mapping with task & priorities must be managed by hand

 They have state automaton but low level timing specification

 Defines the set and protocol of the exchanged messages

 Communication is performed through « ports »

 Sending of signal via port of communication

« capsule »

anEmitter : Emitter

State 1

State 2 portA.send (s1) ; Signal sending

Communication port

« protocol » infoProto

incoming

S1

Protocol

portA : infoProto

portB : infoProto~

capsule link

« capsule »

aReceiver : Receiver

Behaviour

/ aSpM : Speedometer + / carSpeed

: SpdAcq / aReg : Regulator

+ / carSpeed : SpdAcq~

Initiated

Initial Initial

t3 t3 get

value (data)

Off Inter

Initial

t1

Trigger:

Signal get on port carSpeed Action:

carSpeed->value(data).reply();

Action:

RTMessage retMsg;m

carSpeed.get().invoke(&retMsg);

int newCarSpeed= *(const int *)

retMsg.getData();

t1

A synchronous communication with return value

 blocked until reply receipt  release by reply receipt

Synchronous call with reply

Rose Real-Time (UML-RT)

Not to forget « reply » action on server side !

Rose Real-Time (UML-RT): conclusions

 A high level concept for concurrency with an implicit logical execution model  Capsule

 "Unusual" OO paradigm

The concept of “Capsule” is certainly very powerfull but a little bit “exotic” regarding usual OO paradigm (eg. For communication). About RT constraint spec., it is equal to other, i.e. only timing event, because the concept of priority

Capsule paradigm

Entities communicating via signal exchange through ports.

vs.

Usual object paradigm Entities communicating via operation call.

Behavior spec. via limited UML state machine

Timing specification through low level mechanisms

… but close to an Interface with Protocol State Machine

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

TAU UML Suite, ARTiSAN Studio, Rhapsody, ROSE RT,

 Esterel Studio

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

Esterel Studio

 A "graphical form" equivalent to Esterel

• S_Capsule (“Synchronized_Capsule”)

 Inherited from ROOM’ Capsule

 Get ports typed by a “pluget” (~ ROOM Protocol)

• Concurrent components inside behavior

• SyncChart

 A "graphical form" equivalent to Esterel language

 Synchronous computation model

 The Zero-Delay hypothesis

 Absence of event may be a trigger

Esterel studio (SyncCharts)

Running

suspensio n

macro- state

simple state

initial pseudo- state

final state

weak abortion strong

abortion s / e

parallel

component

suspend

normal

terminaison

/ e

transition

label

Esterel studio (SyncCharts): conclusions

• Based on an abstract ideal view of real systems “Synchronous assumption”

 Convenient for “hardware-intensive” systems

 Difficult to insure in other case

• Behavior = SyncChart formalism

 Formal view  possibility of formal verification

 Out of UML standard (notation + semantics)

• Methodology aspect under-development

• The tool support only behavior aspect

 Prototype of coupling with Rose

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

(TAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

ACCORD/UML methodology

- Results of 10 years of OO researches for RT-Syst.

of nuclear plant + PhD work with PSA (Peugeot) + AIT-WOODDES IST Eur. proj. + ACOTRIS a Nat. proj.

 Provides

 Modeling methodology:

continuous process, separation of functional spec.

and implementation constraints or choices

 Tools supporting the process and the method

 Model transform., code gen. for rapid prototyping

 Model analysis, test generation

 Protocol state machine in UML

 Protocol transitions have the following info.:

 a pre condition (guard)

 one or several triggering event

 a post condition. Every

 zero or one operation that belongs to the

context classifier of the protocol state machine.

 It can be associated to Interfaces and Ports

 expresses legal transit. a classifier can trigger

 defines a lifecycle for objects

or an invocation order of its operations

unObjet operation()

« signal » Signal()

E

‘Evt’ ‘[’ garde ‘]’ / ‘liste-Actions’ E

CallEvent

CallEvent SignalEvent ChangeEvent

TimeEvent

operation() Signal()

Maintainability Reusability  

C

Off On

initReg[cptVit->getSpeed()=<30]

/display("ON");

stopReg/display("OFF");

tm(100)/tgSpeed = cptVit->getSpeed();

[carSpeed=<30]/display("OFF");

/delta=k1*atan(tgSpeed-cuSpeed);

mot->sendCmd(coupleVariation);

tgSpeed : int initReg()

stopReg() Regulator

Logic

Logic & Algorithmic Algorithmic

Usual way to use the state machine …

… UML state machine notations

• Separation on concerns to improve behaviour modelling

Protocol View

"what it can do"

Reactive View

"what it must do"

Object behaviour

Algorithmic aspect Logic aspect

AIT-WOODDES / ACCORD proposal :

 a more structured way !

Control logic & Algorithms aspects

Arret Marche

C

Arret Marche

initReg[cptVit->getSpeed()=<30]

/display("ON");

stopReg/display("OFF");

tm(100)/tgSpeed = cptVit->getSpeed();

[carSpeed=<30]/display("OFF");

/delta=k1*atan(tgSpeed-cuSpeed);

mot->sendCmd(coupleVariation);

Logic

Logic & Algorithmic Algorithmic

« describe protocol view »

tgSpeed : int initReg()

stopReg() Regulator

Off On

initReg() stopReg()

maintainSp()

Class behavior

Control logic (protocol use) =

Protocol-transition

call-event ‘(’params‘)’ ‘[’ guard ‘]’

Method behavior Algorithmic parts =

carSpeed = cptVit-

>getSpeed()

delta=k1*atan(tgSpeed- cuSpeed)

mot-

>sendCmd(torqueVariation)

Maintainability 

Reusability 

Regulator +tgSpeed : integer +initReg()

+stopReg() +maintainSp()

Regulator interface

/ maintainSp() RegOnOff /

stopReg()

RegOnOff / initReg()

On Off

[carSpeed<50] / stopReg()

Triggering view (ACCORD/UML)

• ChangeEvent

• CompletionEvent

• SignalEvent

• TimeEvent

Set of consistent rules between protocol and triggering views

Class interface

Regulator +tgSpeed : integer +initReg()

+stopReg() +maintainSp()

« Signal » RegOnOff()

‘evt-name ’ ‘(’param-list‘)’ ‘[’ guard ‘]’ / <ope- name> ‘(’params‘)’

Triggering-transition

« describe reactive view »

S

S

‘call-event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’

S

S

‘event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’

/ called-operation-name ‘(’param- list‘)’

Trigger view (ACCORD/UML)

“What the instances of this class = have to do”

Class

m

()

S

S

m

()

Class structure

Class behavior control logic =

Protocol view (UML ~standard)

“What instances of this class = may do”

Method view (~UML standard)

= How processing is performed

Summary on ACCORD behavior model

act

act

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

(TAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

Decomposition heuristics

& component model

Initial Model Initial Model

ACCORD/UML (PAM ou DAM) ACCORD/UML (PAM ou DAM)

Sub-system Model

Sub-Syst_1 Sub-Syst_2

Sub-Syst_3

«refine

»

ER1

C_Sub-Syst_2

C_Sub-Syst_3 Component Model

«parts»

ER2

ER1 = Heuristics to ease

decomposition of a system into a sub- systems model

ER1 = Heuristics to ease

decomposition of a system into a sub- systems model

ER2 = Model mappings to transform resulting sub-systems model into

component model

- required & offered interface

ER2 = Model mappings to transform resulting sub-systems model into

component model

- required & offered interface

Component definition

 2 possible views:

-“Black box” (= external view)  set of interfaces

-“White box” (= internal view)

 sub-system

Component

• Component Model based on

UML2 component Model + RT_QoS

ACCORD/UML RT-Component Model

Interface

provided required

RT_QoS

 Interface can have both BehavioralFeatures:

• operations also with QoS specif.

• receptions (signals) with QoS specif.

ACCORD/UML RT-Component Model based on a MDA approach…

ER3 = Mappings from the RT-Comp. Mod. of ACCORD/UML towards a platform model (e.g., RT-CCM model)  PIM-to-PSM

RT_QoS

RT_QoS RT_QoS

C_Sub-Syst_1

C_Sub-Syst_2

C_Sub-Syst_3 Component Model

ER2

RT_QoS

RT_QoS

Sub-system Model

Sub-Syst_1 Sub-Syst_2

Sub-Syst_3

RT_QoS

RT_QoS

ER2 = These mappings take into account specified RT

features of the sub-system model  PIM-to-PIM ER2 = These mappings take into account specified RT

features of the sub-system model  PIM-to-PIM

CCM

ER 3

Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML

(TAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML

 Protocol state machine

 RT Component Model

 MDE through UML profiles

MDA Challenges

 Methods to define well-structured models

 Business oriented (versus software techn oriented)

 Activity oriented: req/spec/design/impl/proof/test/simul, etc.

 Techniques to exploit development expertise

 Profile, script, meta-modeling, aspect progr., etc.

 Expertise implementation (RT, emb., safety, valid., etc.)

 Implementation platform models (CCM, RT-OS, etc.)

 Tooling & standards (interf., coop., interact., exch., etc.)

 What MDA means:

modelling with UML to develop a system with

• a clear separation of implementation technology

• following a continuous modelling process

• using intensively model synthesis

 What we need :

ACCORD/UML methodoology:

Models everywhere…

Prototype Model

Tr ain Con

trol Cir cuit

STRU CTUR E INTER ACTIO NS

COMPOR TEMENT

S Application Code

Code Mappings Compiling & Link Mappings

Executable Application Design Mappings

Analysis Model

Tr ain Con

trol Cir cuit

STRU CTUR E INTER ACTIO NS

COMPOR TEMENT S

1 2 3

A pp lic at io n sy nt he si s

Test Model

INTERACTI

Formal Language ONS

of AGATHA

SET2UML Mapping UML2AGATHA Mappings

Analysis model

Tr ain Con

trol Cir cuit

STRU CTUR E INTER ACTIO NS

COMPOR TEMENT

S Symbolic Execution Tree

T es t S yn th es is

user

!

+

Structure of ACCORD Methodology

ACCORD/UML Methodology relizes

Modelling tools defined by

ACCORD/UML Profile

OMG’ Standard profiles !!!

SPE profile

SPT profile AL profile

ACCORD/UML profile

for Embedded Systems

► Real-time QoS model

• The domain viewpoint

- Model overview - Model details

• The UML viewpoint

- Stereotypes and tagged values definition - Tagged Value Types

► Communication model ► Behaviour model

► Concurrency model

Real-Time QoS Model

Communication Model Behavior Model

Concurrency Model

Real-time features model

domain viewpoint overview

• Definifion of a Real-Time QoS

TimingRTF ReadyTime

Deadline

SPTprofile::Core Ressource Model

QoScharacteristic

PriorityRTF

Priority Period

RTF generic concept of RT Priority-based RT QoS

QoS Timing-based RT

QoS

Real-time features model

domain viewpoint details

• PriorityRTF

Attributes Operations

- create ( ref in RTtimeValue, pr in Priority, pe in Period=-1, peNb=-1 in integer ) : It create an instance of priority-based RTF according to values passed as parameters. “pr” is the priority, “pe” is the period and “peNb” is the number of period of the new instance.

Associations

- itsPr:Priority (1-1): It denotes the priority feature of the current priority RTF.

- itsPe:Period (0-1): It denotes the period feature of the current priority RTF if necessary.

PriorityRTF RTF

Priority Period +create(In pr:Priority ,In pe:Period ,In peNb:integer)

itsPr 1 itsPe

0..1

► RT_QoStype  “(“ <timingQoS> | <priorityQoS> ”)

<timingQoS> ::= “(“ <RefDate> “, “ <Deadline> “, “ <ReadyTime> “,“ <Period> “, “

<NoPeriod> ”)”

<priorityQoS> ::= “(“ <Priority> “, “ <Period> “, “ <NoPeriod> ”)”

<RefDate> ::= “(RefDate, “ <value> “, “ <timeUnitStr> ”)”

<Deadline> ::= “(Deadline, “ <value> “, “ <timeUnitStr> ”)”

<Priority> ::= “(Priority, “ <value> ”)”

<ReadyTime> ::= “(ReadyTime, “ <value> “, “ <timeUnitStr> ”)”

<Period> ::= “(Period, “ <value> “, “ <timeUnitStr> ”)”

<NoPeriod> ::= “(NoPeriod, “ <value> “, “ <timeUnitStr> ”)”

<value> ::= <Integer> | <Real>

<timeUnitStr> ::= “ ’ns’ ” | “ ’us’ ” | “ ’ms’ ” | “ ’s’ ” | “ ’hr’ ” | “ ’days’ ” | “ ’wks’ ” | “

• RTF

Real-time features model – UML viewpoint

Stereoty pe

BaseClas s

Parent Tags

«RTF» Action   RTF_value

  Transition    

  Message Tag    

Name

Tag Type Multiplicit RTF_value RT_QoStyp y

e

[0..1]

From SPT Profile

Conclusions

• Industrial tools support model based development

 Modelling is not new !

 Moderation around the new key-word MDA

… but MDA not supported, they are too limited on:

 Model analysis,

 Model transformation and mappings

 Platform independent model writing

• UML 2:

 better for RT, but not a RT formalism!

 Should better support profile definition and, thus, MDA

 Strong lacks on the model exploitation language

 No graphical formalism at this time

 No standard and very "tool dependent"