Room

Published on May 2016 | Categories: Documents | Downloads: 87 | Comments: 0 | Views: 737
of 27
Download PDF   Embed   Report

Comments

Content

Real-Time Object-Oriented Modeling
Bran Selic ObjecTime Limited [email protected]

Tutorial Structure
• • • • Real-Time Systems and Architecture The ROOM Modeling Concepts Development Process Summary

2

General Real-Time System
SW Machine

SW Machine

SW Machine

SW Machine

SW Machine SW Machine

SW Machine

SW Machine

SW Agent

SW Agent

SW Agent

Sensor

Sensor

Effector

Effector

Physical Elements

3

Software Architectures
SW Machine

SW Machine

SW Machine

SW Machine

SW Machine SW Machine

SW Machine

SW Machine

SW Agent

SW Agent

SW Agent

Sensor

Sensor

Effector

Effector

Physical Elements

4

What is an Architecture?


Architecture: an abstract specification that constrains the structural and behavioral patterns of all system components
Key to proper construction and evolution
Functional Space
version N Architecture A



version 3

version 2 version 1 Architecture B

5

An Example Architectural Specification
High-Level System Structure
initialize

Behavior

user user1 keypad entrance1

dbase

console
Ready

dbase
timeout key resetDisplay displayMsg

user user2 keypad entrance2

dbase

console database ctrlrs
Entering1stStr WaitingForReset

enterKey

enterKey

user user3 keypad entrance3 dbase

Entering2ndStr

msc SuccessfulAccessScenario

User key key key key

KeypadDisplay

AccessController

GateController

PWDatabase

Scenarios (Use Cases)

entryReq validationReq valid unlock displayMsg timeout lock resetDisplay

6

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 ...#h

B!‰m

!

7

Why Architectures Fail
• 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...”

8

Modeling and the Development Cycle
• Traditional view
Scope
High-Level (Architectural) Modeling High-Level Modeling Notations Compilation & Library Structures

Detail Modeling

Detail Mod. Notations + Programming Languages Analysis&Design

Programming Languages

Implementation

Development Activity



Characterized by semantic gaps that discourage recursion and introduce errors

9

The ROOM Approach
• •

Real-Time Object-Oriented Modeling
Two level scheme with formally defined relationships between levels

High-Level (Architectural) Modeling

ROOM Schematic Modeling Language

Detail Modeling

Programming Languages

Analysis&Design

Implementation



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

10

ROOM
• A method for developing software for real-time distributed systems
WILEY

WILEY PROFESSIONAL COMPUTING

-

suited for event-driven systems full-cycle method (A D I)

REAL-TIME OBJECT-ORIENTED MODELING

Bran Selic, Garth Gullekson and Paul T. Ward

uses a formal graphical modeling language suited for computer-based automation:
--executable models automatic code generation


11

Originated in Bell-Northern Research

Modeling in ROOM
initialize Ready

user user1 keypad entrance1

dbase

console
timeout key

resetDisplay

displayMsg

dbase
Entering1stStr WaitingForReset

Two Levels of Modeling
user2 keypad user3 keypad

user entrance2

dbase

console database ctrlrs
enterKey enterKey

Entering2ndStr

user entrance3 dbase

msc SuccessfulAccessScenario

User key key key key

KeypadDisplay

AccessController

GateController

PWDatabase

Architectural Level Language (ROOM)

entryReq validationReq valid unlock displayMsg timeout lock resetDisplay

Detail Level Language e.g. C++

12

Why Object-Oriented?
• • The structural aspect of architectures tends to be object-based The object paradigm is a synergistic combination of proven, useful concepts
encapsulation, polymorphism, inheritance...



The potential for re-use
formally supported only in implementation-level programming languages can it be used at the architectural level?
-e.g., can an architecture be inherited?

13

• • • •

Real-Time Systems and Architecture The ROOM Modeling Concepts Development Process Summary

14

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

15

Messages
• Objects that carry information about some event
Signal

“Fire”
Location Street: Elm St. Number: 10

“ACK”

Data object (optional)



Message-based communication is well-suited to distributed systems

16

Message Priorities
• A message in transit is assigned a priority that identifies the significance of its event

“Fire”
Location Street: Elm St. Number: 10
HIG PRI H OR IT Y



Required to support timely responses

17

Object Types

ACTIVE PASSIVE
- messages - Detail Level data - actors - own execution thread (concurrent)

18

Actors
• The active objects of ROOM are called actors
ENCAPSULATION SHELL

ACTOR

INCOMING MESSAGE PORTS

OUTGOING MESSAGE



Actors can send and receive messages through distinct interfaces called ports
19

Actor Interfaces
• Each interface of an actor has a unique name and an associated protocol Different interfaces can use different protocols An actor can present different “views” of itself to different collaborators; e.g.:
controlIF

• •

CONTROL INTERFACE PORT

serviceIF1

serviceIF2

serviceIF3

SERVICE INTERFACE PORTS

20

Protocols
• An extension of conventional interface concept based on 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)

21

Message Sequence Charts
• Message sequences are expressed by Message Sequence Charts (MSCs)

msc Joke

Comedian KnockKnock WhosThere Boo BooWho PleaseDontCry

StraightMan


22

Defined by ITU standard Z.120

Protocol Classes
• Sometimes different actors use the same protocol definitions It is convenient to define protocols independently of the actors that use them through protocol class specifications Each port (actor interface) has a type that is defined by its protocol class Protocol classes represent reusable interface specifications; this is the basis for a type of polymorphism available in ROOM







23

Actor Types
• The collection of all interface types of an actor defines its type
controlIF

serviceIF1

serviceIF2

serviceIF3



This is a basis for a form of genericity

24

Combining Actors — Actor Structures
• The object paradigm allows us to combine objects to create more complex systems
user entrance1 dbase

user entrance2

dbase

database ctrlrs

user entrance3 dbase



The connections between ports are called bindings

25

Bindings
• Abstract representations of established communication channels for exchanging messages between actors Only ports with compatible protocols can be bound
Usually, a protocol class and its conjugate





Bindings explicitly identify all valid causal linkages between actors Semantics of bindings are defined by the protocol classes of the ports



26

Looking Inside Actors
• If the functionality of an actor is complex, it may be useful to break it down into simpler components
user entrance2 dbase

database ctrlrs

user user keypad axCtrlr

keypad axCtrlr gate

ctrlr gateCtrlr

dbase

dbase


27

Actors can be defined recursively!

Reusing Specifications — Actor Classes



As with protocols, it is often useful for multiple actors to share a common specification This is achieved through actor classes ROOM distinguishes between the class and the type of an actor

• •

actor class = actor type + actor implementation

28

Handling Messages and Port Types
• Actors can either relay messages to internal components or handle them directly All messages arriving on relay ports are forwarded automatically



user user keypad axCtrlr

keypad



Alternatively, messages arriving on an end port are processed by the actor

29

End Ports and Behavior
• End ports are the access points to the behavior (component) of an actor Identified by a distinct graphical notation



keypad

gate

dbase



The behavior component is implicit; i.e., it is not explicitly rendered in a diagram

30

The Behavior of Reactive Systems
• Between successive events, the behavior is quiescent, “listening” for incoming messages When a message arrives, the behavior is activated and may respond by sending one or more messages of its own through its ports



Wait for Next Message

Handle Message

31

Execution Paradigms
• What happens if a new higher priority event arrives while the previous event is being processed?
Two options:
-



preemptive paradigm interrupts current event handling run-to-completion paradigm finishes handling the current event handling before moving on to the new event



ROOM uses the run-to-completion paradigm

32

ROOMcharts

user user keypad axCtrlr

keypad axCtrlr gate

ctrlr gateCtrlr

dbase

dbase

initialize timeout Ready

entryReq

invalid

Wait for Next Message

Validating

valid

Handle Message

DoorOpen

33

Events, Triggers, and Actions
• Each transition has
a trigger which specifies the message arrival event(s) that causes the transition

-

optionally, an action that specifies how the event is handled



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

34

Extended State Variables



In addition to temporary variables that may be associated with an action, ROOMcharts also allow the definition of extended state variables Variables are passive objects used to store Detail Level information that needs to be retained between transitions
for example, instances of C++ object classes



35

Hierarchical States
• Hierarchy is a means of dealing with complexity by focussing on only a manageable chunk at a time

key

initialize Ready
key

timeout

key

resetDisplay

displayMsg

EnteringKeys

Entering1stStr

WaitingForReset
key false

enterKey

enterKey

CP1

Entering2ndStr

true

enterKey

36

Behavior — Group Transitions
• A “shorthand” form for equivalent transitions that emanate from a common state

S1

e e S0 e

S1

=
S2 S2

e S0

S2

S2



Group transitions not only reduce visual clutter but often also identify “higher-order” events and provide hints about potential state aggregations

37

The Effectiveness of ROOMcharts
b

A1|B1
a1 a b2 a2

B1|A1
b1 b

A1
a2 a1

a

B1
b2 b1

A1|B2

B2|A1
a b

=
a2

b

A2|B1
a a1 b b2

B1|A2
b1

A2 A

B

B2 A2|B2

a

B2|A2

ROOMCHART: (6 states, 6 transitions)

“FLAT” STATE MACHINE EQUIVALENT: (8 states, 16 transitions)

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

38

Inheritance Hierarchies in ROOM
• Each of the following class types has a distinct class hierarchy
Actor classes Protocol classes Data classes



The rules of inheritance are not uniform in the three different hierarchies

39

Actor Class Inheritance — Structure
CLASS Gray pen used to indicate inherited attributes in subclass SUBCLASS
user entrance2

user entrance1

dbase

dbase

database ctrlrs

user user1 keypad entrance1

dbase console dbase

user entrance3 dbase

user user2 keypad entrance2

dbase

console database ctrlrs

user user3 keypad entrance3 dbase

NEW ATTRIBUTES IN SUBCLASS

40

Actor Class Inheritance — Behavior

Off

Off

off on

initialize on

off

On

On

41

Refinement of Behavior in Subclasses
SUBCLASS REFINES A “LEAF” STATE IN THE SUPERCLASS

on on

off

PoweringUp initialize Off done initialize on off Operational

On

42

Replicated Structures
• Useful for dealing with regular repeating structures

kNumGates PORT INSTANCES kNumGates ACTOR INSTANCES
console dbase kNumGates user entrances dbase

console database ctrlrs

43

Dynamic Structure — Optional Actors
• Components may be created after their container as needed



Creation/destruction controlled by the container

44

Multiple Containment and Importing
• Captures components that are simultaneously part of two or more container actors
TelephoneSystem Call n Telephones “IMPORTED” Actor

TelephoneX

TelephoneY

EQ1 EQ2

“REPLICATED” Actor



Component actors are “slots” to be filled as needed

45

Generic Structures
• Ability to define a component as “generic”
Call

+
TelephoneX

+
TelephoneY

• •

Any actor with a compatible type can be imported into the generic “slot” A single model represents a collection of possible variants

46

Layering
• Layer relationships:
Directed hierarchical relationship For modeling widely-shared implementation services
E E

B

C

D

B

C

D

A

SharedService

A

SharedService

• •

Reduces apparent complexity Communication model also based on protocols and port-like interfaces (Service Access Points (SAPs))

47

• • • •

Real-Time Systems and Architecture The ROOM Modeling Concepts Development Process Summary

48

Typical Current Development Micro-Cycle
Required MSC
Generate Scenarios
msc SuccessfulAccessScenario User key key key key entryReq validationReq valid unlock displayMsg timeout lock resetDisplay KeypadDisplay AccessController GateController PWDatabase

Derive structure

Requirements Spec
user user1 entrance1 keypad dbase console dbase

+ msc SuccessfulAccessScenario User key key key key entryReq validationReq valid unlock displayMsg timeout lock resetDisplay KeypadDisplay AccessController GateController PWDatabase

user user2 keypad entrance2

dbase

console database ctrlrs

Compare MSCs

user user3 keypad entrance3 dbase

Structure Model
initialize Ready

Generated MSC

timeout

key

resetDisplay

displayMsg

Derive behavior

Entering1stStr

WaitingForReset

Execute model and generate MSC

enterKey

enterKey

Entering2ndStr

Behavior Model

49

• • • •

Real-Time Systems and Architecture The ROOM Modeling Concepts Development Process Summary

50

Why Use ROOM?
• The essential complexity of reactive systems is sufficiently high to require specialized modeling concepts ROOM takes advantage of many recent developments in computer technology (formal methods, the object paradigm, graphical user interfaces) Also, ROOM was explicitly designed to take advantage of computer-based automation of many of the more mechanical activities of development This gives it a unique potential for significant gains in productivity and quality







51

Modeling Structure
• • 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

52

Modeling Behavior
• • High-level based on graphical syntax Uses hierarchical state machines
Chosen to allow powerful modeling capabilities while allowing for straightforward and efficient (automated) implementations



Priority-based event handling for dealing with realtime requirements Incorporates industry standard programming languages (e.g., C++) for detailed specs



53

Experience
• Over a hundred different industrial projects have used ROOM
including complete automatic code generation



Various application domains:
telecom defense/aerospace manufacturing



ROOM and ObjecTime are being used as a basis for teaching real-time systems in a number of undergraduate and graduate courses

54

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close