METHOD ENGINEERING APPROACH

Many software development methods have been introduced in the last decade. Examples of these are object-oriented analysis and design methods, and business process reengineering methods [Rossi 95]. This rapid growth in number conforms with the software quality requirements and the increasing complexity of techniques involved. The classical ‘pencil and paper* approach is no longer a satisfactory solution. The support of CASE tools is an interim result of the crisis, since they provide facilities to develop ‘large-scale’ software as well as to maintain system consistency. However, a CASE tool is always embedded with a fixed set of concepts (or a single methodology), which is found to be inflexible. In addition, there is no support of multiple viewpoints in software development. Therefore, method integration and method engineering have become ad hoc research topics. Meta modelling techniques and metaCASE tools are emerging to fill the gap of insufficiency.

With metaCASE technology, the capability of prototyping is also extended. It advocates an evolutionary approach to the software development cycle. The traditional waterfall life cycle and/or spiral model is elevated to include the method engineering phase, so that a tailor-made method can be produced for the required specification. The proposed three stages prototyping approach is summarised in figure 4.3. The three stages are known as requirement specification prototyping, methodology prototyping and software development prototyping. Since the new software development cycle is different from the approaches mentioned previously, it is referred to as the method engineering approach. The following subsections describe the different phases of this approach.

Requirement Specification Prototyping

Method

SKBs MetaCToolASE

A\ Methodology Prototyping "TFT CAS E Tool A\ Software Development Prototyping -K G enerated ~z Software

Figure 4.3 Three Stages Prototyping Approach

4.2.3.1 REQUIREMENT SPECIFICATION PROTOTYPING

The aim of requirement specification prototyping (RSP) is to provide sufficient knowledge about the problem domain and/or work environment for the next phase (i.e. methodology prototyping). The client forms a wish-list of the target system. The requirement engineer then models the requisite semantics according to the methods available in the semantic knowledge base2. This process is incremental and iterative. It cycles around the client, the requirement model and the engineer until the satisfactory result is obtained.

Moreover, RSP adopts the evolutionary approach of rapid prototyping. That is, various phases of the software development are used to supply different information for the methodology prototyping. For instance, the analysis phase needs more inquiring concepts, whereas the design phase requires more resolving concepts. Different tools may be used to obtain multiple viewpoints on the system. The prototype can be specified by any requirement engineering techniques or tools available.

2 A context free dictionary is provided in the system to lookup method concepts. These concepts must be stored in canonical form that is a common representation throughout the mcthdologies in the semantic knowledge base, (see later for details)

4.2.3.2 METHODOLOGY PROTOTYPING

Methodology prototyping (MP) is the phase for method engineering. The objective of this phase is to manipulate the required semantics and to provide a suitable method or CASE tool for the software development prototyping. The canonical concepts specified by the requirement specification prototyping are fed into an expert server, in which the concepts are matched with method semantics in the knowledge base. The semantics will then map to the information required by a metaCASE tool for the production of an appropriate CASE tool. Such a system is known as an expert server, because:

• It acts as an intelligent expert, which has the capability to search, match and inference the input canonical concepts to the method concepts in the knowledge base. Forward chaining, backward chaining and backtracking mechanisms are provided. The search algorithm, such as depth-first, breadth-first or best-fit search should be available. Similarly, the matching mechanism that includes parameters, such as priorities, weight factors etc., allows the user to optionally select.

• It acts as a knowledge base server to manage and propagate method semantics in the semantic knowledge base (SKB). Since the number of concepts in a method is large and it increases with the number of software development methods in the SKB, the speed of retrieving information from the data repository is vital. An effective server ensures adequate performance in projecting, selecting and joining concepts.

Methodology prototyping is the most important of the three stages. It links the ‘specification stage’ to the ‘implementation stage’ by transforming semantics from requirements to software development. A method prototype is created to bridge the semantic gap between the two stages. From a metaCASE point of view, a method prototype is a CASE tool with the desired method underneath the system.

The main focus of this research is to investigate and to formulate a generic model for representing semantics in a software development method. This is a crucial part of the evolutionary approach, especially in the methodology prototyping phase. A canonical form is invented to integrate various methods in the SKB s. The ability to share information within or amongst method fragments depends greatly on the unified model in the common data repository.

Efforts are also made to reduce the number of notations to a minimum, whilst still representing the complete semantics and various aspects of a method. In other words, the representation must be as precise and concise as possible. Moveover, the representation must be designed with the aim of mapping the method semantics to metaCASE semantics, which is the output channel of methodology prototyping.

4.2.2.3 SOFTWARE DEVELOPMENT PROTOTYPING

Software development prototyping (SDP) is a CASE tool based software development phase. As shown in figure 4.3, the SDP takes the CASE tool constructed by the methodology prototyping stage as input. It proceeds with normal CASE practice, that is to model a software system by the semantics provided by the underneath method. If the code generation facility is provided in the CASE tool, the target software is produced, otherwise the result is a paper model of the specified system.

The work environment depends on the CASE tool produced or in other words it relies on the tool generation ability of the metaCASE tool. Hence the final product varies from system to system and therefore the description is of no interest.

Our generic model captures both the conceptual base of a method as well as the practical base. That is, the model describes the structural and behavioural semantics of a system. The structural semantics show what the concepts are, whereas the behavioural semantics identify how the concepts are constructed. A capable metaCASE tool allows mapping of both types of semantics into the generated CASE tool. In addition the heuristic guidance of the software method is also an important component in the software development prototyping. Section 4.4 provides a detailed discussion about these constituents of a single development method._I