TOOR: A System for Tracing Object Oriented Requirements

A brief summary

by Francisco Pinheiro


TOOR is designed for tracing requirements in system development. It considers as objects, in the computing science sense of the word, any artifacts used during the development of a software system, e.g., an interview transcript, a video tape, a design chart, a program specification text, a system manual, etc. It also considers the possible relations between any two objects as an object itself.

The idea is to specify the objects that can take part in a software development process, use TOOR to input these objects as they are created, and then trace requirements, making use of the relations among the current collection of objects. In this approach requirements are also objects.

For many more details, see An Object-Oriented Tool for Tracing Requirements, by Francisco Pinheiro and Joseph Goguen, IEEE Software (special issue of papers from International Conference on Requirements Engineering '96), pages 52-64, March 1996.

Further topics in this document:

The TOOR specification

Taking account of the specific nature of different development processes, the classes in TOOR can vary from project to project. This is achieved by means of a FOOPS specification of TOOR. This meta-description makes the tool very general and provides for great adaptability. Note that the FOOPS specification of TOOR should not be confused with the specification of the system being developed using TOOR. For example, we can use an interview transcript to extract a requirement which will be used when specifying a module about, let us say, some kind of account in a bank system. Interview, Requirement, and Specification are classes of TOOR, but Account and Bank are classes of the system being developed. Both are specified using FOOPS, but they are at different levels.

Setting up the tool

When starting a project, a setup should be chosen or a new one should be created. This determines what kind of objects one can use. To create a new setup, the TOOR specification is evaluated by FOOPS, and the result is used to build the templates for the objects. The placement of the templates in menus and the layout of the templates are also part of the tool setup.

There are two main menus for templates (classes): one for relations and the other for objects (that are not relations). The menu hierarchy can be different from the class hierarchy. After the TOOR specification has been evaluated by FOOPS and the templates have been created, the user is presented with the class hierarchy and a standard menu hierarchy derived from the former. Then the user can make changes in the menu hierarchy to adapt it to the characteristics of the project.

The layout of the templates is fixed, but the user can modify the number of lines in each field of the template. So the description field of a document can have ten lines, while the author field can remain a single line. While the possibility of changing the number of lines in fields of a template is important for visually presenting the information contained in it, all fields are filled according to a common procedure powerful enough to cope with most situations, as explained below.

Filling in templates

Templates in TOOR are really forms containing a title, which is the name of a class, and a field for each attribute of the class. The fields are composed by the name of the attribute and a space of variable length where the value of the attribute may be shown or typed in. If the attribute has a constant value declared in the TOOR specification, then those values are automatically placed in a pulldown menu that can be activated by clicking on a button at the side of the field.

The value for each attribute can be typed directly into the corresponding field or, alternatively, can be extracted from a file or typed using a text editor. To type directly into the field, the user just has to place the cursor inside the field and type. The name of the attribute is really a button which activates a pulldown menu containing the options to fill in the field using a text editor or information in some file.

An object instance is created by filling in the appropriate template for the class to which the object belongs. Validating each object, i.e., verifying whether the attribute values obey the specified axioms, is done by FOOPS. TOOR sends FOOPS the object to be evaluated, and as a result an object instance is created in the FOOPS database. Here a word of caution is necessary. FOOPS will not evaluate the image of a video-document or a bitmap representation of a design chart, for example. This kind of attribute is referred to by means of an identifier; in TOOR a bitmap or image file contains the value of the attribute. In fact, these are object-valued attributes.

TOOR-FOOPS communication

The communication between TOOR and FOOPS is through a communication manager, which receives TOOR requests, passes them to FOOPS, gets the results, and sends them back to TOOR. The TOOR-manager side of the communication channel is implemented via a UNIX socket. The manager-FOOPS side is implemented by means of two unnamed pipes with the redirection of the standard input and output channels of FOOPS through those pipes. In that way, there is no need to develop a special version of FOOPS to talk to TOOR; FOOPS is used as it is. All messages passed to FOOPS are FOOPS commands, and all messages received from it are FOOPS results. Built-in functions, which are already a feature of FOOPS, are used to cope with the specific necessities of TOOR. So in the event of a FOOPS upgrade or a modification of the FOOPS code, the only things that need to be modified, if any, are the built-in functions. Besides the advantages of making the development of TOOR independent of FOOPS, so that bugs are restricted to TOOR, this approach also shows the expressive power of FOOPS.

Browsing objects

Objects and relations between objects are presented in two independent windows. A large window is used to show objects and their relations in a graphical way, and a smaller one is used to list the objects according to several criteria: all objects of a given class, all objects participating in a given relation, etc. The user can browse and select objects and relations in both windows.

Hyper-media characteristics

As TOOR is intended to deal with requirements extracted or derived from several kinds of documents, it is useful to trace backward and forward to the original form of these documents. This means that TOOR has to have some sort of hyper-media capability. At the moment DOMAIN is being considered as the possible interface between TOOR and the Chimera hyper-server. This seems fruitful mainly because DOMAIN by itself addresses requirements issues not covered by TOOR. It can be used for requirement and scenario analyses, while TOOR provides for requirements structure and traceability.

Modularizing requirements

Entering a requirement into TOOR gives rise to a requirements module, which is a kind of FOOPS module where the requirement, the other objects related to the requirement, and the relations themselves are declared. Requirements modules can be structured in just the same way as FOOPS modules, using importation and parameterization. This, together with the fact that the requirements modules can have not only informal axioms but also (formal) FOOPS axioms, gives a nice integration of the formal and informal aspects of the system development process. It also supports requirements spread over several phases of the development process.

Tracing requirements

Requirements are traced backward and forward to documents and other objects by means of the relations given between the objects involved. The precise characterization of the possible relations, their formalization and, consequently, the constraints that they put on the kinds of possible changes will be the main feature of our traceability model, which is now being worked out.

TOOR status

Presently, the tool setup, with the automatic creation of templates, the changing of template layout and menu hierarchy, and the creation of a new setup from a FOOPS specification of TOOR are working features. The TOOR-FOOPS communication is also done as described above. The presentation of the objects and relations in both graphical and textual forms are under development. The next planned step is to create the built-in functions to be used in the TOOR-FOOPS communications.
To Systems index page
To Joseph Goguen homepage
Maintained by Joseph Goguen
Last modified 23 February 1999