real-time object-oriented modeling...bran selic objectime limited [email protected] real-time...
TRANSCRIPT
Bran SelicObjecTime Limited
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