5 3.3.5 REFERENCING
APPLIES TO TYPE: (
8. METHOD REPRESENTATION
Similar to a software model, a method model describes the structural and behavioural aspects of a SDM. The encapsulated information about the SDM is known as method representation. This representation is based upon a generic meta model to document the product, the process and the heuristic of the SDM comprehensively. In this chapter the method representation of GMR is presented. Some extra modelling considerations are also discussed.
8.1 INTRODUCTION
In meta modelling, the semantics of a method should be represented as concepts or techniques. The ideas of individual fragment, entity and property should be denoted so that they can be used to define the specific task operations and dependence of software development processes in the method. The heuristic guidance and rules should also be included in order to provide substantive assistance for the method engineer. All these semantics should be specified to capture the characteristics of the method. In other words, the method representation is a concise and precise documentation of the SDM. Hence the generic model needs to handle various presentation techniques found in method models.
Chapter three shows various attempts to represent SDMs from different viewpoints, but none of them is satisfactory. There is in the literature no established way of deriving such a model based on capturing method techniques rather than specific methods. In this research we propose such a model and try it out on five SDMs to demonstrate the expressiveness of method representation. These methods are Booch OOD, Codarts/DA, HOOD, OMT and
Ptech (see chapter two for the overviews and justification). They cover a large spectrum of software modelling techniques and emphasise various aspects of systems development.
The concept diagrams of these five methods and the task diagrams of OMT are attached in this thesis as appendices D and E respectively. The detailed description of individual representations of these methods is less significant and they will not be given in this thesis. However, in this chapter the pragmatic model of GMR is discussed. A common specification language is used for the three models of GMR that is known as Method Specification Language (MSL). The complete BNF grammar of MSL is also given.
The organisation of the chapter is as follows. The next section gives an overview of method representation by GMR. Section 8.3 describes some additional considerations in this method representation. The grammar of the three method components in GMR is presented in section 8.4. Section 8.5 shows Prolog clause formats corresponding to the MSL grammar, and the last section gives a conclusion.
8.2 OVERVIEW OF GMR REPRESENTATION
In our generic representation, the semantic information of a single method comprises three parts. The product model describes the method concepts (chapter five); the process model describes the method tasks (chapter six); and the heuristic model gives the method guidance and rules (chapter seven). These components represent the method both graphically and textually. The grammar of each model is documented by a uniform method specification language (MSL), which can then translate to Prolog predicates for execution.
concept diagram product specification
heuristic specification
<=>
productModelSpecification » PRODUCT.MODEL IS listOIConceptDefinitlons llstOfConceptRules END PRODUCT.MODEL heuristicSpecification » HEURISTIC IS listOfHeuristics END HEURISTIC processModelSpecification « PROCESS.MODEL IS listOIProcesses END PROCESS.MODEL task diagram<=>
process specification method(omt, concept(ob(ect)...). method(oml, concept). method(omt, process)...). •). rrvethod(omt, heuristic)...). sem antic knowledge baseFigure 8.1 GMR Method Development
Figure 8.1 illustrates the method development by GMR. After knowledge acquisition of a SDM (see chapter ten) the method product and the method process are identified and depicted by concept diagrams and task diagrams respectively. Each of these diagrams is then converted into the corresponding specification as shown by the hollow arrows in the figure. The method guidance and rules are also documented as the heuristic specification. These processes of information are linked directly to the related concepts or tasks. Finally, all these specifications are compiled into Prolog predicates.
The descriptions of individual constituents are given in the previous three chapters. In this section, we present the enhancement of the meta models and discuss the significance of such method representation. The next subsections introduce the meta modelling techniques based on dissection sets which are followed by shared concepts between fragments. The representation of various peculiar method relationships, such as derived relationship, multiple inheritance and delegation are discussed. Then a further description on the text fragment is given. Finally, a complete structured grammar of the MSL is presented in the last section.
8.3 ADDITIONAL CONSIDERATIONS
This section introduces some extra representation considerations that have not been discussed in the previous chapters. They include dissection set, shared concept, other concept relationships and text fragment.
8.3.1 DISSECTION SET
In chapter five, the product model introduced five method concept relationships to define different types of association between method concepts. These relationships can be considered as primitive (or meta) relationships in the concept diagram, and they should be differentiated from the method relationships. For instance, aggregation, generalisation are method relationships between objects in OMT. However, they are shown as method concepts in the meta level, and the relationship between these concepts and object concept is described by the linking meta relationship. All these relationships are denoted as a link between entity concepts or between an entity concept and a fragment concept.
In a SDM, a concept diagram may contain a number of fragments to describe various aspects of a system. Normally subtyping and referencing are the common concept relationships between method fragments. For examples, in Codarts/DA the systemContextDiagram is a subtype of contextDiagram; and in Booch OOD each stateTransitionDiagram refers to a
stateTransitionTemplate. In this section we introduce another relationship which only happens between fragment concepts. This relationship is to deal with the common concepts across fragments. Since it is very important in fragment dissection and it copes with one or more method concepts between two fragments, the association is known as a dissection set.
taskArchitectureDiagram , dataFlowControlFlowDiagram 1 contextDiagram
\ / s t S tV task operation dataStore term inator dataT ransformation' informationHidingModule dataFlow
Figure 8.2 Codarts/DA: dataFlow and dataTransformation Concepts
Figure 8.2 illustrates the overlapping concepts of different fragments in Codarts/DA [Gomaa 93]. The dataFlow is a link concept to relate entity concepts in each of the three diagram
fragments. For a taskArchitectureDiagram, a dataFlow connects a task and an
informationHidingModule or it links up a task to an operation1 of an
informationHidingModule. For a dataFlowControlFlowDiagram, a dataFlow relates a
dataTransformation and a dataStore. However, a dataTransformation can also connect with a terminator2 by a dataFlow in a contextDiagram. Due to these complex conditions in the
dataFlow concept3, a set of constraint rules is required to present these relationships and this is denoted by the label ‘c’ in the dataFlow box (refer to section 5.3.2.6). The dotted lines show the division between fragments. The line between the dataFlowControlFlowDiagram
and taskArchitectureDiagram cuts through the dataFlow, which means that the dataFlow is a concept applied to both fragments. The dissection set is {dataFlow}. The line separating
contextDiagram and dataFlowControlFlowDiagram cuts through the dataFlow and the
dataTransformation concepts, which means both of them can be shown in these two fragments. Hence, the dissection set is {dataFlow,dataTransformation}.
(dataFtow.dataT ransformation}
contextDiagram
stateT ransitionDiagram
taskArchitectureDiagram dataFlowControlFlowDiagram
Figure 8.3 Codarts/DA: Dissection Sets
A dissection set is denoted by a line joining the two related fragment concepts with the label ‘ds’ on it. Figure 8.3 demonstrates the four dissection sets as they appear in Codarts/DA. In addition the figure shows the two possibilities of common concepts in a dissection set.
• Firstly, it simply represents the concepts that literally appear in both fragments, and the instances of the concept which have no interrelationships at all. In the Codarts/DA example, dataFlows which appear in different diagrams are separate tangible links.
• Secondly, it shows a continuation of concept modelling between fragments. Again in the example, a dataTransformation in the contextDiagram is further described in the
dataFlowControlFlowDiagram and the decomposed diagram of itself.