# The Azimuth Project Real-time object-oriented modeling (ROOM) (Rev #4, changes)

Showing changes from revision #3 to #4: Added | Removed | Changed

These notes include excerpts from the Real-Time Object-Oriented Modeling (ROOM) book:

Bran Selic, Garth Gullekson, Paul T. Ward (1994) Real-Time Object-Oriented Modeling. John Wiley and Sons.

#### ROOM book p.63

Recursion. A ROOM object is an arbitrarily complex logical machine; objects may be modeled as being composed of other objects, to any desired depth. ROOM also permits the behavior of an object to be modeled by a hierarchical state machine in which states may be decomposed into substates to any desired depth.”

#### ROOM book p.149-150

“ROOM is an object-oriented modeling language and it is natural that its basic modeling concept is a special kind of object.”

“The fundamental concept for modeling high-level structure in ROOM is that of an actor. Actors model functionally significant components in a reactive system, which gives them a fairly broad scope, since functional significance is a relative term. Significant components occur at many levels in a system starting from the basic units of concurrent execution all the way up to complete systems consisting of multiple layers distributed over a wide physical domain. This is to be expected, since practically any system can be considered as a component of some greater system.”

“In general, a ROOM actor represents an active object that has a clearly defined purpose. … the term ‘active’ means that an actor may have its own execution thread and can, therefore, operate concurrently with other active objects in its domain.”

“In contrast to actors are passive data objects” that “do not appear as part of the high-level structure of a system”.

“The key to identifying an actor is its purpose. Like any object, each actor should have a definite purpose that it fulfills and that justifies its presence in a larger system. As a good rule of thumb, the purpose of an actor should be expressible in a single sentence.”

#### ROOM book p.156-157

“Object composition, and its inverse, object decomposition, are at the very heart of all structural modeling. A structure is a combination of parts that are connected according to some pattern. Composition is the process of creating a structure of actors, and consists of selecting which parts to use and defining the relationships between them.”

#### ROOM book p.160

“Bindings and ports provide the means to assemble arbitrarily complex aggregates of actors or other high-level structures. The graphical representations of these aggregates clearly and explicitly identify all the components that constitute a system, as well as their relationships.”

“Assuming the availability of a suitable library of standard parts, creating actor structures is similar to assembling toy blocks. The required parts are picked out of library of actor classes and then connected together with bindings.

#### ROOM book p.162+ Hierarchical Structures

“The approach taken in ROOM is to … take advantage of the simple, yet effective, idea of recursion.”

“Since the actor concept is defined recursively, there is no need to define a separate concept to represent some top level system. A system is simply an incarnation of some actor class. … opens up the possibility of easily embedding any given system within a greater context.”

“… one of the most common uses of composite actors is to model complex relationships between two or more objects. This is based on the simple observation that components encapsulated in a common composite actor must be related in some way. The nature of this relationship usually can be determined from the stated purpose of the encapsulating actor.”

#### ROOM book p.186+ 6.10 Formal Specifications

“In this section, we provide the formal abstract syntax of the main concepts introduced in this chapter”

I have simplified this somewhat, by removing some optional more advanced features of actor-interface. [Ken]

“An actor class is defined as a 4-tuple,

actor-class = <class-name, parent-class, actor-type, actor-implementation>

where class-name is the symbolic name of the class and parent-name is the immediate parent class from which this class was derived. If this is a root class, then this component can be empty.“

“The type of an actor is defined by its interface,

actor-type = actor-interface

where actor-interface is defined as,

actor-interface = <peer-interface>

“The peer-interface of a class is defined as a set of zero or more port references representing the ports that appear on the outside of the actor,

peer-interface = {port-ref[1], port-ref[2], ...}

“Each port reference is defined as a composite of four elements,

port-ref = <port-ref-name, replic-factor, protocol-class, conjug-ind>

“The port-ref-name … must be unique with respect to other port references in the peer interface. The replication factor (_replic-factor >= 1) is a positive integer that indicates how many incarnations of port i are defined. The protocol class is the basic class of the protocol associated with the port reference. Finally, the conjug-ind is a Boolean that indicates whether port i is conjugated” (this has generally to do with defining inputs and outputs [Ken]).

“The actor-implementation of an actor consists of two components,

actor-implementation = <structure, behavior>

where structure defines the internal decomposition of the actor and behavior defines the behavior component of the actor and may be an empty specification (for actor classes representing pure encapsulations). The formal definition of behavior components is provided in Chapter 8.“ (These are ROOMcharts, which are derived from Harel Statecharts, which are hierarchical state machines [Ken].)

“The structure component of an actor’s implementation is defined as the following 4-tuple,” (reduced to a 2-tuple [Ken])

structure = <behavior-interfaces, components>

“The set of interface components that are directly accessible by the behavior component is defined by,

behavior-interfaces = <end-ports>

“The ports that are directly accessible to the behavior component are defined by the following set:

end-ports = {port-ref[a], port-ref[b], ...}

This set can be empty.“

“The set of component actors that form part of the implementation of an actor are specified by a possibly empty set of actor references,

components = {actor-ref[1], actor-ref[2], ...}

where each actor reference is defined by the 5-tuple, (reduced to a 3-tuple [Ken])

actor-ref = <actor-ref-name, replic-factor, actor-class>

where actor-ref-name is the name of the actor component, replic-factor is its replication factor, and actor-class is its actor class.“

#### 6.11 Summary

“The primary concepts introduced in this chapter (actors, protocols, ports, and bindings) are used to model architectures consisting of hierarchies of communicating concurrent objects. To support reuse, all specifications are captured in the form of classes.”

“An actor is a concurrent active object that hides its implementation from other actors in its environment. Each actor can have multiple interface components, called ports, through which it can communicate with other actors be exchanging messages. A message is a composite object consisting of a signal, a priority, and an optional message data attribute. Each port has an associated protocol that restricts the types of messages flowing through the interface component. … The type of an actor is defined by the set of interface components (and their respective types) that appear on the outside of the actor.”

“Actors can be assembled into complex structures by interconnecting their ports with communication channels called bindings. … This means that the actor concept is recursive so that arbitrarily complex hierarchical actor structures can be constructed.”

“The ability to encapsulate actor structures with a containing actor means that an actor can be used as an abstraction facility that replaces the underlying aggregate with a single concpetual unit.”

“Each actor can optionally have a behavior component. This component can initiate activities by sending messages as well as respond to external messages.”

“ … actor components in composite actors can be replicated. This allows graphical representations of complex systems involving a large number of actor incarnations.”

#### 8.2.3 State Machines and Complexity

“Despite the additional range achieved with extended state machines, state machines can still become unmanageable when confronted with the complex reality of real-world systems. We illustrate this with a simple example.”

#### 8.2.3.2 Hierarchical State Machines

“… a solution based on the traditional approach to reducing complexity: the use of hierarchy and abstraction. That is, we can aggregate states into composite states similar to the way in which we aggregated actors into composite actors.”

#### 8.3 ROOMcharts

“The technique used in ROOM to specify behavior components was inspired by the state-charts formalism [Harel87]. In recognition of this key influence, the formalism is called ROOMcharts.”

#### A.1 The ObjecTime Toolset - History and Objectives

“The purpose of the ObjecTime toolset is to support the creation, validation, and management of ROOM models and their transformation into executable programs.”

“ObjecTime was originally developed by the Telos Group at Bell-Northern Research. The Telos Group was founded in 1985 by Jim McGee to investigate advanced systems architectures for integrated voice and data telecommunications applications. Later, this role was expanded to include research into software technologies to support large-scale systems architecture capture and computer-aided software development. This research led to the development of ObjecTime.”

## Ken’s notes

The ROOM and ObjecTime word Actor became Capsule in Rational Rose Realtime, Structured classifier in the Unified Modeling Language (UML), and Block in the Systems Modeling Language (SysML).

My Xholon tool uses the word Xholon or just Node. The word Xholon is based on the idea of a Holon which is simultaneously a whole and a part.

Xholon extends the ROOM concept in several ways.

actor-implementation = <structure, behavior, attributes>

where attributes are data values.

Behavior and attributes are equivalent to transitions and places in a Petri net. This allows Xholon to use message passing and state machine behaviors as in ROOM, and/or to use the place/transition approach of Petri nets. With ROOM-style message passing, the interactions between nodes (active objects) are always asynchronous, which means that the message just goes into a queue first. With Petri nets, the interactions between transitions (active objects) and places (passive objects) are synchronous, which means that the transitions probably (it depends how a given tool implements stuff) just call a method on the places to get and set values. Xholon supports both the asynchronous and synchronous styles of interaction, through ports.

An individual xholon/node in a composite structure is usually an active object, a passive object, or a container. Nothing prevents it from being any combination of these three, but best practice is for the node to only be one of these three types.

The Unified Modeling Language (UML) concept of composite structure, and the Systems Modeling Language (SysML) concept of block, are both based on ROOM. The UML specification section on Composite Structures, and the SysML specification section on Blocks are well worth reading. But I think that the core concepts as originally expressed in the ROOM book are more readable, and have been too genericized in the UML and SysML descriptions.

## SysML Blocks

The Blocks Overview in the SysML specification document (section 8.1) states:

“Blocks are modular units of a system description, which define a collection of features to describe a system or other elements of interest. These may include both structural and behavioral components, such as properties and operations, to represent the state of the system and behavior that the system may exhibit.”

“Blocks provide a general-purpose capability to model systems as trees of modular components. The specific kinds of components, the kinds of connections between them, and the ways these elements combine to define the total system can all be selected … SysML blocks can be used throughout all phases of system specification and design, and can be applied to many different kinds of systems. … Parts in these systems interact by many different means, such as software operations, discrete state transitions, flows of inputs and outputs, or continuous interactions.”

“A block can include properties to specify its values, parts, and references to other blocks. Ports are a special class of property used to specify allowable types of interactions between blocks.”

## Example

It’s always helpful to have a visual example. The following diagrams, from an Elevator model, were drawn using the MagicDraw UML tool which is very similar to the ObjecTime diagram editor. They illustrate many of the ROOM features described on this page. I will use the ROOM terminology here.

The first structure diagram shows an actor-class with a class-name of AnElevatorSystem, and an unknown parent-class (we would check the separate class browser or diagram to determine that). Its actor-implementation consists of structure and no behavior, so it’s just a container. AnElevatorSystem has four components in its structure, where each component is an actor-ref. For example, the Elevator actor-ref has an actor-ref-name of elevator, a replic-factor of 2 (there are 2 elevators), and an actor-class of Elevator.

The second structure diagram shows the further decomposition of the Elevator actor-class. Elevator, which is also just a container, has ports along its outer edge. The port-refs are small yellow squares, each with a port-ref-name, a replic-factor, and a protocol-class (ex: bFloor, 8, PushbuttonMessages0). Bindings (lines) connect the ports. Each Elevator has an ElevatorPanel with an actor-ref-name of panel, a Door named door, and a Hoist named hoist.

The ElevatorPanel, another nested container, has a FloorSelectionButton actor_ref with a replic-factor of 8, one Indicator, and 2 DoorControlButton actor-refs one named bOpen and the other named bClose.

The Door class is an active object that contains a behavior. The hierarchical (ROOMchart, Harel statechart) state machine that implements its behavior is shown in the final diagram. The top-level composite state contains two states - Locked and Unlocked. Unlocked is also a composite state, with substates Open, Closing, Closed, and Opening. The lines between states are state transitions, and are labeled with the events that cause the transition.