Content deleted Content added
Categories added |
hierarchical state machines and layering |
||
Line 1:
{{more footnotes|date=March 2014}}
'''Real
ROOM was developed in the early 1990s for modeling [[Real-time system]]s.<ref>[http://www.lehmanns.de/shop/mathematik-informatik/226929-9780471599173-real-time-object-oriented-modeling Summary of the book "Real-Time Object-Oriented Modeling"]</ref> The initial focus was on [[telecommunication]]s, even though ROOM can be applied to any event-driven real-time system.
Line 44:
If a transition specifies a certain ''trigger'' then it is said to ''fire'' if the state machine is in the source state of the transition and a message of the type specified by the trigger arrives. Afterwards the state is changed to the target state of the transition.
[[File:ROOM Behavior Diagram.jpg|thumb|ROOM behavior diagramm (state machine as a state chart)]]
During the state change certain pieces of code are executed. The programmer (or modeler) can attach them to the states and transitions.
Line 51:
Then the ''action code'' of the firing transition is executed and finally the entry code of the target state.
A typical part of those codes is the sending of messages through ports of the actor.
State machines in ROOM also have a graphical notation similar to the [[UML state machine|UML state charts]]. An example is shown in the diagram in this section.
A state machine can also have a hierarchy in the sense that states can have sub state machines. Similar to the structure this can be extended to arbitrary depth.
For details of the semantics of hierarchical state machines we refer to the original book<ref>ISBN 978-0-471-59917-3</ref>.
An important concept in the context of state machines is the execution model of ''run-to-completion''. That means that an actor is processing a message completely before it accepts the next message. Since the run-to-completion semantics is guaranteed by the execution environment, the programmer/modeler doesn't have to deal with classical thread synchronization. And this despite the fact that typical ROOM systems are highly concurrent because of the asynchronous communication.
And maybe its worth to stress that the asynchronous nature of ROOM systems is not by accident but reflects the inherent asynchronicity of e.g. the machine being controlled by the software. Definitely this requires another mind set than the one that is needed for functional programming of synchronous systems.
But after a short while of getting accustomed it will be evident that asynchronously communicating state machines are perfectly suited for control software.
=== Inheritance ===
Line 63 ⟶ 72:
The derived actor class can add further states and transitions to the inherited one.
===
A last powerful concept of ROOM is ''layering''. This notion refers to the vertical layers of a software system consisting of services and their clients. ROOM introduces the notions of ''service access point (SAP)'' for the client side and ''service provision point (SPP)'' for the server side. From the point of view of an actor implementation the SAPs and SPPs work like ports. Like ports they are associated with a protocol. But other than ports they don't have to (and even cannot) be bound explicitly.
Rather, an actor is bound to a concrete service by a ''layer connection'' and this binding of a service is propagated recursively to all sub actors of this actor.
This concept is very similar to [[dependency injection]].
== Literature ==
* Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3<ref>[http://www.lehmanns.de/shop/mathematik-informatik/226929-9780471599173-real-time-object-oriented-modeling Summary of the book "Real-Time Object-Oriented Modeling"]</ref>
| |||