Real Time Object Oriented Modeling

from Wikipedia, the free encyclopedia

Real Time Object Oriented Modeling (ROOM) is a domain-specific language .

ROOM was early 90's for the modeling of real-time systems developed. Originally developed for the field of mobile telecommunications with a focus on simplicity and performance, the ROOM language can be used for any event-driven real-time system.

ROOM is z. B. supported by the tools ObjecTime Developer (commercial) and eTrice (Open Source).

Many of the basic concepts of ROOM have been incorporated into the definition of UML2 (Version 2 of UML with real-time extensions).

Concepts and basic terms

ROOM is a modeling language for describing software systems, which allows the complete generation of the program code for the system from the model. ROOM defines a textual as well as a graphic description language for this. Typically, the generated code is supplemented by manual code, for example for a graphical user interface ( GUI ). The code is then compiled and linked against a runtime library that provides base classes and basic services (such as messaging).

ROOM knows three aspects of a software system: structure, behavior and inheritance. These aspects are briefly explained in the following sections.

structure

The structural view in ROOM is made up of so-called actuators . Actuators can communicate with other actuators via ports . Ports are connected to one another via bindings . Actuators exchange messages that are sent asynchronously via ports and bindings . Each port is assigned to exactly one protocol . A protocol in ROOM defines a set of incoming and a set of outgoing messages. Bindings can only connect ports that belong to the same protocol and that are conjugated to one another. This means that one port receives the incoming messages of the protocol and sends the outgoing ones. This port is also called regular . Its counterpart, the conjugated port, receives the outgoing messages of the protocol and sends the incoming ones. A port thus combines a required and a provided interface in one role (since the same protocol can be used by several ports of an actuator).

Example of a structure diagram

An actuator can also contain other actuators (as a composition ). These actuator references are called in ROOM . Structural hierarchies of any depth can be created in this way.

The ports of an actuator can be part of its interface (i.e. externally visible) or part of its structure (i.e. used by itself) or both. Ports that only belong to the interface are called relay ports . They are directly linked to the port of a subactuator (an actuator reference). Ports that only belong to the structure are called internal end ports . Ports that belong to the structure and interface are called external end ports .

behavior

Each actor in ROOM has a behavior in the form of a hierarchical state machines (Engl. State Machine ). A state machine is a directed graph that consists of nodes called states and edges called transitions . Each state corresponds to a state. State changes can only take place along a transition. Changes in status are triggered by a message arriving at an (internal or external) end port (which in this context is also called an event or signal ). If this so-called trigger is specified by the transition, it fires precisely when the state machine is in the initial state of the transition. The state machine then changes to the target state of the transition.

ROOM behavior diagram (state machine)

When the state changes, pieces of code are executed which the programmer / modeler attaches to the states and transitions. Such pieces of code are written in a detail level language , usually the target language of the code generation. A distinction is made between entry and exit codes for the state. In the event of a change of state, the exit code of the initial state is executed first, then the action code of the firing transition and finally the entry code of the target state. A message is very often sent from such pieces of code via a port of the actuator.

Further elements of a state machine are the choice points and the transition points , which will not be discussed further here.

A state machine can introduce further hierarchical levels in which individual states again have a sub-state machine. Similar to the structure, this can be continued to any depth.

Finally, an important concept in this context is the execution model of run to completion . This means that an actuator completely processes a received message before processing the next. Since the run to completion semantics are guaranteed by the execution environment, the programmer / modeler does not have to worry about synchronization and thread safety separately, although systems implemented with ROOM can be highly concurrent.

Inheritance

Like any object-oriented programming language , ROOM is a class model. In other words, actors are classes that can be instantiated multiple times as objects . Each individual instance of a class can be in a different state and can also communicate with other instances of the same class.

ROOM also knows the term inheritance in the sense of single inheritance. This means that an actuator class can be derived from another (its base class ) and inherits all properties of its base class, such as ports and actuator references, but also the state machine. The inherited state machine can be expanded by the derived class to include further transitions and states.

Layering

A last powerful concept in ROOM is the so-called layering . This means a vertical stratification of the system into services and users of these services. ROOM introduces the terms Service Access Point (SAP) on the user's side and Service Provision Point (SPP) on the provision side of a service. It is interesting that SAPs do not have to be explicitly connected to SPPs like ports. Rather, an actuator can be linked to a service via layer connection and makes it available to all subactors (recursively). Otherwise, services and their users, like ports, are linked to protocols and communicate using messages that are sent asynchronously.

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
  • Oliver Kaiser: "Real-time requirements for the simulation of technical products", Herbert Utz Verlag, 2000, ISBN 3-89675-734-2

Individual evidence

  1. Lecture TU Dresden ROOM - UML comparison (PDF; 73 kB)
  2. Microsoft Information on ROOM  ( page no longer available , search in web archivesInfo: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2Template: Dead Link / office.microsoft.com  
  3. eTrice - ROOM Open Source Tool
  4. Information in English on ROOM and the book "Real-Time Object-Oriented Modeling"