IPSYS TOOLBUILDER

IPSYS ToolBuilder is an integrated system that combines the efforts of six universities and three research projects in the UK [Alderson 91]. Different parts of the system communicate through a common data repository. The meta-model of ToolBuilder is mainly based on three models, which are entity model, frame model and shape model, (see appendix B)

The entity model is an extended entity relationship diagram and a set of entity type definitions of the described method. Each entity represents a method concept and it can have a number of attributes to describe the internal state of the concept. Four types of relationships are provided, namely subtyping, composition, reference and derived relationships. The first two are borrowed from object-orientation. A reference relationship can be considered as an association between concepts in different frames, whereas a derived relationship is a link that depends on all the above relationships, including the derived relationship itself.

The frame model describes all user-defined frames which appear in run-time. Each frame is based on an entity type in the entity model. There are three types of frames. A structured text frame is a textual specification which can be used as a concept template, a description or a

catalogue; a diagram frame is a graphical specification to present the method model pictorially; and a root frame is basically a structured text frame that initialises the system when it starts. Each structured text frame has a number of subsections to define the structure of that frame, and the frames can communicate through sharing objects [IPSYS 92].

In addition, the shape model provides facilities to define the graphical presentation, and each individual notation is stored as a shape set or as a linkstyle set. Since ToolBuilder is fairly well known in both academia and industry, it is adopted to map our meta model to the metaCASE tool semantics. A detail description of the ToolBuilder is given in appendix B and the full comparison with our meta model is shown in chapter eleven.

SIGNIFICANCE

ToolBuilder is a comprehensive integrated metaCASE tool. Despite the massive number of structured text frames needed to declare a radical method, the basic meta model is definite and explicit. The following points are noted:

• The entity model is a fairly simple and clear documentation of method concepts. Unlike ObjectMaker, each concept is associated with its own semantics directly, such as attributes, relationships and their related features. The shortcoming is that there is no straight distinction of a frame as a presentation of an entity or a tangible concept that must be denoted in the entity model. For instance, an object diagram can be referred to as a presentation or as a concept according to the denotation of the user. Some notions are debatable, such as persistence of an object can either be described as concept or attribute. • ToolBuilder allows implementation ‘directives’ to be added in composition and/or

reference relationships. These directives include set of, sequence o f owner o f source,

target, name and reverse name etc. However, it may be advisable to describe individual conceptual aspects explicitly. The first two deal with cardinalities of source and target entities in a relationship, whereas the next three are used to denote the role of associated entities in composition relationship. The last two naming directives are used as references to the specific directional relationship. These directives are declared in this form because of the implementation requirement.

• It is relatively easy to formulate relationships in ToolBuilder, although some of them are mainly for navigational purposes rather than conceptual exposition. This is because ToolBuilder requires each navigation path in (frame/object/field) operation to be denoted by a single relationship between entities. Some reference relationships and the three types of derived relationships (path/aggregation/user-defined) are designed for this purpose. For a meta model, precise and concise representation is important. Unnecessary concepts and relationships, such as implementation constructs, should be eliminated or avoided.

• On the other hand, the navigation paths present an implicit model of the CASE tool processes, since the only accessible means of an entity is through one of the paths from the current entity.

• The precondition and trigger in each operation are defined as the guard condition and service supported to the underlying entity. These are essential modelling mechanisms in denoting processes, such the pre- and post- conditions described in a MASP specification (section 3.3.1).

• In ToolBuilder, each frame virtually represents a new state of the model with an entry action, which is basically displaying the frame and constructing a different set of operations available in the new frame. There is no explicit representation of method

process in the meta model. This is, in fact, a great drawback of most metaCASE tools in term of method representation.

• Method heuristics are not formally described in ToolBuilder and many other CASE tools. This makes the tools a notational description rather than a complete documentation of the method. A good method should have a well-balanced description of concepts, processes and heuristics. Hence, a good meta model should have a comprehensive specification on these three aspects.

• The user-defined graphical presentation and adaptability of external environment (such as embedding C code) are the main advantageous features of ToolBuilder. The open method design is more favourable than the closed method design as in ObjectMaker (section 3.4.1).

3.5 SUMMARY OF INVESTIGATION