ORIGINAL RESEARCH

Naveen Prakash

On generic method models

Received: 9 August 2005 / Accepted: 9 December 2005 / Published online: 10 March 2006� Springer-Verlag London Limited 2006

Abstract The generic method model assumes thatmethods abound and method engineering and applica-tion engineering is done in diverse areas. Therefore, it isnecessary to understand the notion of a method inde-pendent of information systems and software engineer-ing. The generic model presented here abstracts out fromproduct and process meta-models to define a system ofconcepts that can be used in any domain. Additionally,it integrates in it essential features of methods likequality checking, guidance, backtracking, and trace-ability. The proposed generic model looks upon amethod in two parts, the static and the dynamic parts.The former provides the basic structure of a methodwhereas the latter is the enactment support provided forapplication development. The static part provides thenotion of method blocks and dependencies betweenthem. Method blocks can be enacted. The generic modelis a triple <M, D, E> where M is the set of methodblocks, D is the set of dependencies between methodblocks, and E is the enactment mechanism.

1 Introduction

A method has been described in various ways. TheOxford dictionary [1] considers it to be (a) ‘a particularway of doing’ and (b) ‘the quality of being well plannedand organized’. Both these attitudes have been adoptedin Software Engineering and Information Systems. Thefirst attitude is reflected in approaches [2–5] that arebased on the way of working adopted by the engineer tocarry out a task. The second attitude results in the viewthat a method provides the means for well planned andorganized product development. Thus, [6] looks upon amethod as providing the necessary structure using which

a product is built. A method is a collection of tools andtechniques, product and process models, guidelines,checklists, heuristics, etc. that help an application engi-neer to build a suitable product.

For information systems development methods (IS-DMs), the basic technique adopted to understand andengineer methods is that of meta-modelling. Meta-mod-els have been developed with different abstractions andfor highlighting different aspects of methods, the prod-uct aspect [7, 8], the process aspect [9, 10], and integratedproduct–process aspect [11, 12]. Considering the crucialimportance of guidance and tracing capabilities inmethods, a system of three meta-models was defined in[13]. These are (a) ‘basic’ meta-model, (b) guidancemeta-model and (c) traceability meta-model. However,quality issues, those of representing method constraintsand heuristics as well as of determining constraint andheuristic satisfaction have remained unaddressed inmeta-models.

A formal definition of a method [9, 10] was made inthe early 1990s. Here a method was treated as an n-tuplewith n being around 10. Later, with the emergence ofsituational method engineering, the notion of a methodfragment was formalized [14]. This formalization usesten sets and five predicates resulting in a fragment basedmethod being treated as a 15-tuple. Evidently, thenumber of concepts used to represent a method is verylarge and a method is a very complex artefact.

In the last few years we have seen the emergence ofgeneric models that abstract out the common propertiesof meta-models. This results in a three-layer frameworkconsisting of the generic, meta-model and method layers[12, 15]. This idea was tested in [16] and the benefits ofthe generic layer were found to be as follows:

• The generic layer makes explicit nature of the domain.Therefore, it promotes the development of methodsand processes specific to that domain. This improvesthe chances of method acceptability.

• Again, by making explicit the nature of domain, ithelps in understanding and comparing differentdomains.

N. PrakashJUIT, 173215 Waknaghat, Himachal Pradesh, IndiaE-mail: praknav@hotmail.com

Requirements Eng (2006) 11: 221–237DOI 10.1007/s00766-005-0026-1

• The generic layer helps in meta-method engineering. Itwas shown that meta-models of very diverse domainscould be engineered. Meta-models can be checked outfor consistency and completeness under the genericview. This can be facilitated by constructing genericcomputer aided method engineering (generic CAME)tools.

• The generic layer can be used for simulating realprocesses and systems before they are actually imple-mented. For example, in the robotics domain, theentire robot can be conceptualized, and a methodproduced. Using computer aided systems engineering(CASE) support, application processes can be built tocheck that the robot does, in fact, handle the pro-posed range of tasks. If not then the robot can bere-conceptualized. Thus, before constructing the realrobot, its viability can be fully established.

Given this range of benefits of the generic layer, ourfocus now is on the development of a generic model. Ouraim is to build a model that is

1. Simple. Simplicity is measured in terms of the arity ofthe tuple required to formalize it. Thus, we arelooking for much less than the 10 to 15-tuple for-malizations referred to above.

2. Complete. Completeness is to be seen in the range ofmethod features, guidelines, heuristics, etc. that canbe derived from the model.

The generic model developed here treats a method as atriple, <M, DEP, E) where M is a set of method blocks,DEP is a set of dependencies between method blocks,and E is an enactment mechanism for method blockenactment. Clearly, this three tuple is relatively simplerthan the formalizations referred to above. Additionally,instead of treating guidance, traceability and basicmethod capabilities separately as in [13], we put themtogether in a unified whole. The set, DEP, forms the basisof this unification. Finally, our generic model addressesquality issues as well. This happens in three parts. First,constraints and heuristics are represented in a sub-classof method blocks called quality checking method blocks.Second, dependencies tell us which quality methodblocks are to be enacted when and finally, quality methodblock enactment under the enactment mechanismprovides information on satisfaction. With this capabil-ity, the proposed generic model provides a relativelymore complete representation of method features.

Our approach to generic model definition starts off,in the next section, with building a classificationframework that helps us to define our notion of gene-ricity. Thereafter, in Sect. 3, we identify the propertiesthat generic models should have. The implication ofthese properties on generic model development is con-sidered in Sect. 4. The generic model is presented in theSect. 5. This section is divided into two main parts, thefirst dealing with the static part and the second withthe dynamic part. The underlying mechanisms for

backtracking, traceability, and guidance are explainedhere. The section ends with our Enactment Mechanism.Appendix 1 contains an example of use of the genericmodel and Appendix 2 contains a glossary of terms.

2 The four-dimensional classification framework

Methods have been classified in different ways.

1. Methods are classified on the basis of their emphasis.Those that emphasize the functional aspects areprocess oriented; those that emphasize data baseconstruction are data oriented; those that emphasizetemporal aspects are behaviour-oriented methods.

2. Classification is based on the stages of the develop-ment process addressed. Thus, we have methods forrequirements engineering, systems, design, construc-tion design, etc.

3. Classification is done on the extent of use of mathe-matical formalisms. This leads to formal and systemicmethods.

4. Classification is based on the nature of issues handledin the method. Soft methods like Soft Systemsmethodology [17] and SISTeM [18] make it possiblefor different organizational actors to develop a viewof the organization and of the information systemsneeded to support this view. In contrast, hard meth-ods concentrate on the technical aspects of informa-tion systems product development and ignore thelarger organizational roles played by them.

A number of other classification schemes exist [19–22]and each has its own perspective of classification.

Looking now at meta-models, we find

1. Classification is based on the treatment given to theproduct and process aspects of methods. This leads toproduct meta-models, process meta-models, andintegrated product–process meta-models.

2. Classification is based on the method feature empha-sized. This yields [13] basic meta-model, guidancemeta-model, traceability meta-models, etc.

The foregoing classification schemes aid our under-standing of methods and meta-models, respectively.However, we wish to exploit this body of work to help usin arriving at the set of concepts that could go into defininga generic model. Meta-model classification (1) tells usthat there are two aspects of methods, product andprocess aspects. Looking at the product aspect, methodclassification (1) says that products can have differentnature of concepts. Concepts can be for data, function,event, etc. Classifications (1) and (2) also suggest thatmethod products vary in complexity. A final aspect ofthe product concerns the nature of the real world phe-nomena being captured. Information systems methodsare concerned with abstractions of the real world.However, methods in some areas, particularly artificialintelligence, deal with non-abstracted phenomena.

222

Now consider the process aspect. Method classifi-cation (2) suggests that in methods spanning a singlestage products are constructed. However, in movingfrom one stage to the other, a product may have to betransformed to assume another form. Thus, the pur-pose or aim of the method, whether to construct aproduct or to transform a product, is to be taken intoaccount because it determines the nature of the processsteps involved.

The foregoing analysis suggests that four factors ofmethods are of importance in developing the genericmodel. These constitute a four-dimensional space inwhich methods can be placed. We consider these ingreater detail below:

• The complexity dimension: We postulate that thecomplexity of a method is related to the complexity ofthe product to be produced. If a product is morecomplex than another, then the method to produce itmust also be more complex. We measure productcomplexity in terms of product ‘facets’. A facet is theset of tightly coupled concepts, whose instantiationresults in a product. As the number of facets of aproduct increases, the complexity of the methodincreases. The simplest method is the single-facettedone, and we refer to it as atomic. Methods with higherfacets are compound. As an example, a method tobuild an ER product is atomic whereas the Rationalmethod is compound.

• The aim dimension: This dimension considers thepurpose behind the method, what the method tries toachieve. We express method aim in terms of the natureof the product that is to be produced. A product canbe a new one, constructed from scratch, by reuse, etc.or it can be a transformation of another product.Thus, along the aim dimension, there can be con-structional methods and transformational methodshaving the purposes to construct a product andtransform a product, respectively.

• The domain dimension: Here, we consider the natureof the phenomena dealt with in the method. We believethat there are two kinds of phenomena of interest, realand abstract. For example, the ER model providesabstraction-based concepts. Thus, methods to buildER products lie in the abstract domain. In contrastreal domains are of particular interest in artificialintelligence. As an example consider playing with toyblocks. The specific blocks are given and the playermanipulates these real blocks rather than abstractionsof these. A specific method for playing with the givenblocks can be devised. If the blocks are changed then anew method has to be built and, as before, thismethod is also specific to the new game.Thus, we say that the nature of phenomena may beeither real or abstract and we get real domains orabstract domains.

• The semantic dimension: This dimension deals with thenature of concepts of the method. Along this dimensionwe consider methods to use active or passive concepts.

Passive concepts capture passive, data-oriented aspectsof products whereas active concepts capture active,process or dynamic, aspects of products.

3 Properties of the generic model

The foregoing suggests that a generic model should havethe following properties:

1. The generic model should be class independent. Thatis, it should be possible to represent in the genericmodel a method that occupies any position in ourfour-dimensional space.

2. The generic model should be independent of anymeta-model. Essentially meta-model independencecalls for independence from product meta-modelsand process meta-models. Interestingly, meta-modelindependence facilitates class independence as shownbelow.

Product meta-model independence makes it possible torepresent abstract or real domains and active or passiveconcepts. Thus, it facilitates independence along thedomain and semantic dimensions. Similarly, it facilitatescoverage independence because products of any stage ofthe life cycle can be instantiated. Independence along theaim dimension is facilitated because the constructed ortransformed products can all be handled with productmeta-model independence. Product meta-model inde-pendence facilitates the representation of one or moresets of concepts to represent one or multiple facets.Thus, independence along complexity is also facilitated.Process meta-model independence facilitates indepen-dence along aim and coverage dimensions. Along the aimdimension, different process steps are followed inbuilding constructed or transformed products, respec-tively, and process meta-model independence facilitatesthis. Again, coverage independence is achieved becauseprocess steps of any stage of the life cycle can be han-dled. Similarly, it can be argued that domain andsemantic dimensions are also facilitated by process meta-model independence.The foregoing shows the close linkage between productand process aspects of methods and the need to integratethese two aspects together.

3. The three-layer generic framework suggests that thegeneric model must provide an essential view of amethod. This view should abstract out the commonproperties of meta-models. It should reveal the natureof methods, what they are, what they do, and howthis capability is achieved.

4. Features of methods that are essential but treated as‘add-ons’ today should be integrated in the methodand represented at a suitably high level of abstrac-tion. Thus, it should be possible to express methodconstraints, heuristics, guidelines, etc. in the genericmodel.

223

4 Towards the generic model

In this section we develop our approach to building thegeneric model. We shall consider the implications ofeach property identified in the previous section andidentify the basic concepts of the model and their inter-relationships. These shall be put together in the nextsection to form the generic model itself.

4.1 Class independence

Since class independence calls for meta-model indepen-dence, the holistic structure of the artefact, its compo-nent parts, and inter-relationships between thesecomponents must be expressed in abstractions highenough to instantiate a meta-model. These concepts ofthe generic model, the generic concepts, must not betechnical artefacts, graphs, relationships, objects, frag-ments, chunks and the like. Instead, generic conceptsshould directly capture the notions of product andprocess. We propose to do this through the notion ofproduct and process primitives.

A product primitive is an atomic product unit. It is thesmallest unit that can be operated upon. After a productprimitive has been manipulated, it may be mandatory oroptional to manipulate another related product primi-tive. Correspondingly, a process primitive is the atomicprocess step that can be enacted. After a process prim-itive has been enacted, the enactment of some otherprocess primitive may become mandatory or optional.The generic model should articulate all mandatory andoptional consequences of primitive enactment.

The inseparability of the product and process aspectshas been mentioned above. To handle this we integrateprocess primitives and product primitives together in thenotion of method primitives. A method primitive is thesmallest meaningful process unit that can be enacted. Itspecifies which process primitive manipulates whichproduct primitive to produce what result.

The application engineer uses the set of methodprimitives to construct the development process. Thiscan be done in two ways, by

• Following a process model or• Some ad hoc means

The former is a statement of ‘what is to be donewhen’. Thus, the sequence of method primitives to beenacted is pre-decided and any decision making re-quired to determine what is to be done next is part ofthe process model. In the ad hoc approach, the deci-sion as to what to do next is taken by the applicationengineer explicitly, as development proceeds. Thus, theissues around process modelling are external to thisapproach.

We believe that the ad hoc approach is suited to thedevelopment of our generic model. First, it makes themethod independent of any process model. As discussed

earlier, this facilitates genericity. Second, the enactmentmechanism becomes simpler: since no decision making isto be incorporated in it, only a mechanism for sequentialenactment of selected method primitives is required.

4.2 An essential view

We [12] view a method as an artefact that provides thecapability to construct a product. A method has twoaspects to it, its static and dynamic properties. Staticproperties of interest, from a modelling point of view,are those that describe the holistic structure of theartefact, identify the component parts of the artefact,and bring out the inter-relationships between thesecomponents. The dynamic properties of artefacts arethose that describe the interaction of the artefact with itsenvironment. We believe that there are two kinds ofenvironments relevant to a method (see Fig. 1). Thetechnical environment highlights the technical behaviourof the method: the technical input, technical response,technical features to be supported, etc. This environmentconsists of the product to be developed and the processused to develop it. The usage environment looks to themanner in which the method will be used. It deals withits functional aspects: who uses the method, how is itused, what functionality is needed, etc. The usage envi-ronment is principally determined by two actors, theapplication engineer and the method engineer.

The technical environment suggests that things thatflow across the artefact–environment boundary are

1. Process stimulus2. The product under development3. Product information, for example, product quality

metric values4. Guidance information, what can or must be done

next5. Trace information

It follows that the static aspect of methods mustcontain generic concepts for these. Further, the dynamicaspect is a mechanism that processes the processstimulus and generates (2)–(5) above.

The Usage Environment

Method engineerfunctionality

Application engineer functionality

METHOD

The Technical Environment

ProcessProductGuidanceTracing

The Usage Environment

Method engineerfunctionality

Application engineer functionality

METHOD

The Technical Environment

ProcessProductGuidanceTracing

Fig. 1 The two environments

224

It can be seen that the technical environment is usefulin developing the generic model. It provides knowledgefor defining the static and dynamic aspects of the genericmodel.

The usage environment reveals the functional capa-bility that should be built around a method. Thiscapability should include

1. For the method engineer: method instantiation. Thethree-layer framework suggests that generic modelinstantiation yields the meta-model whose instantia-tion, in turn, yields the method. This is the traditionalapproach to meta-modelling. However, given thegeneric model, the existence of the meta-model makessense provided a number of methods can be instan-tiated from it. When only one method is required,then it would be best if the generic method could beinstantiated to directly yield the method. This latterpossibility arises, as mentioned above, in the domainof real methods.In other words, there should be features to instantiatethe method or the meta-model from the genericmodel. It follows that we need to extend CAMEtechnology to include the former.

2. For the application engineer: capability should beprovided to decide the process stimulus, view theproduct, and obtain all product information. Addi-tionally, support for the development process isneeded: features for guidance in deciding what to donext, tracing, backtracking, etc. Reuse of previousexperience must be catered to.

4.3 Integrating essential features

As mentioned earlier, there are some essential features ofmethods like method constraints, heuristics, guidance,tracing and backtracking, etc. Consider the first two ofthese. First, we require a representation of the constraintand heuristic to be satisfied and we express these asproduct primitives. Second, we need to define appro-priate process primitives for constraint or heuristic sat-isfaction. We find two different ways in which theseprimitives could act:

• Primitives check for constraint and heuristic satisfac-tion.

• Primitives enforce constraints and heuristics.

Constraint and heuristic enforcement is essentially aprocess model: the product is examined and appropriatemethod primitives are enacted to modify it. In accor-dance with the ad hoc approach adopted by us, we rejectthis option. Thus, we shall define process primitives thatcheck constraint and heuristic satisfaction. Just as forother primitives, the application engineer has to decidewhen to enact these.

As discussed earlier, the enactment of certain methodprimitives may imply mandatory or optional checkingfor constraint and heuristic satisfaction. We need an

abstraction that models this successor-predecessor rela-tionship. Similarly, to provide guidance we need thisabstraction to tell us which method primitives must orcan be enacted after which ones. Tracing and back-tracking require that this abstraction be traversed in thereverse direction.

5 The generic model

The generic model consists of two complementary parts,the static and the dynamic parts. The static part dealswith (a) product, process and method primitives, (b)dependencies between method primitives, (c) the rela-tionship between method primitives and a method, and(d) method typology. The dynamic part deals withmethod primitive enactment and the role of dependen-cies in process modelling, process guidance, tracing andbacktracking.

5.1 Generic method statics

In this section we provide an overview of generic statics.Details can be found in [15]. As shown in Fig. 2, we viewa method as a collection of one or more method blocks.This is shown by the M:N relationship between a methodand method block: a method block may belong to one ormore methods and a method may have one or moremethod blocks in it. The specialization hierarchy of amethod shown in Fig. 2 models the complexity and aimdimensions of our classification. In accordance with thecomplexity dimension, a method can be atomic orcompound. An atomic method deals only with thoseproducts that are expressed in exactly one productmodel whereas a compound method is composed ofother simpler methods. It is possible to consider the typeof a method as constructional or transformational. Thisis in accordance with the aim dimension. A construc-tional method is used whenever a new product,expressed in one or more product models, is to beconstructed. In contrast a transformational method isused for transforming a product, expressed in or moreproduct models, into a product of other productmodel(s).

A constructional method that builds products for theER model is atomic since the product is expressed inexactly one model. Similarly, the transformational

ock1,N1,N

#Composedof

Method Method block

ConstructionalCompound Atomic Transformational

has

#o

Method Method bl

ConstructionalCompound Atomic Transformational

Fig. 2 Generic method statics

225

method for converting an ER product into a relationalproduct is atomic since the product to be transformedand the resultant product are both expressed in oneproduct model each. Now consider examples of com-pound methods. The constructional atomic methods toconstruct products in accordance with the object model,functional model, and dynamic model of OMT, composethe constructional compound method of OMT. Similarly,the constructional atomic methods to construct the usecase and object schema comprise the rational compoundconstructional method. Transformational methods mayalso be compound. For example, a method to convert therational product to an object-oriented design product iscompound: the transformation deals with multipleproduct models as input even though there is only oneproduct model on its output side.

When expressed in terms of method blocks, compoundmethods are composed of method blocks that belong toseveral methods whereas all method blocks of an atomicmethod belong to the atomic method only.

The different types of method blocks are shown inFig. 3. Broadly, these are of two kinds, product manip-ulation method blocks do product development andquality checking method blocks that check for andprovide information about the quality of the product.The expectation is that application engineering isa product development–quality checking–productdevelopment cycle.

Figure 3 shows that there are three kinds of productmanipulation method blocks. The first, product life cyclemethod blocks pertain to atomic methods. They can(a) create instances of product primitives, (b) relate theseinstances together, and (c) delete product instances. Thesecond, product mapping method blocks pertain to con-

structional methods and establish a mapping betweeninstances of one component method with those of theother. Thus, for example, an object of an object modelcan be mapped to a data flow of a functional model. Thelast, namely, product transformation method blockspertain to transformational method and cause thetransformation of an instance of one model to those ofthe other. For example, an entity of the ER model couldbe transformed to a relation of the relational model.

Quality checking method blocks when enacted, sup-ply information about the quality of the product. Heu-ristic checking blocks tell the application engineerwhether a given heuristic has been satisfied or notwhereas constraint-checking blocks provide informationon the satisfaction of method constraints.

The structure of a method block is shown in Fig. 4.When viewed structurally, it is possible to classify amethod block as a method primitive, an abstract methodblock, or a complex method block. A method primitive is apair, <objective, approach>. The objective of a methodprimitive tells us what it tries to achieve. The approachtells us the technique that can be used to achieve theobjective of the block. An objective itself is a pair<product primitive, process primitive>. Productprimitives belong to the product model. For eachproduct primitive of the product model, the processprimitives that act upon it are associated with it to yieldthe objectives of the method.

Complex method blocks are composed from simplermethod blocks. For example, the complex methodblock, build aggregate, can be defined to build anaggregate entity from primitive method blocks to createentities and to establish relationships between them.Abstract method blocks are built to generalize methodblocks based on their common properties. For example,two complex method blocks, build aggregate and buildISA hierarchy can be abstracted into a method block,build hierarchies based on the common property thatboth these construct hierarchies, aggregate and ISAhierarchies, respectively.

Method primitives exhibit dependencies amongthemselves. This is shown by the Depends on relationshipin Fig. 4. Dependencies are statements about whichmethod primitives must or can be enacted after a givenmethod primitive is enacted. Clearly, dependencies getcarried over to complex and abstract method blocks andtherefore we can speak of dependencies between methodblocks and not just method primitives.

We will now consider the main concepts of Fig. 4 indetail.

5.1.1 Product primitives

Methods have concentrated on producing products thatare well defined and well formed. As a consequence, amethod focuses on the concepts of the product model,and ensuring that the product satisfies the tenets of themodel. From this perspective, one can find product

Method block

Heuristicchecking

Constraintchecking

Producttransformation

ProductProductlife cycle

Quality checkingProduct manipulation

Method block

Heuristicchecking

Constraintchecking

Producttransformation

Productmapping

Product

Quality checkingProduct manipulation

Fig. 3 Types of method blocks

1,N

1,N Belongsto

Dependson

1,N 1,N

1,N

1,N

Composedof

Method block Productmodel

Processmitive

Productimitive

Method primitive

Abstractmethodblock

Complexmethodblock

1,N

1,N Belongsto

Dependson

1,N 1,N

1,N

1,N

Composedof

Method block Productmodel

Processprimitive

ProductMethod primitive

Abstractmethodblock

Complexmethodblock

primitive

Fig. 4 Structure of a method block

226

primitives by a detailed examination of the productmodel.

We classify product primitives into two, productmanipulation primitives and product quality primitives.The former include concepts and their inter-relation-ships whereas the latter include quality concepts likemethod constraints and heuristics.

In an atomic method there is only one productmodel and the foregoing suffices. However, in com-pound methods, consistency across every pair ofproduct models has, additionally, to be ensured so thatthe compound product is properly composed ofits simpler products. This composition requires prod-uct composition primitives and composition qualityprimitives.

It can be seen that our product primitives are at therequired level of abstraction. They are independent ofany product model or meta-model. A product primitivemay be instantiated to any product model or meta-model concept, an abstract one (graph, an object, anentity) or a real one (a sound clip, a block of a toy).Thus, domain independence is protected. Productprimitives make no assumption about the nature of theproduct that may belong to any stage of the life cycle.Thus, the coverage dimension is promoted. As thecomplexity of the method rises, the set of productprimitives becomes large. While a way of handling thislarge number has to be found, product primitives do notin any way inhibit the construction of methods of anycomplexity or of different aims.

5.1.2 Process and method primitives

A process primitive is the smallest unit of process. Itoperates on a product to cause a change in it therebyproducing a new product. Since constructional andtransformational methods perform different operationson the product, process primitives for these are differentfrom one another. Consider atomic methods first. Con-structional methods need to construct individual prod-uct concepts, inter-relationships between these andprovide information about product quality. Thus, wehave three types of process primitives as follows:

1. Create or delete instances of product primitives.2. Establish inter-relationships between instances of

product primitives.3. Display product information on demand: is the

product complete? Is it consistent? Does it complywith heuristics?

For a transformational method the process primitivesare those that transform from the source to the targetproduct model. Therefore we need essentially one kind ofprocess primitive to transform instances of different kinds

1. An instance of the source product primitive to thetarget product primitive.

2. An instance of the source inter-relationship to thetarget one.

3. An instance of the source quality primitive to thetarget one.

Now consider compound methods. We need processprimitives for mapping. This yields the product com-position class and the composition quality class of pro-cess primitives.

It can be seen that the taxonomy of method blocksshown in Fig. 3 draws heavily from the different kinds ofprocess primitives described above.

5.1.3 Dependencies

As shown in Fig. 4, method primitives are dependentupon one another. We postulate that there are differentways in which method primitives are dependent uponone another. This is captured in the notion of a depen-dency type. For example, in the meta-model of [15] thereare four dependency types called requirements, removal,activate and inactivate, respectively.

A dependency shows up in two forms

1. The enactment of a primitive may call for theenactment of another, or

2. Primitive enactment may call for another primitivenot to be enacted.

We refer to the former as an additive dependencywhereas the latter is a subtractive one. More formally, letus be given a set of dependency types, DT={DT1,DT2,...,DTn}. For an additive dependency we say that amethod primitive O2 is dependent upon a method prim-itive O1 under a dependency type DTi if the enactment ofO1 is a pre-requisite for the enactment of O2 under thatdependency type. As an example, let there be a depen-dency type, trigger. Then O1 fi O2 (O2 depends on O1)says that for O2 to be triggered, the enactment of O1 is apre-requisite. In other words, the enactment of O1 makesO2 available for enactment. For a subtractive dependency,a method primitive O2 is dependent upon a methodprimitive O1 under a dependency type DTi if the enact-ment of O1 results in barring the enactment of O2 underthat dependency type. As an example, let there be adependency type, withdraw. Then O1 fi O2 says thatthe enactment of O1 makes O2 unavailable for enactment.

Two attributes, urgency and necessity, are associatedwith each dependency type. Urgency refers to the time atwhich the dependent method primitive, O2, is to beenacted. If O2 is to be enacted immediately after O1 isenacted then this attribute takes on the value Immediate.If O2 can be enacted any time, immediately or at any

Table 1 Nature of dependencies

Type Urgency Necessity

1 Immediate Must2 Immediate Can3 Deferred Must4 Deferred Can

227

moment, after O1 has been enacted, then urgency takeson the value deferred. Necessity refers to whether or notthe dependent method primitive O2 is necessarily to beenacted after O1 has been enacted. If it is necessary toenact O2, then this attribute takes the value mustotherwise it has the value can.

These attributes provide the basic properties to besatisfied by method primitives related to each otherunder a dependency type. Four cases arise as shown inTable 1.

Dependency type 1 of the table says that the depen-dent method primitive O2 must be enacted immediatelyafter O1 has completed. Dependency type 2 says that O2

can be optionally enacted; and if it is in fact enacted,then this must be done immediately upon the completionof O1. A delayed enactment of O2 is disallowed.Dependency type 3 says that O2 must be enacted afterO1 has been enacted but this may be done at anymoment after the completion of O1. Finally, dependencytype 4 says that O2 may be optionally enacted any timeafter the completion of O1.

Consider the meta-model of [15]. In this meta-modelfour dependency types have been defined, requirementsdependency, its inverse called removal, activate depen-dency, and its inverse called inactivate. Requirementsdependency says that a dependent method primitive O2

must be enacted after O1 but it may be enacted any timeafter O1 is completed. This corresponds to dependencytype 3. Its inverse dependency, removal is of type 1. Itsays that O2 must be immediately removed from the setof method primitives to be enacted after O1 is complete.The activate dependency is of type 4. It says that O2 maybe optionally enacted at any later moment after theenactment of O1 is over. Its inverse, inactivate depen-dency is of type 1. The method primitive O2 must beimmediately inactivated if it was activated by an earlierdependency. It can be seen that in the example meta-model, there is no type 2 dependency.

It can be seen that requirements and activate areadditive dependency types whereas removal and inacti-vate are subtractive ones.

5.1.3.1 The dependency graph It is possible to organizemethod primitives in a directed dependency graph foreach dependency type. Thus, there are as many graphsas the number of dependency types in a method. Themethod primitives in a dependency graph that have noedges entering them are particularly interesting. We referto these as ‘start’ method primitives. Let the set of startmethod primitives under a dependency type DTi bedenoted by Si. We can compute the set of start methodprimitives START, for the entire method by determiningthe common start method primitives across all depen-dency type graphs:

START ¼ \ Si for all i:

Similarly the dependency graph has nodes that have nooutgoing edges. Just as the former are start method

primitives, the latter are stop method primitives. Aftertheir enactment, the development can halt. Just as forstart method primitives, the set of stop method primi-tives is obtained by taking the intersection of the stopmethod primitives of each of the dependency graphs. Letthis set be STOP.

START is interesting because it identifies thosemethod primitives that can be used to start off applica-tion development. Thereafter, the dependency graphscan be followed to select the method primitives to beenacted. The development process can be halted when amethod primitive belonging to STOP has been enacted.

Consider a method with the set of method primitivesO={O1, O2,...,O14}. Let there be two dependency typesDT1 of type 1 and DT2 of type 2. Let the followingdependencies be defined:

DT1 dependencies

O1 ! O2 O1 ! O3 O1 ! O4 O1 ! O5

O6 ! O7 O6 ! O8

O9 ! O10 O9 ! O11 O9 ! O11

:

It can immediately be seen that method primitives withno edge incident on them are O1, O6, O9. Therefore,S1={O1, O6, O9}. The dependency graph is shown inFig. 5.

DT2 dependencies

O1 ! O6 O1 ! O9

O6 ! O13 O6 ! O14:

Again, it can be seen that O1 is the only method primi-tive with no edge incident on it. Therefore, S2={O1}.The dependency graph is shown in Fig. 6 with this kindof dependency being shown by a dotted arrow.

We can put the two graphs of Figs. 5 and 6 togetherto yield the total dependency graph for our method asshown in Fig. 7. The set of start method primitives,START = S1 \ S2 = {O1}. It can also be seenthat STOP = {O2, O3, O4, O5, O7, O8, O10, O11, O12, O13,

O14}.

O1O3

O2

O6O8

O7

O4

O5

O9O10

O11

O12

Fig. 5 The dependency graph under DT1

O1O9

O6 O14

O13

Fig. 6 The dependency graph under DT2

228

It is to be noted that whereas a dependencygraph highlights the dependency structure of methodprimitives, it does not make explicit the additive–sub-tractive or the necessity–urgency properties of a depen-dency type. These are to be determined from the natureof the dependency type itself.

In Sect. 5.2 we will see that dependency graphs can beused to provide support for guidance, tracing, andbacktracking.

5.2 The generic model: the dynamic part

Whereas static aspects of a method deal with the struc-ture of a method, method dynamics deals with thebehaviour of methods. It determines the response of amethod to stimuli provided by application engineers. Inthis stimulus–response view, the development process isa sequence of stimuli selected by the application engineerfor enactment. The algorithmic process, the enactmentalgorithm, that responds to this sequence constitutesmethod dynamics.

The stimuli of interest are

1. Requests for enactment of product manipulationmethod blocks

2. Requests for enactment of product quality checkingmethod blocks

3. Requests for guidance [23] in method block selection4. Requests for trace information5. Backtracking requests

We summarize the stimulus and the correspondingresponse in Table 2.

A stimulus has two components (a) a product partand (b) a method block. It says that the product partmust be manipulated by the method block. The productpart is found in the product under development and isthat piece of the product that requires application pro-grammer attention. The product part must have thesame number and type of arguments as the methodblock. It is only when this match occurs that the methodblock can operate upon the product part.

5.2.1 Product part

We define a product part as that part of the product,which is the focus of attention for further exploration. Itis axiomatically defined as follows

• Every instance of a product primitive is a product part.For example, in the ER model, an attribute, an entityand a relationship type are product primitives. In-stances of these like date_of_birth, employee, andemploys, respectively, are product parts.

• Every set of instances of product primitives partici-pating in a method primitive is a product part. Forexample, the set of entity type instances that arearguments to the method primitive to construct arelationship is a product part.

• Every set of instances of product primitives partici-pating in a complex method block is a product part.For example, the set of entity type instances that arearguments to the complex method block, buildaggregate of Sect. 5.1, is a product part.

• Every set of instances of product primitivesparticipating in an abstract method block is a productpart. Again, the set of instances of entity types partici-pating in build hierarchies of Sect. 5.1 constitutea product part.

• There is a special product part called ‘don’t care’.Every product has it. It says that irrespective of whatthe product is (‘don’t care’ what the product is) someprocess primitives can be used. For example, theprimitive create can be applied to ‘don’t care’ to createnew product parts.

5.2.2 The development process

The development process is a sequence of developmentprocess constructs (DPC). A DPC represents the stim-ulus and consists of a product part and a method block.We define it as an objectified relationship betweenproduct part and method block

DPC ¼ ð½pp�; mcÞ;

where pp is the product part, mc belongs to the set ofmethod blocks, and mc can manipulate pp. The fol-lowing are examples of DPCs

O1O3

O2

O4

O5

O9

O6 O14

O13

O8

O7

O10

O11

O12

Fig. 7 The dependency graph for the method

Table 2 Method dynamics

Stimulus Response

Product manipulation Product after enactmentQuality checking Quality metric valueGuidance seeking Menu of method blocks that

can be enacted nextTracing up to N previousenacted method blocks

Up to Nth previous enactedmethod blocks in reverseorder of their enactment

Backtracking to Mth previouslyenacted method block

Product at backtrack pointEnacted methodblock at backtrack point

229

ð½don’tcare�; < entity; create>Þð½date of birth; employee�; < attribute; entity; couple>Þ:

The first says that the method block to create an entitycan be used on the product part don’t care to create anew, named entity instance whereas the second says thatthe method block to couple an attribute and entity canbe used to couple date_of_birth and employee to eachother. At the end of enactment of this DPC, employeehas an attribute, date_of_birth.

Our development process deals with instances ofmethod blocks. These must be in accordance with thedependency graphs of a method. Initially, the applica-tion engineer selects an instance of a method block fromSTART (see Sect. 5.1.3.1). The enactment algorithmenacts it and the product is accordingly modified. Thenext method block instance that can or must be enactedis obtained by following the dependency links in thevarious graphs. Since the type of the enacted methodblock is known, the dependency graphs yield the set ofmethod block types whose instances can now be enacted.In this way, it can be seen that any development processis a route among the dependency graphs and that theonly processes that can be built are the ones definedunder the dependency graphs of the method.

Let us denote the jth instance of method block Oi byoi,j and show the progress of a typical developmentprocess. Let the development process start by enactmentof o1,1. Now, the dependency graph of Fig. 5 suggeststhat instances of O2–O5 could be enacted under DT1

whereas, by Fig. 6, O6 and O9 could be enacted underDT2. Let the application engineer enact o6,1. FollowingFig. 5, it is now possible to enact instances of O7 and O8

under DT1 as well as O13 and O14 under DT2. Let theapplication engineer select o7,1 for enactment. Thedependency graph now suggests nothing. The applica-tion engineer may choose to terminate the process at thispoint or may start with another instance of O1.

Assuming that the process is terminated, we get thefollowing process

o1;1o6;1o7;1

:

Equivalently, the process (see Fig. 8) is the route takenin the dependency graph of Fig. 7.

Supporting the development process To support thedevelopment process outlined above, we develop anenactment algorithm. This algorithm must providecapability to handle

• Product manipulation primitives• Quality checking primitives• Guidance in selecting the next manipulation or qualitychecking primitive to be enacted

• Tracing and backtracking

We first lay out our policy for guidance, backtracking,traceability, and quality checking and then present thefull enactment algorithm.

5.2.3 Providing guidance

As is well known, there are two approaches to guidance,the passive and the active. We adopt the formerapproach here. This approach says that (a) uponenactment of a method block the set of method blocksthat can be enacted next is calculated, (b) the applicationengineer is provided this set to select the next methodblock to be enacted.

We develop three kinds of guidance here

• Basic guidance• Operational guidance• Semantic guidance

The set of dependency graphs of a method defines theentire basic guidance capability available in the genericmodel. Since progression from one method blockinstance to the next must follow the directed edges ofthese graphs, the enactment of a method block shouldinitiate the determination of its successor nodes. Thus,the method blocks that can be enacted next can bedetermined and presented to the application engineer.Operational guidance is built on top of basic guidance(see Fig. 9) and considers operational behaviour patternsof application engineers. These patterns form the basis ofpartitioning the set of method blocks determined by basicguidance into sets specific to a behaviour pattern. Thepartitions can be presented to application engineers.

Semantic guidance is also built on top of basicguidance (Fig. 9). However, the basis of classification isnow different from that of operational guidance. We are

o 7,1

o 6,1

o 1,1

Fig. 8 A dependency graph route

Basic Guidance

Semantic GuidanceOperational Guidance

Basic Guidance

Semantic GuidanceOperational Guidance

Fig. 9 Guidance levels

230

now not looking for operational behaviour patterns butfor the intention that the application engineer has inmind. The set of method blocks obtained through basicguidance are partitioned according to the intention thatthey help in fulfilling. Application engineers are thenpresented with only those intentional sets that are rele-vant to the task at hand.

We now consider each kind of guidance in detail.

5.2.3.1 Basic guidance level Consider that the develop-ment process is just starting out. The application engi-neer may want to know the objectives that can beenacted to start off. The guidance mechanism mustdisplay the set START to enable selection of an objec-tive to be enacted. Once an objective has been selected,guidance is provided by following the dependencygraphs. Given a node that has been enacted, the graphsare traversed along the direction of the edges. The suc-cessor nodes (those that are one edge removed in thedirection of traversal) of the given node for each graphare determined, the additive–subtractive nature ofdependency types is taken into account and the set ofobjectives available for enactment is calculated. This isthe menu from which the next objective to be enactedcan be selected.

Notice that we do not take into account theurgency and necessity properties of dependencies. Thisis because our intention is to present a menu thatidentifies what can be done next rather than when itmust be done (urgency) or whether it must or can bedone (necessity).

We formalize the foregoing now. Let there be a set Gi,called the choice set, which contains the set of methodblocks that can be enacted next after method block in-stance di has been enacted. Under the passive guidanceapproach, Gi is the set of method blocks that is to beprovided to the application engineer by the guidancemechanism. Initially G0 = START. When di is enactedthen the guidance mechanism computes Gi as follows:

1. For each graph instance in which di occurs, find thecorresponding dependency graph type

2. For each such graph type

For each directed edge going out from the method blocktype corresponding to di

Find the successor node, N.If dependency is additive then Gi=Gi [ N but if it issubtractive then

Gi ¼ Gi � N :

It can be seen that as each method block instance isenacted, Gi is modified to reflect the new method blocksthat can possibly be selected.

Consider providing guidance for the process ofFig. 8. At the start, the guidance mechanism presents O1

as the only objective from which development process isto begin. After enactment of o1,1 the guidance mecha-

nism determines that its type is O1. The graphs DT1 andDT2 are traversed from O1. The former yields the set{O2, O3 O4, O5} and the latter yields {O6, O9}. Thus, theguidance mechanism suggests the set {O2, O3 O4, O5, O6,

O9}. The application engineer now selects the objectiveO6 and proceeds to enact its instance o6,1. The guidancemechanism determines the sets {O7, O8} and {O13, O14}.Additionally, taking into account the self-loop on O1,the set presented is {O2, O3 O4, O5, O6, O7, O8, O9, O13,

O14}. The developer selects an instance o7,1 of O7 forenactment. This enactment leads to no further additionin the choice set and O7 is the terminating node in thegraph. Application development may now stop, if theproduct meets application needs.

5.2.3.2 Operational guidance level The choice set Gcontains all possible method blocks that can be enactedafter the enactment of a method block instance. Fromthe previous section it can be surmised that that thechoice set Gi grows very rapidly and can becomeextremely large. It has been shown in [12] that this largesize makes it very difficult for the application engineer toselect a meaningful method block.

To obviate this difficulty, operational guidanceexploits typical patterns of an application engineer’soperational behaviour. In computer science such oper-ational behaviour patterns abound. For example, inoperating systems, page replacement algorithms useLRU LFU patterns to determine the page to be dis-carded. Similarly, in programming, it is assumed thatflow of control is sequential. Computers are organized toincrement the program counter by unity under theassumption that the next sequential instruction shall beexecuted. In a similar way, it is possible to postulate thelocalization pattern: the application engineer may like toconcentrate on the most recently manipulated productpart. Localization is so named because attention is onthe development of a small, localized part of the prod-uct.

Let the most recently enacted DPC be d. Two casesarise as follows:

1. d is unary. Its enactment may result in either aproduct part ‘p’ or a ‘don’t care’ being produced.Localization says that the next DPC may be eitheranother unary DPC operating on p or ‘don’t care’, oran n-ary method block having p as one of its argu-ments.

2. If d is n-ary then the next DPC may have any one ormore arguments of d as its arguments, in addition to‘don’t care’.

Case (1) continues to maintain focus on the productsof d whereas case (2) provides the possibility of a gradualmovement away from earlier products.

Consider operational guidance in a small part of adevelopment process as follows. An entity, employee, iscreated by a unaryDPC, ([don’t care],<entity, create>).The operational guidance mechanism computes the

231

choice sets for, among other product parts, ‘don’t care’and ‘employee’. The application engineer chooses to fo-cus on employee, looks at the employee specific choice setand decides to define an attribute for employee. A binaryDPC is used to define ‘name’ as an attribute of ‘employ-ee’, ([name, employee],<entity, attribute, couple>). Thechoice set is computed for all part parts including forname and employee. By (2) above, it is possible to chooseeither employee or name as the next product part to bedeveloped. Focusing on name causes a shift away fromemployee. Notice how attentions shift from ‘don’t care’initially, to ‘employee and then to ‘name’.

Of course, it is possible that an altogether differentproduct part becomes interesting suddenly, calling for aclean break from the localization pattern. For example,after making ‘name’ to be an attribute of ‘employee’, theapplication engineer may want to create a new entitytype ‘department’. This is supported by the operationalguidance mechanism by the computation of the choiceset specific to ‘don’t care’.

Let us now consider the guidance mechanism tosupport operational guidance. Basically, the mechanismneeds to determine the method blocks that are applica-ble to each product part comprising the product. Recallthat ‘don’t care’ is a product part of every product. Thelocalization pattern implies that the guidance mecha-nism must present only those method blocks that arerelevant to the localized task at hand. Thus, the choiceset Gi is to be partitioned product part wise. Givenproduct parts P1, P2,...,Pn, to obtain their localizedchoice sets Gi1, Gi2,...,Gin, respectively, the followingaction is taken

1. For unary di: Determine the product part producedby di. This can be either ‘don’t care’ or an instance ofa product type, Pj. The application engineer choosesthe product part to be developed further. The choiceset corresponding to this is presented.

2. For n-ary di: Determine the product parts operatedupon, say P1, P2,...,Pn. Then any of Gi1, Gi2,...,Gin

may need to be presented.

Once the partitioned choice sets are available, it ispossible for the application engineer to select the prod-uct part of interest through any operational pattern(most recently manipulated, most frequently manipu-lated) and ask for the appropriate partition.

Method dynamics can now be visualized as acycle shown in Fig. 10. At each turn of this cycle, theenactment mechanism creates localized choice sets foruse by the operational guidance mechanism.

5.2.3.3 Semantic guidance Whereas operational guid-ance makes assumptions about the operational behav-iour of application engineers, semantic guidance takesinto account the developmental aim that the applicationengineer wants to satisfy. Only that set of method blockswhich helps in achieving this aim is presented to theapplication engineer. Thus, if the aim of the applicationengineer is to assess the quality of the product, then onlythe method blocks that help in quality assessment arepresented. On the other hand, if the aim is to develop theproduct further then method blocks for product devel-opment are presented.

Semantic guidance requires a classification of the setof method block types according to the aim that eachclass fulfils. Let us be given developmental aims A1,A2,...,An. For each Ai we create a class of method blockssuch that each method block fulfils the aim Ai:

Ai ¼ fDjjDj fulfilsAig:

For example, a method may have the two basic aims(among others), enforce method constraints and checkheuristics. Then, two classes of method block typesare produced, the former containing method blocktypes that enforce method constraints and the lattercontaining method block types that check for heuristicsatisfaction.

Developmental aims may be aggregates of simplerdevelopmental aims. As before, there is a class ofmethod block types for the aggregate aim and it consistsof all those method block types that fulfil the aggregateaim. The aggregate class is the union of the classes of thesimpler developmental aims. Formally, if AA is anaggregate of simpler aims A1, A2,...,An then:

AA ¼ A1 [ A2 [ � � � [ An:

In case an aim is an aggregate of others then thecycle corresponding to the aggregate aim can bedecomposed into a bundle of cycles of lower aims. Thisallows the guidance mechanism to operate in a hierar-chical manner: the developmental aims of the applica-tion engineer can be ascertained starting from broad,fuzzy, aggregate aims and going down to increasinglyprecise aims. Once the most precise aim has beenobtained, the guidance mechanism presents the choiceset corresponding to this aim. Let there be an aim,enforce product quality that is an aggregate of enforcemethod constraints and check heuristics. Then themethod block types of both these have the aggregateaim of enforcing product quality. The set of methodblocks for enforce product quality is the union of thesets of these two.

Method dynamics can now be visualized as multiplealternative cycles as shown in Fig. 11. Each cycle cor-responds to a developmental aim of the method. Afterthe enactment of a method block the application engi-neer has the choice of following one of several devel-opmental aims. The various choice sets are computedupon method block instance enactment. Thereafter,

Partitioned Choice Sets

Enact DecisionComputePartitioned Choice Sets

Fig. 10 The enactment mechanism

232

depending upon the developmental aim, the appropriatechoice set is presented to the application engineer.

5.2.4 Backtracking

Backtracking is the ability to go back to an earlierprocess state. This can happen for two reasons

1. There is dissatisfaction with the product. However,the product was good up to a DPC enacted earlier.Therefore, the product and process has to be restoredto this state and a new development route is to befollowed. We refer to this as backtracking in thejettison mode.

2. There is no real dissatisfaction with the product.However, the application engineer wants to exploreanother development option starting from someearlier state. We refer to this as exploratory modebacktracking.

In terms of dependency graphs, backtracking can beunderstood to be the inverse of guidance: whereasguidance deals with ‘next nodes’, backtracking is con-cerned with ‘previous nodes’.

Let the most recently enacted DPC be DPCn =([ppn], mbn). Let it be desired to backtrack to DPCk =([ppk], mbk). Then, the enactment mechanism mustundoDPC starting from DPCn till DPCk is reached. Themechanism to handle this is as follows:

Step 1: If backtracking is in the exploratory mode thensave the current product, process, and alldependency graph data

Step 2: Repeat till DPCk is reached

Step 2(a): Restore to [ppn�1] by enacting the inverse ofmbn.

Step 2(b): Move back in dependency graphs to thepredecessor node mbn�1 of mbn.

Step 2(c): Discard the node DPCn from the process andestablish DPCn�1 as the last process nodeenacted

As an example of backtracking consider the devel-opment process of Fig. 8. Let backtracking occur inexploratory mode after o7,1 has been enacted. First thecurrent product, dependency graph data, and the pro-cess is saved. Now, let I(mbn) refer to the inverse ofmethod block mbn. Then, as per step 2(a) above, the

DPC ([ppn], I(o7,1)) is enacted. This restores the productto [ppn�1].

5.2.5 Providing traceability

Traceability uncovers the process history that led to theenactment of a DPC. Equivalently, it tells the applica-tion engineer the evolution history of the product, thatis, how did the product evolve to reach its current form.Traceability is similar to backtracking in that interest isin previous nodes of dependency graphs. However,traceability is different from backtracking in its purpose.When backtracking, the aim is to restore developmentstatus to a previous product and process state and toproceed with the development process from this restoredpoint. On the other hand, when tracing, interest is inknowing previous development steps. Thus, traceabilityprovides a re-run of the DPCs that were enacted in thepast. No restoring of the product or process to an earlierdevelopment status is required.

The generic model provides traceability in twomodes, burst or decrement mode. Decrement modetraceability assumes that the application engineer wantsto examine evolution step by step as it occurred. In burstmode traceability, the application engineer wants toexamine evolution from some pth earlier DPC.

To provide traceability, the complete process is savedas for backtracking. However, it is not required to savedependency graph instances. Let the most recently en-acted DPC be DPCn. In decrement mode, DPCn�1 isdisplayed and position established at it for supportingfurther traceability. Further invocation of decrementmode traceability causes DPCn�2 to be displayed. Inburst mode, DPCn�1, DPCn�2,..., etc. are displayed untilthe pth earlier DPC is reached.

In our example process of Fig. 8, decrement modetraceability will cause o6,1 to be displayed. If asked foragain then o1,1 shall be displayed. If instead of decre-ment mode traceability is used to trace back two steps,then first o6,1 and then o1,1 shall be displayed.

5.2.6 Quality checking

In Sect. 5.2 we had postulated quality checking methodblocks. When these are enacted the application engineeris provided information about product quality. Thebasics of our quality checking approach are found in therepresentation theory of measurement of softwareengineering. According to this theory, entities havequality attributes that are measured through metrics.For example, a software product is an entity. It hasattributes size and complexity. The former is measuredusing the lines of code metric. Similarly, the latter ismeasured using the order O metric.

We extend this to include IS products andtheir quality attributes. Consider for example thegeneralization–specialization hierarchy. It has an attri-bute called depth that can have an associated metric

Compute semantic choice sets

Compute semantic choice sets

Semantic choice sets

Enact DPC for A1

Enact DPC for A2

Compute semantic choice sets

Enact DPC for A2

Fig 11 The dependency cycle

233

with it. The depth of the hierarchy is controlled though adepth heuristic that, in the case of OMT, suggests that itbe restricted to about five levels deep. A number ofmethod constraints are specified in methods. There arefour [6] such: completeness, conformity, fidelity andconsistency. These are imposed on IS products and canbe treated as attributes of these products. Again, weassociate metrics with this.

The association of metrics with IS products makes itpossible for us [24] to compute the metric value andreturn to the application an indication of whether theproduct parts of interest satisfy or do not satisfy theheuristic or constraint attributes. For this purpose wedefine quality method primitives as indicated earlier. Asexamples of these consider

\entity; check completeness >\ISAhierarchy; check depth heuristic > :

These primitives participate in a dependency structurewith others. For example, since the creation of an entity,employee, calls for its completeness check, we have

\entity; create >!\entity; check completeness > :

This is a type 3 dependency in terms of Table 1: it mustbe checked that a created entity is complete but thischeck can be deferred till an appropriate moment.

Since the enactment of a quality method primitivegives information about whether the quality of theproduct part is satisfactory or not, it is possible for theapplication engineer to decide which method primitiveto enact next.

5.2.7 The enactment algorithm

At the heart of method dynamics is the enactmentalgorithm that embodies in it support for processenactment, guidance, backtracking and traceability.Thus, it provides all the features that we have discussedso far in this section.

The algorithm assumes that application engineershave a number of different courses of action availableand select one of these. These courses of action are rep-resented in the algorithm as the set, possibility. Possi-bility contains in it the set of DPCs that are available forenactment. Under the passive guidance scheme outlinedearlier, this set may be displayed depending upon theguidance mode: basic, operational, semantic or hybrid.The application engineer makes a selection from Possi-bility and the selected DPC is enacted. This leads to amodification of Possibility. In other words, given possi-bilityi�1, a DPC is enacted and this results in possibilityi.

With each enacted DPC, three cases arise. Theapplication engineer

1. Makes a fresh selection from possibilityi2. Desires to backtrack in either exploratory or jettison

mode, or3. Wants to trace the development activity so far

In order to handle (2) and (3) above, we introducespecial method blocks as follows:

1. <‘don’t care’, jback> for backtracking in the jetti-son mode

2. <‘don’t care’, eback> for backtracking in theexploratory mode

3. <‘don’t care’, trace(P)> for tracing. P specifies thesize of the burst mode trace. By default, trace isdecrement mode only

Define possibility, Pi to be the set of all DPCs that areavailable for selection at a given moment and Si is theselected DPC from among these for enactment. Pi+1 iscomputed by considering the instances of the depen-dency graphs and by determining the contributionsmade by the dependencies:

1. The additive–subtractive nature of dependencies tellsus the DPCs that become eligible or ineligible forenactment. This suggests two sets ADD(Si) andSUB(Si). The former identifies all the dependentDPCs that become available on account of additivedependencies, due to enactment Si. The latter iden-tifies the dependent DPCs that must be madeunavailable on account of subtractive dependenciesdue to Si.

2. The necessity property of dependencies tells us whe-ther additive DPCs are to be mandatory or optionallyenacted. This suggests that we partition ADD(Si) intotwo sets MAND(Si) and OPT(Si) such that

ADDðSiÞ ¼MANDðSiÞ [OPTðSiÞ:

3. The urgency property tells us the time of enactmentof a dependent DPC. Thus, it does not make a con-tribution to Pi.

Let there be two sets, READY(Si) and PEN-DING(Si). The former computes the set of optionalDPCs after the enactment of Si and the latter, the set ofmandatory ones. Then

READYðSiÞ ¼ READYðSi�1Þ [OPTðSiÞ � SUBðSiÞPENDINGðSiÞ¼ PENDINGðSi�1Þ [MANDðSiÞ � SUBðSiÞ:

Putting together the various components, possibility,Pi+1 is defined as

Piþ1 ¼ READYðSiÞ [ PENDINGðSiÞ:

Note that when the development process starts out thenthe initial Pi = P0 = START. We start with a nullproduct. Consequently, the only product part availableis ‘don’t care’.

It can be seen that the enactment algorithm supportsthe dynamic properties of our generic model. All threekinds of guidance, namely, basic, operational, semantic,and hybrid are supported by the foregoing algorithm asfollows:

234

• The set Pi contains in it the set of all DPCs that can beenacted after Si. This corresponds to the basic guid-ance level introduced earlier.

• By partitioning Pi part-wise into APSETs we are ableto provide support for operational guidance. It theapplication engineer determines the product part ofinterest then it is possible to display all applicableDPCs.

• The partitioning of Pi aim-wise makes available the setof DPCs that meet a given aim. The partitioning ofeach such set into AIMAPSETs provides support forhybrid guidance.

Backtracking is supported naturally due to specificmethod blocks for its different forms. Since these oper-ate on the product part ‘don’t care’, backtracking can beinvoked anytime in the development process. Supportfor backtracking is described in Sect. 5.2.5.

Traceability is supported through the introduction ofspecific method blocks that operate on ‘don’t care’.Traceability can be invoked any time in the developmentprocess and the support needed for this is described inSect. 5.2.6.

6 Conclusion

We have shown in [16] that it is possible to use thegeneric model to engineer meta-models. Additionally wehave shown in [25] that it can be used for engineering‘application-centric’ methods as well. For reasons ofspace, we shall deal with the meta-model and methodengineering mechanisms associated with the genericmodel in a separate paper.

A prototype generic-CAME tool for the generic modelhas been implemented by a group of students. A morerobust implementation is currently ongoing. This generic-CAME tool shall provide an integrated environment formeta-model and method engineering. We intend to use itto do engineering of (a) meta-models like GOPRR (b)methods for real businesses as well as (c) applications inartificial intelligence like playing games with blocks.

Our work with the generic model has so far beencentred around ‘hard’ methods. We have been con-cerned with the technical issue of building products andhave not considered ‘soft’ methods.

To our knowledge, the only other work that uses theterm ‘generic model’ in the context of methods is [26]. Itdevelops an assembly of ways of doing situationalmethod engineering and a selection from this assembly is

to be made. Genericity exists in the sense that the col-lection of methods forming the assembly can all be usedto carry out the same common intention, that of doingsituational method engineering. Thus, the intention ofthe assembly is shared by or is typical of a whole groupof methods. This meets the criterion for it to be generic.

It is to be seen that our generic model is not anassembly of methods. It is a system of concepts andinter-relationships, it is a model. It is not possible toselect a method in our case. Rather meta-models andmethods can be engineered from it. In the assemblyapproach, the method has already been engineered andis available, as part of the assembly, for selection.

Appendix 1

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

The static part of the generic model is instantiated toyield meta-model statics, instances of method blocks andthe set of dependencies between these. In our meta-model, method blocks are instantiated to purposes,product primitives to conceptual structures and fixedstructures, and process primitives to operations whichcan be of two types, product manipulation and qualitychecking. There are four dependency types, require-ments, removal, activate and inactivate. The set ofdependencies is instantiated with dependencies betweenpurposes of different types.

Through the click and drag features of the generic-CAME tool, the instantiations of product primitives withconceptual and fixed structures shown in Figs. 12 and 13are arrived at. As shown in Fig. 12, conceptual structurescan be partitioned into two clusters. The first cluster

conceptual structure

definitional constructional Linkconstraintsimple

complex

collection of concepts

##

Fig. 12 The conceptualstructure

Fixed Structure

Method Constraint

Heuristic Design Factor

Environmental Factor

Fig. 13 The fixed structure

235

classifies them as either simple or complex. The secondcluster partitions conceptual structures into disjointclasses of structures called constraint, definitional, con-structional, link and collection of concepts, respectively.

Figure 13 shows the product primitive instances thatidentify the criteria that must be met by a good qualityproduct. There are four kinds of fixed structures asshown. Again, these are created by the drag and dropfacilities of the generic-CAME tool.

Operations identify the instances of process primitivesof the generic model that operate upon conceptual andfixed structures to provide product manipulation andquality checking capability to application engineers.Again, the generic-CAME tool is used to produceFig. 14.

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

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

Purpose ¼\structure; operation > :

Thus, the following are purposes

\simple constructional structure; create >

\simple constructional structure; method constraint;

method constraint enforcement > : ð30Þ

The definition of the set of meaningful purposes of themeta-model is supported by the generic-CAME toolwhich generates the cross product of structure andoperation. This cross product is presented and themeaningful purposes are then selected. The complete setof purposes can be found in [25].

Finally, the set of dependencies of different types areinstantiated and the generic-CAME tool keeps aninternal representation of the dependency graphs.

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

Appendix 2: Glossary

References

1. Hornby AS (2000) Oxford advanced learner’s dictionary ofcurrent English. Oxford University press, Oxford

2. Brinkkemper S, Saeki M, Harmsen F (1999) Meta-modellingbased assembly techniques for situational method engineering.Inform Syst 24(3):209–228

3. Plihon V, Rolland C (1995) Modelling ways-of-working. In:Proceedings of CAiSE’95, Springer, Berlin Heidelberg New York

4. Ralyte J, Rolland C (2001) An assembly process model formethod engineering, In: Proceedings of CAiSE’01, Springer,Berlin Heidelberg New York

5. Rolland C, Prakash N, Benjamen A (1999) A multi-model viewof process modelling. REJ 4(4):169–187

6. Prakash N (1994) A process view of methodologies, advancedinformation systems engineering. In: Wijers, Brinkkemper,Wasserman (eds) LNCS 811, Springer, Berlin Heidelberg NewYork, pp 339–352

7. Smolander K (1991) OPRR: a model for modeling systemsdevelopment methods, next generation of CASE tools. IOSPress, Amsterdam

8. Souveyet C (1991) Validation des Specifications Conceptuellesd’un Systeme d’information, Ph.D. thesis, University of Paris

9. Brinkkemper S (1990) Formalisation of information systemsmodelling, Ph.D. thesis, University of Nijmegen, Thesis Pub-lishers, Amsterdam

operation

in tegration basic life cycle re lational fixed structu reenfo rcem en t

m ethod constra in ten fo rcem en t

heu risticen forcem en t

design factoren fo rcem ent

env ironm entalfacto ren forcem en t

Fig. 14 The operation

Product primitive The smallest unit that can be operatedupon in a method

Process primitive An atomic action that can be enactedMethod primitive The smallest meaningful process unit of

a method that can be enacted. It is apair <product primitive, processprimitive>

Complex method block A composition of simpler methodblocks

Abstract method block A generalization of a method blockMethod block It can be either a method primitive, a

complex or an abstract method blockProduct part A part of a product that is the focus of

further developmentDPC The product part together with the

method block that can operate uponit. It is the smallest unit of thedevelopment process

Development process The sequence of DPCs enacted to buildthe product

236

10. Wijers GM (1991) Modelling support in information systemsdevelopment, Ph.D. thesis, University of Delft, Thesis Pub-lishers, Amsterdam

11. Grosz G et al (1997) Modelling and engineering the require-ments engineering process: an overview of the NATURE ap-proach. REJ 2(3):115–131

12. Prakash N (1999) On method statics and dynamics. InformSyst J 24(8):613–637

13. Jarke M et al (1994) Experience based method evaluation andimprovement: a process modelling approach. In: Verrijn-Stu-art, Olle (eds) Methods and associated tools for the informationsystems life cycle, Elsevier, Amsterdam, pp 1–28

14. Harmsen F et al (1994) Situational method engineering forinformation system project approaches. In: Verrijn-Stuart, Olle(eds) Methods and associated tools for the information systemslife cycle, Elsevier, Amsterdam, pp 169–194

15. Prakash N (1997) Towards a formal definition of methods. REJ2(1):23–50

16. Prakash N, Bhatia MPS (2002) Generic models for engineeringmethods of diverse domains, advanced information systemsengineering (CAiSE 02). In: Pidduck, Mylopoulos, Woo, Ozsu(eds), LNCS 2348:612–625

17. Checkland OP, Scholes J (1990) Soft systems methodology inaction. Wiley, Chichester

18. Atkinson CJ (1997) Soft information systems and technologiesmethodology (SISTeM): a case study on developing the elec-tronic patient record. REJ 1–22

19. Blum BI (1994) A taxonomy of software development methods.CACM, pp 82–94

20. Davis AM et al (1988) A strategy for comparing alternativesoftware development life cycle models. IEEETSE, pp 1453–1461

21. Lyttinen K (1987) A taxonomic perspective of informationsystems development: theoretical constructs and recommenda-tions. In: Boland, Herschheim (eds) Critical issues in informa-tion systems research, Wiley, New York, pp 3–41

22. Krogstie J, Solvberg A (1996) A classification of methodolog-ical framework for computerized information systems supportin organizations. In: Brinkkemper, Lyytinen, Welke (eds)Method engineering: principles of method construction andtool support, Chapman & Hall, London, pp 278–295

23. Rolland C, Souveyet C, Ben Achour C (1998) Guiding goalmodelling and scenarios. IEEETSE 24(12):1055–1071

24. Prakash N, Sibal R (1999) Modelling method heuristics forbetter quality products, advanced information systems engi-neering. In: Jarke M, Oberweis A, (eds) LNCS 1626, Springer,Berlin Heidelberg New York, pp 429–433

25. Prakash N, Bhatia MPS (2003) Developing application centricmethods. In: Eder, Missikoff (eds) CAiSE Forum, pp 225–228

26. Ralyte J et al (2003) Towards a generic model for situationalmethod engineering, advanced information systems engineer-ing. In: Eder J, Missikoff M (eds) CAiSE 2003, LNCS 2681,Springer, Berlin Heidelberg New York, pp 95–110

237