Figure 1. The HOORA system
Contractor:
E2S (B)
Funding:
Advanced Systems and Technology
Programme Phase 4
The European space software development environment (ESSDE) currently supports a functional method for requirements analysis (SADI) and an object oriented method for design (HOOD). There are, however, differences between the paradigms (the underlying patterns) which govern the functional and object oriented methods. Results produced by the former do not fully match the inputs needed by the latter, impeding traceability between what is required and what is produced.
In the meantime considerable progress has been made in object oriented requirements analysis, making it feasible to introduce this technique into industry. Consequently ESA placed a contract with the Belgian company, E2S, to identify object oriented analysis techniques which would provide sufficient clarity and which would satisfy ESA's needs for suitable process, documentation and supporting software tools.
The project, started in January 1993, took two years to complete and produced a new method called HOORA. Support tools for HOORA have been produced in versions for Unix platforms and for platforms running under Microsoft Windows. The latter are freely available from E2S. The user and reference manuals for HOORA are avilable to the public via Internet (ftp.estec. esa. nl/ pub/ wm/ wme/ hoora).
Major ESA requirements for a method of object oriented requirements analysis were:
A survey of more than twenty existing methods was conducted. Rambaugh s object modelling technique (OMT) was considered the most promising because of its sound concepts and extensive documentation. Its weaknesses-lack of clear process guidelines, lack of complexity management and lack of consistency between models-could be overcome.
OMT could be selected as the basis of the new HOORA method, provided the following changes were implemented:
Rules for mapping between the HOORA and the HOOD entities were established to derive an initial architectural design from the model.
HOORA supports three different views of the system under development (Figure 1).
These are:
The requirements model specifies and helps in formalising user requirements. The method used encourages the identification of common terms (grouped in a lexicon) to be used throughout the project.
Figure 1. The HOORA system
The static model defines all of the structural information about the classes in the problem domain. Classes are characterised by attributes and operations. They are linked by association, aggregation and specialisation, in a class relationship diagram (Figure 2).
Figure 2. Example of a class relationship diagram
The dynamic model describes the system behaviour. Interactions between classes are formalised in a class interaction diagram, and are further specified by the use of state transition diagrams and transaction trace diagrams. The latter, sometimes called message passing charts, offer the capability to identify possible scenarios.
These models are tightly integrated with each other. Both the dynamic and the static models relate to the requirements model (user requirements and terms). The dynamic model and the static model share information, since they represent different views of the same objects; an operation in the static model is a transaction in the dynamic model. (Figure 3 and Figure 4).
Figure 3. Example of a class interaction diagram
Figure 4. Example of a state transition diagram
Models elements are defined in a hierarchy, using a concept similar to the HOOD method, in which the analyst can focus on a particular aspect of the system without losing any information about the surrounding classes.
The presence of an element in the static and dynamic models constitutes a software requirement. The definition of the element defines the information necessary for its complete description. A systematic method is used for translating model elements into natural language requirements. In addition, the terms (already defined during the user requirements analysis phase but possibly refined) are added to the software requirements document. All diagrams created during modelling are put into the software requirements document, but the information can also be found in a textual form.
As the software requirements are derived from the information contained in the model, they are different from the original user requirements. They are far more detailed and in a form that has been checked for completeness and consistency. The format of the automatically generated software requirements documents is compliant with ESA's software engineering standards.
The HOORA analysis tool (HAT) is available for systems running under Microsoft Windows 3.1 (for a PC) and Motif (for a Sun work station). The environment provides full support for the method including the automatic generation of an initial HOOD architecture. Documents are generated in rich text format (for a PC) or in Unix-based maker interchange format. The HOOD design is generated in a standard interchange format, HSI. The PC version can be obtained free of charge from E2S.
HOORA, HOOD and the ADA language provide a consistent approach to software production, exploiting object orientation from the early conceptional phase through to final testing.
HOORA satisfies ESA s needs for a system which generates a complete software requirements document and not simply a set of diagrams. It also provides an easy transition to HOOD.
The HAT tool, which is publicly available, offers easy acquisition and verification of the HOORA concepts by direct use.
Preparing for the Future Vol. 5 No. 4.