TOOR: A System for Tracing Object Oriented
Requirements
A brief summary
by Francisco Pinheiro
Introduction
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:
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.
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.
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.
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.
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.
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.
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.
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.
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