2.1 Scope of ROOM

This chapter will give a rough overview of what ROOM ( eal time bject riented odeling) is and what it is good for. It will try to answer the following questions:

• Where does it come from?
• Which kind of SW-Systems will be addressed?
• What is the relation between OOP and ROOM?
• What are the benefits of ROOM?
• Which consequences must be taken into account?

2.1.1 Where does it come from?

ROOM was developed in the 1990th on the background of the upcoming mobile applications with the goal to manage the complexity of such huge SW-Systems. From the very beginning ROOM has focused on a certain type of SW-Systems and is, in contrast to the UML, well suited for this kind of systems. In this sense, ROOM is a DSL (Domain Specific Language) for distributed, event driven, real time systems.

Bran Selic, Garth Gullekson and Paul T. Ward have published the concepts 1994 in the book Real-Time Object-Oriented Modeling. The company object time ^TMdeveloped a ROOM tool which was taken over by Rational SW ^TMand later on by IBM ^TM. The company Protos Software Gmbh ^TMalso developed a ROOM tool called Trice ^TMfor control software for production machines and automotive systems. Trice ^TMis the predecessor of eTrice (see Introduction to eTrice).

From our point of view ROOM provides still the clearest, simplest, most complete and best suited modeling concepts for the real time domain. All later proposals like the UML do not fit as well to this kind of problems.

2.1.2 Which kind of SW-Systems will be addressed?

As mentioned before ROOM addresses distributed, event driven, real time systems. But what is a <em>real time system</em>? ROOM defines a set of properties which are typical for a real time system. These properties are:

• Timeliness
• Dynamic internal structure
• Reactiveness
• Concurrency
• Distribution
• Reliability

Each of these properties has potential to make SW development complex. If a given system can be characterized with a combination of or all of these properties, ROOM might be applied to such a system.

As an example take a look at a washing machine. The system has to react on user interactions, has to handle some error conditions like a closed water tap or a defective lye pump. It has to react simultaneously to all these inputs. It has to close the water valve in a certain time to avoid flooding the basement. So, the system can be characterized as timely, concurrent and reactive. As long as the washing machine does not transform to a laundry drier by itself, the system has no dynamic internal structure and as long as all functions are running on a single micro controller the (SW)-system is not distributed. ROOM fits perfect to such a system.

A SW system which mainly consists of data transformations like signal/image processing or a loop controller (e.g. a PID controller) cannot be characterized with any of the above mentioned properties. However, in the real world most of the SW systems will be a combination of both. ROOM can be combined with such systems, so that for example an actor provides a <em>run to completion</em> context for calculating an image processing algorithm or a PID controller.

2.1.3 What is the relation between OOP and ROOM?

The relation between classical object oriented programming and ROOM is comparable to the relation between assembler programming and C programming. It provides a shift of the object paradigm. As the picture shows, the classic object paradigm provides some kind of information hiding. Attributes can be accessed via access methods. Logical higher level methods provide the requested behavior to the user.

As the figure illustrates, the classical object paradigm does not care about concurrency issues. The threads of control will be provided by the underlying operating system and the user is responsible to avoid access violations by using those operating system mechanisms directly (semaphore, mutex).

ROOM provides the concept of a logical machine (called actor) with its own thread of control. It provides some kind of cooperative communication infrastructure with "run to completion" semantics. That makes developing of business logic easy and safe (see basic concepts). The logical machine provides an ncapsulation shell including concurrency issues (see chapter Run to completion).

This thinking of an object is much more general than the classic one.

2.1.4 What are the benefits of ROOM?

ROOM has a lot of benefits and it depends on the users point of view which is the most important one. From a general point of view the most important benefit is, that ROOM allows to create SW systems very efficient, robust and safe due to the fact that it provides some abstract, high level modeling concepts combined with code generation and a small efficient runtime environment.

In detail:

• ROOM models contain well defined interfaces (protocols), which makes it easy to reuse components in different applications or e.g. in a test harness.
• Graphical modeling makes it easy to understand, maintain and share code with other developers
• Higher abstraction in combination with automated code generation provides very efficient mechanisms to the developer.
• ROOM provides graphical model execution, which makes it easy to understand the application or find defects in a very early phase.

2.1.5 Which consequences must be taken into account?

Generating code from models will introduce some overhead in terms of memory footprint as well as performance. For most systems the overhead will be negligible. However, the decision for using ROOM should be made explicitly and it is always a trade off between development costs, time to market and costs in terms of a little bit more of memory and performance. Thanks to the powerful component model, ROOM is especially well suited for the development of software product lines with their need for reusable core assets.

Care must be taken during the introduction of the new methodology. Due to the fact that ROOM provides a shift of the object paradigm, developers and teams need a phase of adaption. Every benefit comes at a price.