UML Notation and Ilogix Rhapsody Tool

1 UML Notation and Ilogix Rhapsody Tool

This report has been developed in the scope of the seminar "Werkzeuggestützte Modellierung des Tamagotchi" in the winter term 98/99. The seminar has been organized by the AG Software Engineering of Professor Rombach at the University of Kaiserslautern in cooperation with the TU München.
First, we had to work out a simplified safety injection device for a nuclear power plant. The main task was to produce a specification for a Tamagotchi.
Each group had to use different software design methods and CASE-tools. Our group - Christian Becker, Steffen Glomb, and Michael Graf - used the UML notation and the UML-based CASE-tool Rhapsody. All of us study computer science at the university of Kaiserslautern, at the moment in the ninth term.
The following chapters are about the experience we gained during the seminar.
 

1.1 Introduction

In this chapter, we give a short introduction to the UML notation, the applied method and the Rhapsody CASE-tool.
The pictures in this section are taken from the specification of the safety injection device.
 

1.1.1 Notation

The development of UML (Unified Modeling Language) goes back to the year 1995 when James Rumbaugh and Grady Booch decided to put together their two Software Design approaches (OMT and Booch-method). Their attempt to create a so-called Unified Method (UM) failed because they could not agree on uniform method guidelines. Instead of giving up they decided to restrict their effort on the development of a unified notation. Ivar Jacobsen (creator of the Objectory method) joined them and soon they were called the "3 Amigos". Jacobsen introduced the idea of use cases, nowadays one of the most often cited vogue words in the SE community. In January 1997 they published the first standardized version of the UML.
The amigos claim that the UML allows to specify, to construct, to visualize, and to document models of any software system. [Oes97, p.143], [FS98, p.17ff]
In the sequel, many industrial partners like Sun, IBM, and Microsoft contributed their ideas. Therefore, version 1.1 and 1.2 followed rather quickly.

The UML contains a variety of eight different diagram types whose semantics are laid down in a complex metamodel hierarchy. They can be classified according to the three main views of a system: the structural view (class diagrams, component diagrams, deployment diagrams), the behavioral view (state diagrams, collaboration diagrams, sequence diagrams), and the functional view (use case diagrams, activity diagrams). [Atk98, "Modeling dimensions"]

1.1.1.1 Description of data

One of the basic aspects of object-oriented programming languages is that data and processes are combined to form objects. An object's behavior is defined by its methods while its structure is given through its attributes (i.e. its data). A class can be regarded as the object's type or model. Each object is an instance of its class and inherits its class' behavior and but has got its own set of attributes. The class concept reduces complexity because identical information has to be declared only once.
In the UML, class diagrams are used to show information about data. This type of diagram is well known from (the notation subset of) many object-oriented methods, like the OMT or Booch. It describes the different classes that exist in the system and the static relations between them. Classes are shown as rectangles with three subsections divided by horizontal lines. The first section contains the classname, the second lists the classes' attributes while the third section contains the existing methods. Inter-class relations - aggregations, generalizations or associations - are drawn as lines connecting the class boxes. Aggregations are characterized by little diamonds while generalizations are typified by small triangles on the end of the line.
Class diagrams can contain further details like interfaces, stereotypes or constraints. Please refer to [FS98, chapter 5] for more details.

1.1.1.2 Description of behavior

The behavior of an object is defined by its methods. They imply the different states of an object.

In the UML, the object's behavior can be visualized using a statechart diagram. Doing this is especially advisable if the object's behavior is complex or significant to the system's behavior. The statechart diagram is an adoption from Harels' statecharts.

A statechart diagram shows all possible states of an object. The above example contains the states "start", "permit_and_not_blocked", "between_and_blocked", and so on. Other important elements of a statechart diagram are activities and actions. An activity is associated with a certain state whereas an action accompanies a transition. While the former take some time to happen and can be stopped prematurely by an event on an outgoing transition, the latter are considered to be atomic and are therefore not interruptable.
A transition describes the changing of states. It can be triggered by occurring events or by the ending of an activity.
Transitions are visualized by an arrow from the source state to the destination state. In the picture, the arrow between the states "start" and "permit_and_not_blocked" represents a transition that is triggered by the event "permit".
On a transition, events can be created. The timeout event "tm(1000)" triggers a transition from the state "low_and_blocked" to the state "low_and_not_blocked". As a result of the transition, the  event "start_injection" is sent to the object named "itsDevice".

Some other important features of statechart diagrams are not shown in this simple example.
For example, a transition from one state to another can be guarded by a boolean expression. Such a transition is triggered only when at the moment of the occurrence of the appropriate event, the guard evaluates to true, too.
Another important feature is the nesting of states. Substates inherit all outgoing transitions of their superstates. Using this technique, clearer and less complex statecharts can be modeled.
If an object can be in several different states simultaneously, one can describe its behavior in a concurrent state chart.
For a deeper insight in these topics, please refer to the report of the Statechart group or to [Oes97] and [FS98]

Alternatively, activity diagrams can be used - they are especially useful to describe complex concurrent behavior (its roots are SDL and petri-nets).

1.1.1.3 Description of timing requirements

Timing requirements are an important aspect of the behavioral view. In statechart diagrams, timeout events can trigger transitions. They are however no special UML feature, but have to be implemented through user-defined objects. The Rhapsody tool supports a system timer - a convenient solution. Consider "tm(1000)" in the above example on the transition from state "between_and_blocked" to "between_and_not_blocked". This means that after staying for 1000 milliseconds in the "between_and_blocked" state, the transition to the "between_and_not-blocked" state is triggered.

Sequence and collaboration diagrams are interaction diagrams. Each of them is based on a particular section of the system's behavior - sometimes called a scenario.
A scenario is like an instance of a use case or of one step of a use case. Arrows from the sender to the destination are used in both of these diagram types to show the information flow between different objects. The arrangement of these arrows corresponds to the timing in the scenario. Again, we must refer you to the literature for further details on interaction diagrams. [Oes97, p.134f] , [FS98, p.105ff]

1.1.1.4 Mechanisms to structure the specification (into manageable pieces)

First of all, the division into the three views of a system - its behavioral, its structural and its functional aspects - allows to structure the specification. As we have already mentioned, there are own diagram types for each of these views.
Grouping coherent behavior and data into classes also helps to keep the specification clear. Classes (and their objects) provide their service by public interfaces while the actual implementation is "hidden" inside.
Besides that, logically or physically coherent model elements can be organized in a package which defines a namespace for its content. Already existing libraries, subsystems or interfaces form their own packages. The purpose of the package construct is to provide a general grouping mechanism; it can be used for element organization of any purpose. The criteria for grouping elements together into one package are not defined within UML. Packages can be arranged hierarchically - that means, a package can contain other packages. [FS98, p.115], [Oes97, p.181f]
 

1.1.2 Method

A method consists of a notation and process guidelines when and how to use the provided diagram types during the modeling process. Many methods claim to be suitable for all kind of projects. According to Fowler and Scott, this is not true. They recommend to consider certain environment parameters like the size and experience of the development team or the size, complexity and type of the problem before making a decision for one method. FS98, p.27].
The UML, however, is a mere modeling language - it contains no process guidelines. Nevertheless, it can be used to support different modeling methods. Professor Colin Atkinson showed in his lecture on "Object-oriented software design" how the Fusion process can be adapted to use the UML as its notation [Atk97].

1.1.2.1 How to create and verify a requirements specification

Both the UML and Rhapsody give no process guidelines how to produce a requirements specification.

1.1.2.2 Completion criteria

The UML gives no completion criteria, too. The same is true for the tool.
 

1.1.3 Description of the Rhapsody Tool

iLogix Rhapsody is a CASE - Tool for embedded systems software development. Rhapsody is claimed to be "The Industry's first and only UML based objectoriented analysis, design and implementation tool for embedded systems and software developers." [iLogix Website].

In our seminar we used version 2.0 of Rhapsody which is the newest.
Rhapsody supports 4 different UML diagrams:
statechart diagrams, sequence diagrams, use cases and class diagrams.
In the browser window of Rhapsody all classes, diagrams or packages of a system are hierarchically arranged in a  tree, where they can be selected for view or further development.

Rhapsody offers automatic C++ Code generation and code generation with additional simulation functionality. The integrated Simulator component allows to animate the compiled code in the Rhapsody environment with animated sequence diagrams and animated statecharts. During the Simulation the state of all instanciated objects and variables can be viewed in the browser window.
Due to the functionality of Simulation, the focus of work remains at the design level throughout debugging and verification. As a result, Rhapsody allows increased focus on software design while actually reducing cycle times.

Rhapsody offers Unique Model / Code associativety, which treats the code and model as different views of the same design, provides efficient readable code, and enables round-trip engineering of the generated code. That means the generated code can be changed by the developer on the code level and reimported into Rhapsody.
 

1.2 Our approach

This chapter contains information about how we have organized our proceeding. In particular, we describe our personal development process. A few aspects of the final specification complete this chapter.
 

1.2.1 Method

We divided the development of the tamagotchi specification into two phases - a conceptualization phase and a realization phase.
All steps of the conceptualization phase were done without using the Rhapsody tool, since it has not been ready for operation during the first weeks of the term.
We did some ordinary brainstorming to gain a first idea of the Tamagotchi. The next step was to identify the use cases - what tasks are to be done by the system. They were the starting point for the system class diagram that now began to evolve.

In the realization phase we began to use Rhapsody. During this phase, we identified appropriate increments and did the necessary extensions to the class diagram and to each affected statechart diagram. Having finished a system increment, we used the built-in simulator component to perform a series of tests. Detected errors were corrected before performing a new test. After testing, we checked whether all system requirements had already been implemented. Finally, after many iterations, we were convinced that our specification met every requirement. The system specification was handed to another team for a review. During the review, further errors were detected and afterwards corrected.

1.2.2 Teamwork

Both UML and Rhapsody support partitioning of the requirements. Classes can be seen as separate areas of responsibility with their interfaces as a contract between different developers. The ease to identify independent increments and the possibility to add additional attributes and methods to a class without side-effects for already existing methods also supports the division of labor. In addition to this, Rhapsody provides an interface to use the Revision Control  RCS. Nevertheless, we did not develop separately because of three major reasons:

1. the tool has only been installed on one computer
2. only one group member got a professional tutorial
3. working together enabled a quick and direct feedback

1.2.3 Consistence of the specification

We validated our system specification through the graphical simulation of the scenarios based on all equivalence classes that came to our mind. Finally, another group reviewed our documents. This review was not a complete checking of all system requirements, but a rather quick test of several randomly chosen scenarios. Therefore, we cannot speak of a truly verified system. The tool's automatic consistency checks did a good supporting job, however.
 

1.2.4 Size of the specification

We used only slight simplifications concerning the textual interface: "A Mametchi eating a snack" was easier to implement as an animated graphic. Apart from that, we believe that we succeeded in meeting all system requirements - even the timeouts have been implemented as required. We implemented additional simulation events like "sim_night" to speed up the simulation.

The final size of our specification is as follows:

• 2 class diagrams
• 16 statechart diagrams
• 5 sequence diagrams
• approximately 16.000 line of code were generated (including code to support the graphical simulator component)
   

1.3 Specification of the functionality "playing"

To meet the requirements of the functionality "playing", we designed a class called "Game". This class controls the number of rounds played and number of rounds won, and sends appropriate events to the class "Tamagotchi" to update the happiness of the Tamagotchi and to display the necessary Tamagotchi animation (won, lost, playing).
It also turns on the beeping when the game is started and turns it off when the game ends, by sending events to the buzzer.

statechart of the class Game

Concerning the playing functionality the only requirements that are implemented in class "Buzzer", are to keep beeping during a game. On the event "start_game_buzzing" the substate "gamepeeping" is entered and the beeping is started, on the event "stop_game_buzzing" the substate "gamepeeping" is left and substate "idle" is reentered. The beeping stops.

statechart of the class buzzer

The "playing" functionality must be selected in the menu of the Tamagotchi. We designed the class "Menu" for the menu of the Tamagotchi. Only the substate "playstate" is relevant for the "playing" functionality. On the initial transition of "playstate" the game is started through the event "start" send to the class "Game".
The class "Menu" receives the events "m_pressed" or "l_pressed" whenever the middle button or the left button on the Tamagotchi is pressed. In "playstate" these events are resend to the class "Game" to enable the class to receive inputs form the user to during the game.
The "playing" ends, if the right button is pressed (event "r_pressed" received by "Menu"), the substate "playstate" is left and on the leaving transition the event "end" is send to "Game".

statechart of the substate "Tamagotchilife" of the class "Menu"

1.4 Experience

This chapter contains a summary of the experience that we gained during the seminar.

1.4.1 Time spent on the seminar

Together, we needed 40 hours to get used to the notation and the CASE-tool - both topics with an equal share of time. This number represents the sum of each person's expenditures. We decided to delimit the training phase with the completion of the Safety Injection System. Nevertheless, it is a bit difficult to draw a clear border between the training phase and the productive work, since we were far from being expert software designers. So, we kept learning and reading literature while developing the tamagotchi.
The development of the tamagotchi took us about 230 hours (again, this number represents the total sum of the whole group). The overall expense contains all activities that were necessary for the modeling: the conceptualization, the realization, the simulation, and the review. While the major share fell to the actual realization, a considerable amount of time could have been saved with a better tool documentation.
The making of the transparencies and of this report took us approximately 150 hours.

1.4.2 Experience with the UML

The UML was rather easy to learn since all three of us have already used the Object Modeling Technique (OMT), which diagram types are similar to the UML style. A good introduction were the books "Objektorientierte Softwareentwicklung mit UML" from Bernd Oestereich [Oes97] and "UML konzentriert" from Martin Fowler and Kendall Scott [FS98].
UML is a rather powerful notation, because it offers a big variety of different diagram types and the three already mentioned dimensions of modeling: the structural, the functional and the behavioral aspect. Process guidelines would have been a welcome help to master the early stages of modeling, but the UML does not provide any hint at all. Besides, it can be hard to chose between the different diagram types that are provided by the UML. We did not have to take this decision however, because the tool does only support four of the eight different types.
At the beginning we had the problem that the class "Tamagotchi" became more and more complex. At the end, it contained nearly all system functionality. All other classes were much smaller and served more or less as simple data containers. Soon, it was obvious that such a design would not share the typical benefits of a modularized object-oriented approach. The behavior of this class was so complex that is was impossible to work out a lucid statechart diagram.
Our final class distribution evolved after many inner-group discussions and some hints of our tutor. We refined the tamagotchi class into a hierarchy of an abstract superclass tamagotchi and several subclasses - one for each evolution level of the virtual chicken. Apart from that, we introduced a class "Game" to gather all behavior concerning the playing.

1.4.3 Experience with Rhapsody

The installation of the Rhapsody CASE-tool by Ilogix took a whole month. First, the necessary license key was missing. Then, the available C++-compiler was not supported by the tool - so that a new compiler had to be bought.
During the realization phase we encountered the problem how to work out the sequence of the class constructor calls and the necessary includes. Apparently silly error messages turned ot to be caused by not setting the multiplicity of associations in the class diagram. Both the online help and the printed documentation did not help us with these tricky situations.
A positive aspect was its intuitive operation: drag & drop, cut & paste and the use of icons - to mention only a few features. The arrangement of every specification object in an expandable tree (called the browser) allowed a quick and comfortable work. The easy double-click navigation made it possible to inspect every detail almost instantaneously. An automatic consistency check helped to avoid some usual sources of error. For example, every variable used in a statechart diagram was automatically tested against the relevant class declaration.
The animated simulation was important for the quick validation of design increments. All objects and their values can be inspected through the browser during a simulation. Animated statecharts and sequence diagrams are generated automatically and let the user observe the behavior of the whole system. Finally, the possibility to inspect an compile-time error by double-clicking on the actual compiler output was a good assistance.

1.4.4 Review

We had to review the specification of the SCR-group, and vice versa. We did it tool based because of the lack of time. That means, we did not learn the other notation but sat together in front of the computer and let the "expert group" simulate the scenarios we wanted to see. We had not enough time to achieve a complete coverage with the system requirements. So, what we did was not more than a random sample.

1.4.4.1 Review of the SCR specification

The main deficiency of the specification of the SCR-team was the missing linkage between their tamagotchi backend and its frontend. At the stage of the review the two main system sections did not yet fit together. This made it almost impossible to review the specification. But there more reasons that make it hard to check the completeness and the comprehension of the specification: the SCR*-tool is only a scientific prototype - its handling is rather uncomfortable and awkward, since it has been developed with significantly less manpower than our commercial tool. For example, an annoying display fault made it hard to follow the simulation: Every variable that had changed its value since the last simulation step was "highlighted" with a black box. Unfortunately, the value was also displayed with black letters. Besides, the tables that dealt with the behavior of the tamagotchi contained a huge amount of different variables. The other group claimed that this fact was because the tool demanded such a complex modeling. Consult the final report of the SCR-team for a deeper insight in this. Finally, the SCR*-tool compels the user to set most of the many variables manually during the simulation.

1.4.4.2 Review of the UML specification

Rhapsody makes it easy to observe the system's behavior through its good simulator component. One can observe every class with relevant behavioral aspects in an animated statechart. Every instance of a class and every attribute value can be viewed with the tool's browser. Animated sequence diagrams complete the set of useful utilities. Unfortunately, the tool does not support a textual review, because entry and exit events of the statechart diagrams cannot be printed out.
Since some system requirements are mapped into more than one class, it may be difficult for persons who do not take part in the development process, to survey the implementation. A data dictionary and a project wide usage list for attributes, methods and events would have been handy.
As a result of the review of our specification, we learned that our tamagotchi had problems to fall asleep. When the "Bioclock" class (the tamagotchi's timing component) sent the sleeping signal while the user was playing with the tamagotchi or about to feed it, an inconsistent behavior was triggered. Although the tamagotchi object entered the state "asleep" and refused every user signal, the game's and the menu's states remained active. The problem was solved by introducing "asleep" -states for the mentioned classes, too.
 

1.5 Conclusions

This chapter contains a judging of the utility of teamwork in general and of the used notation and tool.

1.5.1 Appraisal of the teamwork

Even though we did not work independently, we believe that we profited by the team development. Most of all, the direct inner-group feedback helped to detect many errors before they could find their way into the specification. Brainstorming sessions were a very fertile means in the conceptualization and the early realization phase. Finally, the mutual motivation helped to overcome many obstinate errors.

1.5.2 Appraisal of the UML

The UML proved to be a mighty and understandable notation. It supports an incremental development because of the modularity of the classes and the possibility to decompose complex aspects hierarchically. Besides, the various concurrent behavioral aspects of an embedded real-time system like the tamagotchi can be captured easily in the statechart diagrams. The division into reasonable classes was a bit tricky at the beginning. After the elaboration of a good class diagram however, the object-oriented view of the system meets the human way of thinking.
The fact that the UML is about to become the standard object-oriented modeling notation is likely to produce synergy effects. The designers will at last be able to concentrate on the more important facts like design patterns instead of always be forced to learn new notations.

1.5.3 Appraisal of Rhapsody

Altogether, we were content with the Rhapsody tool. Although Rhapsody does not provide all UML diagram types, all we needed for our specification was at hand.
A very positive aspect was the already mentioned intuitive usage. Automatic consistency checks helped to avoid some usual sources of error. For example, every variable used in a statechart diagram was automatically tested against the relevant class declaration. The animated simulation was important for the quick validation of design increments. Finally, the possibility to inspect an error by double-clicking on the actual compiler output was a good assistance.

But there were also some negative points. Both the online help and the printed documentation were rather fragmentary. Most tool handling problems had to be solved by trial and error. The absence of an undo-function was a source of frustration, especially because sometimes even a manual "redo" was impossible. Therefore, one should often make backups. Another weakness has already been mentioned: The fact that in a statechart diagram, all one can see from entry and exit events are ">" - signs makes it impossible to review the printed specification.
Apart from the removal of these weaknesses, it would be desirable to have some additional features: A simulator-frontend would make the simulation more comfortable. With Rhapsody, the user has to specify extern trigger signals in a textbox. Additionally, Rhapsody should provide all UML diagram types to make it fit for every UML based development method. Finally, it would be fine if the product supported a greater variety of platforms and compilers.

Nevertheless, we are convinced that using Rhapsody allowed us to produce a better specification than a simple diagram drawing program. Besides, further projects would benefit from the familiarity with the tool that we gained by now.
 

1.6 Literature references

• [Oes97] : "Objektorientierte Softwareentwicklung mit UML", Bernd Oesterreich, Oldenbourg, ISBN 3-486-24319-5
• [FS98] : "UML konzentriert", Martin Fowler and Kendall Scott, Addison-Wesley, ISBN 3-8273-1329-5
• [Atk97] : "Adapting the Fusion Process to Support the UML", Colin Atkinson, Object Magazine, Sigs Publications, Nov.97
• Reference website : www.rational.com
• Reference website : www.ilogix.com

WS 1998/99 Christian Becker, Steffen Glomb, Michael Graf