On generic method models

Abstract

The generic method model assumes that methods abound and method engineering and application engineering is done in diverse areas. Therefore, it is necessary to understand the notion of a method independent of information systems and software engineering. The generic model presented here abstracts out from product and process meta-models to define a system of concepts that can be used in any domain. Additionally, it integrates in it essential features of methods like quality checking, guidance, backtracking, and traceability. The proposed generic model looks upon a method in two parts, the static and the dynamic parts. The former provides the basic structure of a method whereas the latter is the enactment support provided for application development. The static part provides the notion of method blocks and dependencies between them. Method blocks can be enacted. The generic model is a triple <M, D, E> where M is the set of method blocks, D is the set of dependencies between method blocks, and E is the enactment mechanism.

Appendices

Appendix 1

We show here an example of the use of the generic model by instantiating it with the meta-model of [12]. For reasons of space, we assume knowledge of this meta-model and shall not explain its concepts. The focus shall be on giving a flavour of the way the generic model can be instantiated to yield the meta-model. Thereafter the CAME tool, MERU, reported in [25] can be used to engineer the method itself.

The static part of the generic model is instantiated to yield meta-model statics, instances of method blocks and the set of dependencies between these. In our meta-model, method blocks are instantiated to purposes, product primitives to conceptual structures and fixed structures, and process primitives to operations which can be of two types, product manipulation and quality checking. There are four dependency types, requirements, removal, activate and inactivate. The set of dependencies is instantiated with dependencies between purposes of different types.

Through the click and drag features of the generic-CAME tool, the instantiations of product primitives with conceptual and fixed structures shown in Figs. 12 and 13 are arrived at. As shown in Fig. 12, conceptual structures can be partitioned into two clusters. The first cluster classifies them as either simple or complex. The second cluster partitions conceptual structures into disjoint classes of structures called constraint, definitional, constructional, link and collection of concepts, respectively.

Fig. 12

The conceptual structure

Fig. 13

The fixed structure

Figure 13 shows the product primitive instances that identify the criteria that must be met by a good quality product. There are four kinds of fixed structures as shown. Again, these are created by the drag and drop facilities of the generic-CAME tool.

Operations identify the instances of process primitives of the generic model that operate upon conceptual and fixed structures to provide product manipulation and quality checking capability to application engineers. Again, the generic-CAME tool is used to produce Fig. 14.

Fig. 14

The operation

There are two operations in the basic life cycle class, create and delete. The relational class of operations is axiomatically defined and this definition can be found in [15].

A purpose is an instance of the method block of the generic model. It is a pair

$$ {\text{Purpose}} = <{\text{structure}},\,{\text{operation}}> . $$

Thus, the following are purposes

$$ \begin{aligned}{} & <{\text{simple}}\,{\text{constructional}}\,{\text{structure}},\,{\text{create}}> \\ & <{\text{simple}}\,{\text{constructional}}\,{\text{structure}},\,{\text{method}}\,{\text{constraint}},\,{\text{method}}\,{\text{constraint}}\,{\text{enforcement}}> . \\ \end{aligned} $$

The definition of the set of meaningful purposes of the meta-model is supported by the generic-CAME tool which generates the cross product of structure and operation. This cross product is presented and the meaningful purposes are then selected. The complete set of purposes can be found in [25].

Finally, the set of dependencies of different types are instantiated and the generic-CAME tool keeps an internal representation of the dependency graphs.

The enactment algorithm is inherited by the meta-model. Therefore, its full enactment power including guidance, tracing and backtracking is available. The meta-model is validated using this algorithm to enact typical purposes expected to be found in a method which, in turn, shall be produced from the meta-model.

Appendix 2: Glossary

Product primitive	The smallest unit that can be operated upon in a method
Process primitive	An atomic action that can be enacted
Method primitive	The smallest meaningful process unit of a method that can be enacted. It is a pair <product primitive, process primitive>
Complex method block	A composition of simpler method blocks
Abstract method block	A generalization of a method block
Method block	It can be either a method primitive, a complex or an abstract method block
Product part	A part of a product that is the focus of further development
DPC	The product part together with the method block that can operate upon it. It is the smallest unit of the development process
Development process	The sequence of DPCs enacted to build the product