META MODELLING PROCESSES

GENERIC PROCESS MODEL

generic _{Meta Level}

represent represent

METHOD PROCESS p Ut METACASE PROCESS

— physi cal Method Level logical

configure

CASE TOOL PROCESS

specific Software Level

6.2.1 METHOD PROCESS

A method process is the logical process described in a SDM to show the design sequence of the method. Certain literature refers to this as a ‘cookbook approach’, because in theory, a developer can follow the design steps to obtain the software products. However, a rigid approach to design usually leads to inflexibile and largely useless design products. Creativity and common senses are required in addition to the process (see section 6.3 for details). The process of a method is more of an incremental and iterative process, in which the products of design gently unfold over time.

Step Activity

1 identify the classes and objects at a given level of abstraction 2 identify the semantics of these classes and objects

3 identify the relationships among these classes and objects 4 implement these classes and objects

Table 6.1 Booch OOD: Method Process

For instance, the process of Booch OOD [Booch 91], as shown in table 6.1, is a four step design sequence. The first column in the table denotes the design step number and the second column gives the activity description. Booch OOD supports the incremental and iterative process of round-trip gestalt design. This is an incremental process: the identification of new classes and objects causes the developer to refine and improve upon the semantics of and relationships among existing classes and objects. It is also an iterative process: implementing classes and objects often leads us to the discovery of new classes and objects whose presence simplifies and generalises the design.

The Booch OOD has a very simple process model (it comprises only one level and four steps). However, showing the design sequence in tabular form can be a very useful tool in process modelling, especially if the conditions and operations of method processes are considered. The process model of a method is closely related to the product model of the method. For instance, in the Booch OOD example, class, object and relationship are method concepts defined in the product model. The method process is mainly called to determine these concepts. The later sections in this chapter will illustrate that the method concepts described in the product model can be used as input and output tokens to the method process.

As the aim of this research is to develop a generic model to represent a SDM, method process is the main modelling object amongst the three types of processes. Nevertheless, our generic model is powerful enough to represent the metaCASE process as well.

6.2.2 METACASE PROCESS

We described the method process in the last section, that is a logical process model of a SDM. In this section, we discuss the process in a metaCASE tool, which is a physical process model of the method. A metaCASE process is highly dependent on the semantics of a metaCASE tool, such as the data model to represent method concepts and the functional model to describe the method processes. A metaCASE process is the channel to express method semantics to metaCASE semantics, and all these semantics comprise of both product and process models. Therefore, the metaCASE process can be easily clarified into two phases. The first phase involves mapping the logical semantics to the physical semantics and the second phase deals with placing the semantics into the tool.

The technique of mapping method semantics into the metaCASE tool is discussed in chapter eleven. We concentrate on the process of putting method semantics into the metaCASE tool in this section. This metaCASE process describes a sequence of steps that a developer can follow to gradually place the physical semantics into the chosen metaCASE tool. Although this metaCASE process is not a SDM process, we find our meta model also handles this process model efficiently.

determine field determine object specify data model define diagram notation define text subsection specify frame model

Figure 6.2 IPSYS ToolBuilder: An Example of MetaCASE Process

Figure 6.2 illustrates an example of IPSYS ToolBuilder’s [IPSYS 92] metaCASE process. The round-comer boxes denote tasks and the v-shaped arrows represent the control flows in the process model. A developer starts the metaCASE process by specifying the data model of the method, and then develops the diagram and text frames of the required tool. The last step is to define the appropriate diagram notations and text subsections for each frame. The developer can carry on creating more frames. Apart from the incremental and iterative process already mentioned in the last section, this model also introduces the idea of cascade and parallel processes. This is a cascade process: the specification of a new frame requires the formation of shared objects and fields, which then require the definition of the diagram notations and text subsections. Each step refines and describes the details of the previous step(s). It is also a parallel process: the frame specification consists of a number of graphical and textual notations, which in theory can be defined concurrently.

6.2.3 CASE TOOL PROCESS

After the method semantics are placed into the metaCASE tool, it is ready to generate a specific CASE tool of the method. Hence, the generated tool is embedded with the method concepts and method processes introduced to the metaCASE tool. In the software level, the CASE tool is specific to a particular method (or a number of methods if tool integration is provided) and the tool can be used to develop software of a certain domain. However, the metaCASE tool may provide some facilities that allow the process to be refined and/or configured. Therefore, the CASE tool process is first planned from the method process defined in early stage, and then the metaCASE tool may allow the developer to configure the generated process. These relationships are represented by the plan and configure associations in figure 6.1.

determine

sem antics relationshipsdetermine class&objectspecify determ ine

class&object

draw

timingDiagram moduleDiagramdraw processDiagramdraw draw

stateT ransitionDiagram

Figure 6.3 Booch OOD: the Configurable Process

Let us look at an example of configuration by refinement. In figure 6.3, the top four tasks show the process of Booch OOD, which has been tabulated in table 6.1. This part of the figure shows the method process. Booch OOD does not precisely define the activities of each step. For instance, the second step aims to establish the meanings of the classes and objects identified from the first step. This technique involves writing a script for each object, which defines its life cycle from creation to destruction, including its characteristic behaviours. This description is incomplete and ambiguous. However, the developer can configure the process, so that it can be refined to document the semantics of each key abstraction in timingDiagram

and stateTransitionDiagram. This mechanism can also be applied to the other tasks as shown in the figure.

The CASE tool configuration is a major topic on its own [Fisher88], and it is outside the boundary of this research. Therefore, CASE tool processes or configurable processes will not be discussed in the rest of this thesis.

Nevertheless, these diagrams are used to describe the process model of a method graphically. It is good enough to show the sequence of processes, but this does not denote the dependencies between the processes. In later sections, we will develop an enhancement of this diagram to address the problem. The enhanced diagram is known as a task diagram.