Customer Reviews

Real-Time Object-Oriented Modeling

5 star:		(5)
4 star:		(4)
3 star:		(0)
2 star:		(0)
1 star:		(1)

 

 

It's very difficult to evaluate the book. There are actually two things to evaluate: (1) the ROOM methodology, and (2) the book publishing ROOM. The ROOM methodology is great: the only complete software development methodology I have ever seen. However the way it is discussed in the book is not an easy reading, even not for an experienced OO developer. Do not give up when you think you have lost. Reread sections until you understand the gist. Eventually, you will be very happy with the new tecniques you learned. I'm quite sure that ROOM is applicable not only for real-time systems. It should be adapted to non-realtime development too. Without reading this book you will not understand UML RealTime implemented by Rational RoseRealTime. My five stars are primarily for ROOM methodology.

First, remember that this book was published in 1994 - it was probably written in the 1992-3 era. The OO design world was still in the "warring states" period before unification under UML. The company that created ROOM tools, if I understand correctly, was absorbed by another company that was absorbed by another company - I'm not sure how much of ROOM in its pure form is still left.

That doesn't matter. In its time, ROOM was wild, innovative, and a topic of heated debate. It created a visual, highly abstracted language (back then, a questionable novelty) around an intensely parallelized model of computing (also a questionable novelty), at a time when "real-time" often meant lots of assembly programming in command-line environments. I was doing embedded development back about then - based on the mind-set of the time, I'm surprised that ROOM had the success and influence that it did.

Surprised but pleased. Lots of the ROOM techniques and notations survive in UML and other development tools. Modern component programming environments, JavaBeans included, show many signs of direct descent from the ROOM techniques. Still, there's a long way to go. ROOM may have been way ahead of its time, and languages still haven't caught up fully to its models of communication and parallelism.

As impressive an achievement as ROOM was (and is), I have some reservations about it. It relies pretty heavily of state machines for modelling the interacting components. State machines are a good tool, but quite unfamiliar to most software developers these days. I'm not sure whether that's a fault of the methodology or of today's programmers. I also have reservations about any methodology that requires me to buy someone's tools. The authors state that the design methodology can be used without their tools - based on ROOM's complexity, I doubt it. Also, I have a serious distrust of any programming environment that takes over so much of the process. Such tool sets tend to leave me feeling cramped, with little way to express my ideas in different terms. Finally, I'm sure it does all it says it does. Even so, the moment always comes when the tool-generated subsystems need to be opened up for debugging, or when the system has to be open to interaction with other development tools. Real-time and embedded systems tend to be so idiosyncratic and demanding that both kinds of openness in an IDE are compulsory. I just don't see the way out of the closed ROOM.

My present interest is not so much in the ROOM methodology itself, although I'm interested in methodology in general. Instead, I'm studying the visual notation it developed for expressing complex computations. Whatever ROOM's faults and whatever its later history, it's still worth attention.

The ROOM methodology (and ObjecTime's supporting toolset) is representative of the future of distributed system development. The underlying concept of concurrently executing, communicating finite state machines is the essence of successful distributed architecture design. ROOM does a quite reasonable job of mapping this concept into an object-oriented framework, and ObjecTime's toolset makes learning ROOM (and CCFSM) quite approachable-- dare I say even enjoyable!

If you have any interest in distributed systems architecture at all, this book is a must-read.

I have used ROOM since 1993 - it is a very useful and flexible methodology. The authors present it in a very clear and well thought out manner. The examples also show that this is not a "toy" methodology. ROOM comes out of the author's years of experience in developing real solutions; I can only say that it has been very successful for myself and teams I've been on as well. That it has evolved into the real-time representation of UML only shows that these authors were ahead of their time.

The ROOM methodology is specifically tailored for the practical development and maintenance of real-time systems. Have you ever tried to use CASE tools but found that something is always lost between design and implementation? Have you ever had to fix code where there was no design documentation at all? Use the techniques in this book, and those days are gone. The key point from this book is that the ROOM models are executable. The model IS the system. The mapping from your model to the code is unambiguous. Your implementation NEVER deviates from the design - that is how the methodology works. Your design is a living document. If you are doing serious real-time work read this book and check out [...] - you won't regret it.

The ROOM Methodology can look very complicated - until you try to use it once. The beauty of ROOM is that it is a simple and elegant notation to describe a system or an application. This isn't just an academic text but comes from years of work developing real solutions, and it shows. I have applied it to various tasks (both using the ObjecTime tool and without the tool) and have yet to find a system that it didn't work on.

ROOM is a great methodology, but I rarely encounter it in my work. I do mostly SOA and BPM work, and I think there are aspects of ROOM (particular its state machine language) that are well suited to that domain. I wonder how popular ROOM is these days in the real-time and embedded systems development community?

If you're into state machines, you'll enjoy this book. ROOM is influenced by the work of David Harel, supporting hierachical states, group transitions and transitions to history, choice points, and the ability to associate actions with both transitions and states. In contrast with Harel, ROOM does not support orthogonal states, although its concurrency model is quite powerful. I prefer ROOM to the UML for the modeling of state.

The eminently practical, usable, powerful, elegant and - once understood - simple concepts behind ROOM deserve the broadest audience amongst real-time and even non-real-time developers. It has been a couple of years since I cracked the cover and I recall the reading being dry. Nonetheless, if you are considering a move to Rational Rose RealTime as a development tool (into which ObjecTime evolved), then this book is truly helpful as a reference for the modeling concepts. The example used throughout is simple enough that it is easy to grasp allowing you to dedicate your time to conceptual understanding rather than getting your head around some obtuse example. At the same time, the example is a natural vehicle for the inclusion of advanced concepts as each is intoduced.

The concepts of ROOM are finding/have found their way into the UML and the "it's not UML" darts of years ago are a little tired at this juncture.

ROOM is brilliant.

(from a former ObjecTime/Rational type though with no association for a few years)

ROOM is an exciting methodology! The book gives the reasoning behind the development of the method, and describes the methodology in a visual, easy to understand form. It also presents a formal description of the methodology. Along with the ObjectTime tool, which is described in the book, ROOM represents a new paradigm for RT development. One which is the future of all computing. A paradigm where the high-level language used (C++, RPL, etc.) will take the place of assembly language,and design graphics will displace high level languages.

This book doesn't even mention UML. It may be good if you want to use author's modeling.