Bran SelicObjecTime Limited

bran@objectime.on.ca

Real-TimeObject-Oriented

Modeling

2

• Real-Time Systems and Architecture

• The ROOM Modeling Concepts

• Development Process

• Summary

Tutorial Structure

3

General Real-Time System

Physical Elements

Sensor Sensor Effector Effector

SW Agent SW AgentSW Agent

SW Machine

SW Machine

SW Machine

SW Machine

SW MachineSW Machine

SW Machine

SW Machine

4

Software Architectures

Physical Elements

Sensor Sensor Effector Effector

SW Agent SW AgentSW Agent

SW Machine

SW Machine

SW Machine

SW Machine

SW MachineSW Machine

SW Machine

SW Machine

5

What is an Architecture?

• Architecture: an abstract specification that constrainsthe structural and behavioral patterns of all systemcomponents

• Key to proper construction and evolution

FunctionalSpace

version 1

version N

version 3

version 2

Architecture A

Architecture B

6

An Example Architectural Specification

WaitingForReset

Entering2ndStr

Entering1stStr

Ready

timeout

initialize

displayMsgresetDisplay

enterKeyenterKey

key

entrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

database

console

ctrlrs

console

dbaseuser1

keypad

user2keypad

user3keypad

User KeypadDisplay AccessController GateController PWDatabase

msc SuccessfulAccessScenario

timeout

key

key

key

key

entryReq

displayMsg

resetDisplay

validationReq

valid

unlock

lock

High-Level System Structure Behavior

Scenarios(Use Cases)

7

The Fate of Most Architectures...

main () {

BitVector typeFlags (maxBits);

char buf [1024];

cout << msg;

while (cin >> buf) {

for (int i = 0;i<maxBits;i++)

if (strcmp(typeTbl[i],buf)==0)

{typeFlags += i;

break;

}

if ... #❉✯!❽♠ !

8

• Interpretation errors

- “Hmm, I wonder what that bubble means?”

• Feasibility (technological) limitations

- “And, here, a miracle occurs...”

- “To simplify analysis, we will assume...”

• Translation errors

- “Oops!”

• Design changes

- “I’ll show those ivory-tower types how to do it right...”

Why Architectures Fail

9

Modeling and the Development Cycle

• Traditional view

• Characterized by semantic gaps that discouragerecursion and introduce errors

High-Level(Architectural)

DetailModeling

Modeling

Analysis&Design Implementation

ProgrammingLanguages

Compilation & LibraryStructures

Development Activity

Scope

High-LevelModeling Notations

DetailMod. Notations +ProgrammingLanguages

10

• Real-Time Object- Oriented Modeling

• Two level scheme with formally defined relationshipsbetween levels

• Incorporate standard programming languages (e.g.,C++) for detail modeling

Analysis&Design Implementation

ProgrammingLanguages

ROOMSchematic ModelingLanguage

High-Level(Architectural)

DetailModeling

Modeling

The ROOM Approach

11

• A method for developing software for real-timedistributed systems

- suited for event-driven systems

- full-cycle method (A D I)

- uses a formal graphical modeling language

- suited for computer-based automation:

-- executable models

-- automatic code generation

• Originated in Bell-Northern Research

ROOM

REAL-TIMEOBJECT-ORIENTEDMODELING

Bran Selic, Garth Gulleksonand Paul T. Ward

WILEY WILEY PROFESSIONAL COMPUTING

12

WaitingForReset

Entering2ndStr

Entering1stStr

Ready

timeout

initialize

displayMsgresetDisplay

enterKeyenterKey

keyentrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

database

console

ctrlrs

console

dbaseuser1

keypad

user2keypad

user3keypad

User KeypadDisplay AccessController GateController PWDatabase

msc SuccessfulAccessScenario

timeout

key

key

key

key

entryReq

displayMsg

resetDisplay

validationReq

valid

unlock

lock

Architectural LevelLanguage (ROOM)

Detail LevelLanguage

Two Levels of Modeling

e.g. C++

Modeling in ROOM

13

• The structural aspect of architectures tends to beobject-based

• The object paradigm is a synergistic combination ofproven, useful concepts

- encapsulation, polymorphism, inheritance...

• The potential for re-use

- formally supported only in implementation-levelprogramming languages

- can it be used at the architectural level?

-- e.g., can an architecture be inherited?

Why Object-Oriented?

14

• Real-Time Systems and Architecture

• The ROOM Modeling Concepts

• Development Process

• Summary

15

The Question of Notation...

“By relieving the mind of all unnecessary work, a

good notation sets it free to concentrate on more

advanced problems, and in effect increases the

mental power of the race”

- Alfred N. Whitehead

16

• Objects that carry information about some event

• Message-based communication is well-suited todistributed systems

“Fire”

Street: Elm St.

Number: 10

“ACK”

Signal

Data object(optional)

Location

Messages

17

• A message in transit is assigned a priority thatidentifies the significance of its event

• Required to support timely responses

“Fire”

Street: Elm St.

Number: 10

Location HIGHPRIORITY

Message Priorities

18

Object Types

PASSIVE- messages

- Detail Level data

ACTIVE- actors- own execution thread

(concurrent)

19

• The active objects of ROOM are called actors

• Actors can send and receive messages through distinctinterfaces called ports

PORTS

INCOMINGMESSAGE

OUTGOINGMESSAGE

ACTORENCAPSULATIONSHELL

Actors

20

• Each interface of an actor has a unique name and anassociated protocol

• Different interfaces can use different protocols

• An actor can present different “views” of itself todifferent collaborators; e.g.:

serviceIF3serviceIF2serviceIF1

controlIFCONTROLINTERFACE PORT

SERVICEINTERFACE PORTS

Actor Interfaces

21

• An extension of conventional interface concept basedon message exchange sequences

• A protocol is defined by:

- a set of valid message types and their directions of flow

- a set of valid message sequences (future extension)

Protocols

22

• Message sequences are expressed by MessageSequence Charts (MSCs)

• Defined by ITU standard Z.120

Comedian StraightMan

msc Joke

KnockKnock

WhosThere

Boo

BooWho

PleaseDontCry

Message Sequence Charts

23

• Sometimes different actors use the same protocoldefinitions

• It is convenient to define protocols independently ofthe actors that use them through protocol classspecifications

• Each port (actor interface) has a type that is definedby its protocol class

• Protocol classes represent reusable interfacespecifications; this is the basis for a type ofpolymorphism available in ROOM

Protocol Classes

24

• The collection of all interface types of an actordefines its type

• This is a basis for a form of genericity

serviceIF3serviceIF2serviceIF1

controlIF

Actor Types

25

• The object paradigm allows us to combine objects tocreate more complex systems

• The connections between ports are called bindings

entrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

databasectrlrs

Combining Actors — Actor Structures

26

• Abstract representations of establishedcommunication channels for exchanging messagesbetween actors

• Only ports with compatible protocols can be bound

- Usually, a protocol class and its conjugate

• Bindings explicitly identify all valid causal linkagesbetween actors

• Semantics of bindings are defined by the protocolclasses of the ports

Bindings

27

• If the functionality of an actor is complex, it may beuseful to break it down into simpler components

• Actors can be defined recursively !

axCtrlrkeypad

gate

dbase

gateCtrlrctrlr

keypaduser

axCtrlr

dbase

user

entrance2dbaseuser

databasectrlrs

Looking Inside Actors

28

• As with protocols, it is often useful for multiple actorsto share a common specification

• This is achieved through actor classes

• ROOM distinguishes between the class and the typeof an actor

actor class = actor type + actor implementation

Reusing Specifications — Actor Classes

29

• Actors can either relay messages to internalcomponents or handle them directly

• All messages arriving on relay ports are forwardedautomatically

• Alternatively, messages arriving on an end port areprocessed by the actor

keypadkeypad

user

axCtrlruser

Handling Messages and Port Types

30

• End ports are the access points to the behavior(component) of an actor

• Identified by a distinct graphical notation

• The behavior component is implicit; i.e., it is notexplicitly rendered in a diagram

keypad gate

dbase

End Ports and Behavior

31

• Between successive events, the behavior isquiescent, “listening” for incoming messages

• When a message arrives, the behavior is activatedand may respond by sending one or more messagesof its own through its ports

Wait for NextMessage

HandleMessage

The Behavior of Reactive Systems

32

• What happens if a new higher priority event arriveswhile the previous event is being processed?

• Two options:

- preemptive paradigm interrupts current event handling

- run-to-completion paradigm finishes handling thecurrent event handling before moving on to the newevent

• ROOM uses the run-to-completion paradigm

Execution Paradigms

33

ROOMcharts

DoorOpen

Validating

Ready

initialize

timeout

invalid

valid

entryReq

axCtrlrkeypad

gate

dbase

gateCtrlrctrlr

keypaduser

axCtrlr

dbase

user

Wait for NextMessage

HandleMessage

34

• Each transition has

- a trigger which specifies the message arrival event(s)that causes the transition

- optionally, an action that specifies how the event ishandled

• The action specification belongs to the Detail Leveland uses the programming level of choice (e.g., C++)

Events, Triggers, and Actions

35

• In addition to temporary variables that may beassociated with an action, ROOMcharts also allow thedefinition of extended state variables

• Variables are passive objects used to store DetailLevel information that needs to be retained betweentransitions

- for example, instances of C++ object classes

Extended State Variables

36

• Hierarchy is a means of dealing with complexity byfocussing on only a manageable chunk at a time

CP1

EnteringKeys

enterKey

key

false

true

key

key

WaitingForReset

Entering2ndStr

Entering1stStr

Ready

timeout

initialize

displayMsgresetDisplay

enterKeyenterKey

key

Hierarchical States

37

• A “shorthand” form for equivalent transitions thatemanate from a common state

• Group transitions not only reduce visual clutter butoften also identify “higher-order” events and providehints about potential state aggregations

S1

S2 S2

S0

e

e

e

S1

S2 S2

S0e=

Behavior — Group Transitions

38

The Effectiveness of ROOMcharts

A1

A2

a1a2

B1

B2

b1b2

BA

a

b

A1|B1

A2|B1

A1|B2

A2|B2

B1|A1

B1|A2

B2|A1

B2|A2

b

a

b

a

b

a

b

a

a2

a1b1b2

a2

a1 b1b2

“FLAT” STATE MACHINEEQUIVALENT:

(8 states, 16 transitions)

ROOMCHART:(6 states, 6 transitions)

For a 3-state equivalent: 9 states and 12 transitions (vs. 24 and 72)!

=

39

• Each of the following class types has a distinct classhierarchy

- Actor classes

- Protocol classes

- Data classes

• The rules of inheritance are not uniform in the threedifferent hierarchies

Inheritance Hierarchies in ROOM

40

entrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

database

console

ctrlrs

console

dbase

user1keypad

user2keypad

user3keypad

Actor Class Inheritance — Structure

entrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

databasectrlrs

Gray pen used toindicate inherited attributesin subclass

SUBCLASS

CLASS

NEW ATTRIBUTESIN SUBCLASS

41

Actor Class Inheritance — Behavior

On

Off

off

on

On

Off

initializeoff

on

42

On

Off

initializeoff

on

Refinement of Behavior in Subclasses

Operational

PoweringUp

off

initialize

on

on

done

SUBCLASSREFINES A “LEAF” STATEIN THE SUPERCLASS

43

• Useful for dealing with regular repeating structures

database

console

ctrlrs

console

dbase

kNumGates

entrancesdbaseuser

kNumGates ACTORINSTANCES

kNumGates PORTINSTANCES

Replicated Structures

44

Dynamic Structure — Optional Actors

• Components may be created after their container asneeded

• Creation/destruction controlled by the container

45

Multiple Containment and Importing

• Captures components that are simultaneously part oftwo or more container actors

• Component actors are “slots” to be filled as needed

Call

TelephoneYTelephoneXTelephones

n

EQ1

EQ2

TelephoneSystem “IMPORTED” Actor

“REPLICATED” Actor

46

Generic Structures

• Ability to define a component as “generic”

• Any actor with a compatible type can be imported intothe generic “slot”

• A single model represents a collection of possiblevariants

Call

TelephoneYTelephoneX

++

47

Layering

• Layer relationships:- Directed hierarchical relationship

- For modeling widely-shared implementation services

• Reduces apparent complexity

• Communication model also based on protocols andport-like interfaces ( Service Access Points (SAPs))

A

B C D

SharedService

E

A

B C D

SharedService

E

48

• Real-Time Systems and Architecture

• The ROOM Modeling Concepts

• Development Process

• Summary

49

Typical Current Development Micro-Cycle

RequirementsSpec

WaitingForReset

Entering2ndStr

Entering1stStr

Ready

timeout

initialize

displayMsgresetDisplay

enterKeyenterKey

key

User KeypadDisplay AccessController GateController PWDatabase

msc SuccessfulAccessScenario

timeout

key

key

key

key

entryReq

displayMsg

resetDisplay

validationReq

valid

unlock

lock

User KeypadDisplay AccessController GateController PWDatabase

msc SuccessfulAccessScenario

timeout

key

key

key

key

entryReq

displayMsg

resetDisplay

validationReq

valid

unlock

lock

entrance1dbaseuser

entrance2dbaseuser

entrance3dbase

user

database

console

ctrlrs

console

dbaseuser1

keypad

user2keypad

user3keypad

+-

GenerateScenarios

Derive structure

Derivebehavior

Execute modeland generate MSC

CompareMSCs

Required MSC

StructureModel

BehaviorModel

Generated MSC

50

• Real-Time Systems and Architecture

• The ROOM Modeling Concepts

• Development Process

• Summary

51

• The essential complexity of reactive systems issufficiently high to require specialized modelingconcepts

• ROOM takes advantage of many recent developmentsin computer technology (formal methods, the objectparadigm, graphical user interfaces)

• Also, ROOM was explicitly designed to takeadvantage of computer-based automation of many ofthe more mechanical activities of development

• This gives it a unique potential for significant gains inproductivity and quality

Why Use ROOM?

52

• Use of graphical syntax for easier comprehension

• Abstractions for dealing with high-level (architectural)phenomena of large real-time systems

- Protocol-based multiple interfaces

- Concurrent objects (actors)

- Dynamic structures

- Replicated structures

Modeling Structure

53

• High-level based on graphical syntax

• Uses hierarchical state machines

- Chosen to allow powerful modeling capabilities whileallowing for straightforward and efficient (automated)implementations

• Priority-based event handling for dealing with real-time requirements

• Incorporates industry standard programminglanguages (e.g., C++) for detailed specs

Modeling Behavior

54

• Over a hundred different industrial projects haveused ROOM

- including complete automatic code generation

• Various application domains:

- telecom

- defense/aerospace

- manufacturing

• ROOM and ObjecTime are being used as a basis forteaching real-time systems in a number ofundergraduate and graduate courses

Experience