Visualizing the Behavior of Object-Oriented Syst ems

This paper proposes an architecture to visualize the dynamic behavior of an object-oriented program. This architecture successfully achieves the four goals set by the authors. They are:

Versatility
Composability
Extensibility
Platform and language independence

The architecture itself is a very good example of object-oriented design. It uses an annotation method for application instrumentation. Since the process is automatic and unintrusive, it can easily be replaced by more advanced design in the future. The instrumented application is separated from the visualization application. The instrumented application generates annophrases during run-time which describe the activities of the program, and an annotalker transmits the annophrases to a visualization application using a annotalk protocol. The annophrases are then put on an annobus. The annobus can be accessed by various annomodels which construct models of the application from the run-time activities depicted by the annophrases. The annomodels in turn drive the visualizers to generate the visualization, which is presented as concrete images on the screen by renders. The annomodels, visualizers, and renders are all replaceable and extensible objects in the architecture. This allows potential growth of the visualization system. In the paper, the authors also give us a catalog of visualization implemented in this architecture. The visualizations use a great deal of spatial and temporal capacity of the computer screen to convey the dynamic behavior of the program being examined. As the authors point out, "a key principle in designing visualization of object-oriented programs in particular is to take advantage of the structure this paradigm affords," the visualizations in the implementation certainly utilize the structure of object-oriented programs very well.

Question: The inter-class call cluster in a 2D presentation looks quite inadequate to fully represent the relationship between classes. A 3D presentation will be better, but still insufficient. Is there any better way to represent the closeness of the classes? Maybe duplicate the classes which are close to more than one group?

Using Animation to Design Object-Oriented Systems

This paper presents a system (GROOVE) that helps users design object-oriented systems. The idea comes from the observation that schematic information of an object-oriented system does not tell the whole story; the dynamic behaviors are usually added by the humans who actively explain the working of the system. The GROOVE system allows users to design an object-oriented system on the screen. It provides means for users to create classes and their instances, and specify the relations between them. It does a good job in helping users avoid information overload and focus on the relevant part of the system being designed by using the concept of current focus, but more importantly, it records all the dynamics of message passing, and instance creation and destruction specified by the designer during the design process, which can be played back for the designer and/or other people to understand the dynamic behavior of the system.

The GROOVE system effectively uses animation tools for message passing visualization. The roll of lifesavers approach is especially powerful in visualizing the dynamics of the message binding process, which is sometimes a hard concept to grasp. The GROOVE system also allows the designer to specify divergent message flows, which is necessary for a complete system design. The mainline branch idea, on the other hand, provides a way for continuous play back of a scenario without stopping at each branch point.

The dynamic play back and various other visualization techniques used in GROOVE provides users with a useful tool in the designing phase of an object-oriented system and in understanding of the dynamic behavior of the design.

Question: The GROOVE system is a very useful object-oriented design tool. The authors propose to extend it to visualize a running program. But how can we keep the design and the actual program tightly coupled, so we know the implementation is the same as the design? It will be very helpful in keeping implementation consistent with the design. This question is also asked but not investigated in the paper. One approach to keep the consistency is to provide automatic code generation from the design, and put some constraints on the programmer with regard to what kind of modification can be made to the automatically generated code.