A number of meta modelling techniques are available in both academic research and industrial products. Since the emphasis and the requisite of the problem domain is different in each one, there are various shortcomings to each approach. However, some significant experience and/or representation requirements can be drawn from these attempts. This chapter investigates the meta modelling techniques based on three categories: method integration, meta modelling research and metaCASE tools.
3.1 INTRODUCTION
Meta knowledge of the software development method is not a new topic to either the commercial market or the research field [Wen-yin 92] [Wijers 92]. There are many contributions from organisations and institutes all over the world [Kronlof 93] [Carmichael 94]. However, this emerging science should be considered as a combination of technologies from software engineering, design method, advanced CASE tool and artifical intelligence. Some authors even refer to it as method engineering [Harmsen 94] [Nilsen 92]. Most people agree that 'each CASE tool is designed with a model in mind\ A metaCASE is a tool to construct a CASE tool, therefore it must be designed with a meta-model. By looking into the internal formalism of metaCASE tools available, it will help us to recognise the representation of design method semantics and the concepts of meta-modelling embedded in the system, which includes data modelling, method processes, design constraints etc.
This chapter investigates meta modelling techniques in three categories. Firstly, the two major data interchange standards in method integration are presented in section 3.2, namely CDIF and PCTE. Secondly, recent meta-modelling research is studied in order to capture their basis and modelling perspectives. Section 3.3 looks at three proficient approaches in the subject, namely ALF-MASP, SOCRATES Project and MethodBase. Lastly, three prevalent metaCASE tools, namely ObjectMaker, MetaEdit and IPSYS ToolBuilder are reviewed in section 3.4. The costs and benefits of these meta modelling techniques are drawn out to develop the requirements of a generic representation. The final model is aimed to be both method and tool independent. Some significant points in the investigation are presented in section 3.5, which is followed by the conclusion of this chapter.
3.2 METHOD INTEGRATION
There are two bases for method integration: the first depends on data interchange between portable components [Daley 93] [Schefstrom 93]; and the second relies on a common method representation [Potts 89] [Carmichael 94] (see section 3.3). This section concentrates on the first basis by reviewing two well known data interchange approaches, i.e. CDIF and PCTE.
3.2.1 CASE DATA INTERCHANGE FORMAT (CDIF)
The objective of the CDIF is to provide a set of standards that will enable CASE tools to interchange information in a standard format [Imber 91]. It adopts a common four-layer architecture for repositories and similar applications. Each layer in the framework is used to define the layer below it, as illustrated by the examples in figure 3.1a.
0:N IsAttributeOf
RelationshipName
c:d Cardinalities a: minimum source entity
b: maximum source entity c: minimum destination entity d: maximum destination entity a:b q.n H asSource 0:N 0:N HasDestination 0:N | HasSubtype Subtype 1 SubtypeN SuperType EntityName MetaEntity Attributable MetaObject MetaAttribute MetaObject Binary MetaRelationship Meta-Meta-Model
Rules for Building CDIF Meta-Model _______ (e.g. CDIF Meta-Entity)_______
Meta-Model
CDIF Model for CASE (e.g. Entity, Process, Flow, DataStore)
Model
CDIF Models transferred between Tools (e.g. Order System DFD)_______
Data
Instances of objects in Tool Model (e.g. ORDER No. 12345)
CDIF
a. 4-layer framework b. graphical notation c. meta-meta model
Figure 3.1 CDIF Standards
The meta-meta model is composed of an entity-relationship-attribute (ERA) model, which is enhanced with subtyping and relationship cardinalities, as shown in figure 3.1b. Figure 3.1c summarises the meta-meta model by depicting the ERA components in the meta-model. A meta-model splits into two parts: the semantic model and the presentation model. The latter describes the presentation of information to the user, whereas the former denotes the underlying meaning of information in four subject areas:
• core - the aspects required for any objects transferred by CDIF standard; • dataflow modelling - the semantics represented by data flow diagramming;
• entity-relationship modelling - the main forms of ERA modelling in information systems; • data inventory - the definitions of attributes of any object and the underlying data type. These formalisms determine the model that is transferred between tools, whereas the data layer describes the instances of objects in the model.
J. i n v e M l g u i i u n u j i v i e i n u u i f i t c g / u t i u / i , i n c i u i t i u u t u i n g i\co cu« u »
SIGNIFICANCE
CDIF stresses data interchange through standard procedure calls, software bus or broadcast messages [Schefstrom 93]. It provides standards for exchange information and facilities to import/export between different language platforms. No actual data repository or interface services are supported by CDIF [Thompson 93].
From the specification of the meta model above, CDIF does not present any software process or heuristic guidance. It provides meta modelling of the object, but even that is very limited.
3.2.2 PORTABLE COMMON TOOL ENVIRONMENT (PCTE)
PCTE claims to support integration in four dimensions [ECMA 90] [Simon 93] as shown in figure 3.2a, which is based on the framework services amongst the dimensions as depicted in figure 3.2b. Different tools can be incorporated into this model to identify the various services to support the integration [Daley 94]. PCTE considers the platform and environment integrations as external constraints which are not directly managed by the standard.
Integration Description
Presentation appearance of the software environment to the user Data data sharing and exchange amongst tools
Control enhancement of communication between various tools used to support a software process in terms of their invocation Process description and enaction of software process models in
terms of tools invocation
a. 4-dimensions
Figure 3.2 PCTE Standards
Presentation Integration, Control
Integration Tool IntegrationProcess Data Integration Platform Integration Environment Integration
b. integration framework
The advanced PCTE+ Object Management System (OMS) satisfies the requirements of tool integration by introducing the following ideas into the SE database [Oquendo 91]:
• concepts of objects, attributes and links: a specific data model that is derived from the ERA data model and the object-oriented paradigm;
object - a uniquely identified entity that is characterised by a name, a set of supertypes, a set of attribute types, a kind of contents and a set of link types;
attribute - a specific property of an object or a link, that is characterised by a name, a value type, an initial value and a duplication property;
link - a directed binary relationship that is characterised by a name, a cardinality (one or many), a category (existence, composition, reference, designation or implication), a set of possible origin and destination object types, a set of attribute types (possibly empty) and an optional stability property, exclusiveness property and duplication property.
• concepts of composite entities and object’s contents: provide facilities for representing and manipulating data down to the level of fine granularity;
• concept versions of composite entities: provide facilities for storing and accessing multiple versions of single and composite entities while retaining their version history;
• concept of type specialisation: provide facilities for defining new types by extending existing (base) ones while maintaining the compatiability with these base types;
• concept of schema definition sets (SDS) and working schemas (WS): provide facilities for defining database views for tools (SDS - a set of related type definitions which constitute a subset of the database schema, WS - the union of all type definitions in the SDSs);
In addition, PCTE+ also supports the requirements from the SE perspectives:
• mechanisms for concurrency and integrity control: by providing lock mechanisms for ensuring the consistency of concurrent data access operations, and the concept of activity which includes the one of transaction;
• mechanisms for discretionary access control: by means of the concept of security defined as the prevention of unauthorised disclosure, amendment or deletion of information;
• support for multiple programming languages: by defining the database concepts in a language-independent way and by specifying the interface of operations in different programming languages;
• support for distributed architecture and database: by providing a data model whose design takes into account the constraints of a distributed hardware architecture, and a transparent distribution of the database over the network of workstations and mainframes. SIGNIFICANCE
PCTE emphasises the interchanging of portable components (or tools) as outcomes, so neither design process or heuristics are recorded in the OMS declaration. It also lacks a pictorial view of the SDS or the WS. However, PCTE is employed as an information exchange standard for some meta modelling tools, such as [Oquendo 93] and [Saeki 94a].
The major shortcoming of method integration by data interchange is that the approach only handles information transfer between tools (method components) but their internal semantics are not properly addressed. Although both CDIF and PCTE outline an elementary description of ‘product’ as object, there is no conceptual significance to the representation. Moreover, this description is mainly for exchange tool specification rather than a method definition. In this research, the focus is on the other extreme of method integration. That is, to establish a generic model for method representation and to integrate method concepts at a semantic level. The next section presents meta modelling research endeavours to support this approach.
3.3 META MODELLING RESEARCHES
In the academic world, there are numerous research projects in the areas of software engineering [Finkelstein 92], conceptual modelling [Grosz 91] [Siau 92] and CASE tools [Gulla 91]. Some of these studies suggest a requisite for and the significance of meta modelling [Dewal 92], but only a few attempts to tackle the solution explicitly and most of these related projects are fairly recent works. This section discusses some leading meta modelling research projects, and particularly focuses on their method representation aspects. The three projects described are the ALF-MASP metaCASE Environment (from France), the SOCRATES Project (from Netherlands) and the MethodBase (from Japan). Although all three denote method product and process explicitly, the fundamental models are different.
3.3.1 ALF-MASP
The ALF metaCASE environment is developed in the framework of the ALF ESPRIT project. It claims that tool integration is a key issue in CASE environments for supporting the entire software development process [Oquendo 90]. PCTE (section 3.2.2) supports the data and presentation integrations and lacks mechanisms for the control and process integrations. The ALF project extends the PCTE functionality by:
• Control integration - providing means of intertool invocation, communication and synchronisation;
• Process integration - introducing software process interpreters (described later) and software tools between them.
A major enhancement is called the event-reaction mechanism (ERM), which provides the functionalities to express and enforce the two integrations of the software tools on top of PCTE. ERM is represented by a 3-tuple as (E, R, C), where:
• E - an event type that describes situations which raise events of this type;
• R - a reaction type that describes reactions taken when events of type E are raised; • C - a control specification for the triggering of reactions of type R.
ALF has a formalism for software process modelling, called the MASP (meta-Model for
Assisted Software Processes). The ALF project claims that MASP provides the mechanisms for describing a generic process model that can be incrementally and repeatedly instantiated in order to produce project-specific software process models. The MASP description is enactable and can be used to provide a better understanding of software processes and assist the communication amongst developers. Figure 3.3 presents a complete MASP specification and the composed six models are described briefly afterwards [Oquendo 93].
masp = MASP specification description END MASP specification = identifier HAS TYPE operator_type 7 (domain_and_range;) description = object_model_definition (expression_model_definition *;’) operator_model_definition 7 (ordering_model_definition (rule_model_definition *;’) (characteristic_modeI_definition *;’)
domain_and_range = '(’ [ parameter {7 parameter} ] *)’ parameter = par_access p a rjis t7 par_type
par_access = IN I OUT IINOUT I READ I READWRITE parjist = parameter_name {7 parameter_name} parjype = objectJype_name I
relationshipJype_name I attributejype_name object_model_definition =
OBJECT MODEL IS
list_of_schema_definition_sets END OBJECT MODEL
list_of_schema_definition_sets = sds sds} sds = sds_name I sds_definition I sds_extension sds_definition =
NEW SDS sds_name IS typejist END sds_name
sds_extension =
EXTEND SDS sds_name WITH typejist 7 END sds_name
typejist = type {*;’ type}
type = objectJype_definition I objectJype_extension I relationshipJype_extension I
attributeJype_extension I typejmportation objectJype_definition = ot_name SUBTYPE OF
objectJype_names [ WITH
[ATTRIBUTE attributejype_djist 7] [LINK relationshipJype_dJist 7] END ot_name]
expression_model_definition = EXPRESSION MODEL IS list_of_expressions 7 END EXPRESSION MODEL
list_of_expressions = expression {7 expression} expression = event_defintiion I