Extending Methods to Express Change Requirements

© Copyright EMSISE’03

Extending Methods to Express Change Requirements Anne Etien, Rébecca Deneckère, Camille Salinesi Centre de Recherche en Informatique Université Paris 1 – Panthéon Sorbonne 90, rue de Tolbiac 75013 Paris – France {aetien, denecker, camille}@univ-paris1.fr Abstract. A large portion of Information System engineering efforts involves their evolution. As for IS development from scratch, dealing with requirements in an appropriate way is a crucial aspect of IS evolution. There is however very few Requirements Engineering methods that propose explicit concepts to handle the required changes. We developed a number of concepts to express change requirement in an industrial setting. These concepts were generalized and their use experienced in the context of several IS engineering methods. This paper proposes a systematic method engineering approach to introduce these concepts in any IS engineering method based on a meta-model. This SME approach is extension-based. It allows to change an origin method in order to obtain an extended method that meets the requirements. The changes between these two methods are expressed with the same concepts than for the IS it-self.

1

Introduction

It is well known that methods are not always well suited to the user needs and that it is necessary to add/change the concepts and/or relationships between them [Lyytinen87]. Situational Method Engineering (SME) aims at project-specific method construction. The need for a better productivity of Information System (IS) engineering teams, as well as a better quality of products motivates the development of solutions to adapt methods to the project situation at hand [Seaki93], [Harmsen97], [Rolland98], [Ralyté99b]. SME favours the construction of modular methods that can be modified and augmented to meet the requirements of given situations [Harmsen94], [Slooten93]. There are several approaches to adapt methods: by instantiation of generic method components [Rolland93,94b,96], by assembly of different method chunks [Ralyté01], by integration of overlapping fragments [Ralyté99a] or by extension [Deneckère01]. This last approach aims at modifying an existing method (called the origin method) by on-the-fly addition or modification of concepts in its meta-model (to obtain an extended method). There is a number of similarities between adapting methods by extension and what is done in Requirements Engineering to deal with the particular issue of IS evolution. Indeed, when an IS evolves, it moves from an initial situation to a future one. Traditionally, these situations are respectively represented by an As-Is model and a To-Be model [Jackson95]. The problem of eliciting requirements in the context of change can be seen as the one of adapting the As-Is model to reach the To-Be model [Rolland03]. We believe that the same approach can be used when working with methods. However, instead of models adaptation, the issue is the one of adapting meta-models. Therefore, method adaptation deals with changing an “As-Is” meta-model into a “To-Be” meta-model. Our proposal is thus to use the language we proposed to express change requirements for IS adaptation at the meta-model level, and therefore to describe the requirements for method adaptation. The adaptation consists in extending methods with our concepts for the expression of change requirements. Our experience with several industrial projects [Salinesi02b], [Rolland03], showed us that practitioners often find inefficient to completely describe As-Is and To-Be models then to compare them. Instead of this complex way of working, they prefer to express the required changes under the form of gaps with the current situation. Therefore, we believe requirements elicitation for IS evolution shall be driven by gaps. Gaps identify what has to be changed/adapted to the new situation. In order to formalise the definition of change requirements with gaps, we proposed to use operators that express model transformations. These operators have been generalised so that they can be used with any metamodel [Rolland03]. This approach has been experienced with several meta-models [Salinesi02b][Salinesi02a][Rolland03]. We also found that it is more exhaustive than ad hoc proposals such as the typologies of gap operators defined by [Banerjee87] and by [Casati96].

1

© Copyright EMSISE’03

This paper proposes a method engineering approach which aims at improving any method to allow the expression of change requirements. The approach relies on a method extension process. This process adapts our typology of gap operators to the specificities of the method to extend. It then introduces the adapted typology into the method’s meta-model. The process also proposes a number of quality criteria to evaluate the method with respect to the change requirements concern. The next section presents our approach for eliciting change requirements in the IS Engineering domain (i.e. at the model level), and adapts it to the Method Engineering domain (i.e. at the meta model level). The principles of the approach we propose for extending any method with change requirements concepts is outlined in section 3. The method extension process is detailed in section 4 and illustrated with an example in section 5.

2

Change requirements elicitation approach

According to [Rolland03] change requirements are expressed as gaps between the As-Is and the To-Be situations. On the one hand, gaps are specified by instantiating gap operators. On the other hand, the As-Is and To-Be situations are respectively specified with models that instantiate a unique metamodel. The issue is to find out which gap operators should be used with given meta-models. Rather than defining from scratch another collection of gap operators for each new meta-model, we proposed a generic typology of gap operators that can be systematically adapted to any specific meta-model.

2.1

Presentation of the approach

As shown in figure 1, specific meta-models are re-defined using a generic meta-model. Besides, our generic gap typology is instantiated by specific gap typologies. The purpose of the former instantiation is to identify the key elements and structures of the specific meta-models (e.g. UML, OMT etc.). The generic gap operators defined in the generic typology apply to the concepts of the generic metamodel. The production of specific gap typologies is made systematic by combining the generic gap typology and the specific meta-model expressed by instantiation of the generic meta-model. At the model level, the current situation and the future situation are respectively defined by the As-Is and the To-Be models. These are instances of the specific meta-model. The gaps between the As-Is and the To-Be are represented in the figure by ∆. They are instances of operators contained in the specific typology. Generic Meta-model level

Generic Meta-model

Applied on elements of

Instance of

Specific Meta-model level

Meta-model Instance of

Model level

As-Is Model (schema)

Generic Typology Instance of

Applied on elements of

Instance of

Δ

Typology of operators Instance of

Δ Δ

To-Be model (schema)

Figure 1: Framework for the change requirement elicitation approach

Examples of meta-models at the specific level are Entity-Relationship, Use Case Diagrams (UCD), etc. Let us take the example of an IS for which requirements have been elicited using Use Case Diagrams. If the IS has to evolve, then the elicitation of the change requirements shall be driven by

2

© Copyright EMSISE’03

gaps. The typology of gap operators that can be used for this purpose will for instance include “Add a Use Case”, “Change the Origin of a Use Case-Actor Association”, “Merge Actors”, etc. The complete typology of Use Case gap operators to be used can be systematically designed by instantiating the generic gap typology. The remainder of this section presents how to achieve this.

2.2

The generic meta-model and generic typology of gap operators

The generic meta-model aims at making explicit the elements and structures of any meta-model. According to this generic meta-model, any given meta-model is composed of a collection of objects that are either elements or properties of elements. As shown in Figure 2, Elements are classified into two bundles. First, a distinction between Simple Elements and Compound Elements is made. Second, elements can be classified into Link and Not Link. Compound Elements can be decomposed into finer-grain elements. These can be simple or at their turn compound elements. In this view, any model is seen as a compound element. Link Elements are connectors between pairs of elements. One of the connected elements plays the role of the Source and the other is the Target. For technical reasons, there is always an element classified as Root. This allows to indicate what the minimal content of a model is: the “Object” class in a class hierarchy, the system boundary in a Use Case diagram, etc. Property

Root

0..* has a

N o t link

Is-a

Compound Element Name

Link

Simple source target

Figure 2: Meta-model for gap typology definition

In our approach, change requirements are expressed as gaps under the form of change operations made on models. There are different kinds of such operations: adding or removing elements, changing, replacing, etc. Fourteen operators have been identified and defined on the generic level, i.e. to apply on the generic meta-model [Rolland03]. As Figure 3 shows, gaps between Use Case models can for instance be defined using these operators. C6 C1

C1 Extension condition EC3



A1

Extension condition EC1

A1

C2

Extension condition EC2

C2



C5 C5

C7

C3

A4

A3 A2

C4

C3

Figure 3: Example of Use case models evolution.

In this example, there exist some gaps between the As-Is and the To-Be models. In particular, the following operators have been used:

3

© Copyright EMSISE’03

•

AddComponent: The Use Case C6 has been added in the Use Case Diagram (which is a compound element). This could for instance correspond to a new service expected from the system. Besides, the ‘is-A’ link from C6 to C1 is added to precise the definition of this new service.

•

Merge: The use cases C3 and C4 have been merged into C3. This could for instance indicate that from now on, the corresponding services shall be provided by the system within a single transaction.

•

Split: The use case C2 has been splitted into C2 and C7. This can occur when the user requires to be able to use independently the service defined in C7.

•

ChangeOrigin: The link ‘uses’ from C3 to C2 has been changed. In the future situation, the C3 Use Case should include C7. From now on, the service defined in C7 shall be used in the context of C3.

•

RemoveComponent: The actor A2 has been removed. This gap expresses that the system shall not be used by this actor in the future.

•

Replace: The link ‘uses’ from C1 to C2 has been replaced by a link ‘extends’ from C2 to C1. This means that rather than being a sub-part of C1, the service provided by C2 shall now be a variation on a part of C1.

•

Give: The extension condition EC3 has been added to the extend link between C2 and C1. This gap comes in complement to the former one. It indicates the new conditions under which C2 shall be used within the context of C1.

•

Modify: The extension condition EC1 has been modified; in the future situation, EC2 shall replace it.

The three other operators of the generic gap typology are Retype, MoveComponent and Withdraw. Retype applies on any kind of element (Compound, Simple, Link, or Not Link). This operator can be used when an element shall have a different type in the future situation. MoveComponent only applies on Compound elements. It can be used to express the fact that the position of an element is changed with respect to a compound element. The Withdraw operator is only used for properties. Its consequence is the removal of an element’s property in the To-Be model.

2.3

Extending the view provided by the generic meta-model with the concept of gap operator

In our approach the gap operators are the generic concepts that should be instantiated to specify change requirements. Once introduced in a method, they belong to the meta-model, and thereafter they instantiate the generic meta-model. Rather than systematically re-defining this instantiation in an ad hoc way, we propose to introduce an extension to the generic meta-model. The extended generic meta-model has two parts: the first part is the core meta-model (shown in figure 2), and the second part provides a pattern defining any gap operators in the terms of the core generic meta-model. As shown in Figure 4, operators are seen as specialisations of the existing generic concepts. Indeed, an operator is a compound element that includes one or several link elements. Each of these links is set between the operator itself (as source) and any other kind of object (as target). The links with the target elements have a particular property that tell to which time horizon these shall belong: e.g. As-Is or To-Be [Salinesi03a]. For example the AddComponent operator is defined with a link to the changed compound element (identified in the As-Is model), and another link to the added element (that shall belong to the To-Be model). Similarly, the Merge operator is composed of three links; two of these target the merged elements from the As-Is model, the third link targets the resulting element to be included in the To-Be model.

4

© Copyright EMSISE’03

Compound target

Link

Operator

source

Object

has a

Time Horizon

Property

Figure 4: Extended generic meta-model

Let us take the example of Use Case Diagrams. Our Method Engineering requirement is to extend the Use Case Diagrams with gap operators such as Use Case merging. This will allow to express change requirements with extended Use Case Diagrams. The meta-model of such extended UCD shall now include the concept of MergeUseCase that links three Use Cases from different time horizons. This concepts instantiates the pattern provided by the extended generic meta-model. Besides, it reuses the definition provided by the merge operator in the generic gap typology.

3

How to change a method to support change requirements elicitation

We propose to adopt a SME approach to guide the extension of methods with a gap typology. The basis of SME is the issue of the adequacy between a project situation and the method used in the project. If the situation is such that the method used is inadequate, then it should be changed. These changes should comply to change requirements which, in our view, should be expressed as any other kind of change requirements, i.e. with gaps.

3.1

Overview of the approach

The extended generic meta-model defines gap operators as particular kinds of concepts (Figure 4). Gap operators are applicable on every concept of any meta-model. Therefore, they can be applied on themselves. It is thus correct to use a gap operator to indicate that another gap operator should be introduced or modified in a method. Gap operators are used in our approach to define the changes required on a typology of gap operators. This recursion allows us to specify extension of any specific product meta-model with an adequate typology of gap operators. The extension of product meta-models with a typology of gap operators is challenged by the achievement of quality criteria. Indeed, it is often possible to extend a product meta-model, but the important question is why the extension is needed, and what it aims for. Our view is that quality criteria can help answer these questions. Based on a literature review, we selected a number of such criteria and adapted them to the purpose of our approach: •

Completeness: the typology must be expressive enough to capture all ‘essential aspects’ of changes requirements [Teeuw97]. In other terms, the set of operators must subsume every possible change [Banerjee87], [Kradolfer00].

•

Consistency: gap operator definitions must not conflict with each other [Teeuw97]. For example, it should not be possible to define ambiguous gaps, i.e. gaps that could be interpreted as referring to different gap operators.

•

Minimality refers to the achievement of completeness with a minimal set of operators [Casati96]. In other terms, a set of gap operators can be qualified as minimal if it does not contain any operators that can be obtained by composition of others.

•

Exhaustiveness: a typology of gap operators can be considered exhaustive if any type of change can be expressed using only one of its gap operators.

•

Fitness for use: as suggested by Juran [Juran88], the question raised by this criterion is the one of meeting the customer needs. This involves adequacy to the kind of requirements dealt with (e.g. NFRs, architectural requirements), to the techniques and tools used to express them (e.g. 5

© Copyright EMSISE’03

unstructured text), as well as to the purpose of the project (e.g. creation of system, configuration management). •

Correctness: gap operators must be defined so as to preserve invariants1 that are associated to the meta-model.

It can be noticed that these criteria cannot always be simultaneously validated. For example, the criteria of minimality and exhaustiveness are clearly contradictory. Therefore, the choice of quality criteria should be carefully driven by the project situation coupled with the method extension objectives. One has to keep in mind that the non-satisfaction of one of these criteria can engender modifications in the Meta-Model. For example, in the WIDE project [Casati96], the existing gap typology fulfils the minimality, completeness, consistency and correctness quality criteria. Some change requirements, like merging two tasks in the workflow, can only be expressed by combining several operators of the existing typology. It can thus be interesting to extend it in order to achieve the exhaustiveness quality criteria. The requirement is to AddOperators such as MergeTask, SplitTask, or ReplaceVariable in the gap typology. This method extension has however for consequence that the collection of gap operators is no more minimal in the extended meta-model. Our general framework (shown in Figure 1) was adapted to take into account the usage of the gap typology to express methods extension requirements. As shown in Figure 5, the view is not anymore that of a single specific meta-model defining the method. Rather, the framework tells us that we are dealing with an evolving method represented by an As-Is and a To-Be extended specific meta-models. Each extended specific meta-model is composed of the core meta-model and a specific typology of gap operators. The former instantiates the core generic meta-model (Figure 2) whereas the latter instantiates the extension of the generic meta-model (Figure 4). The method extension requirements are expressed as instances of the generic gap typology (using the gap typology for operator object, i.e. the generic gap typology instantiated only for the operator object) insofar as operators are themselves considered as elements. These modifications, represented with ∆ in Figure 5 allow to obtain a To-Be extended specific meta-model. Generic Meta-model level

Extended Generic Meta-model Instance of

Specific Meta-model level

As-Is Extended Meta-Model

Part of

Generic Typology

Instance of

Δ

Instance of

Gap Typology for operator object

Instance of

Δ Δ

To-Be Extended Meta-model

Figure 5: Schema of the extended eliciting change requirements approach

For example, the Orion meta-model, formalized by the extended generic meta-model and further extended with our typology of gap operators has two different representations: one for the As-Is (before extension) and one for the To-Be (after the extension). The required differences between these two are represented by gaps which instantiate the gap typology for operator object.

3.2

Method extension process

Figure 6 presents our method extension process using the Map formalism [Rolland99], [Rolland01]. A map is an oriented graph which nodes are goals and edges strategies, i.e. ways to achieve a goal. Maps organise goals and strategies to represent the flow of decisions made in the process. Contrary to what could be assumed from the directed nature of maps, the purpose is not to specify a sequence of goal achievements, but to represent a non-deterministic ordering of goal/strategy selections.

1

Invariants are properties of the meta-model that hold at every quiescent state, that is, before and after any model modification [Banerjee87].

6

© Copyright EMSISE’03

The overall objective of the map represented Figure 6 is to extend the specific meta-model of a method. Two situations can occur: either the meta-model is already composed of a typology (it is already extended), or not. Formalising the extended specific meta-model is essential as it allows to precisely specify the situation. This process aims at the two main goals identified in the map: “Formalise core meta-model” and “Define extension”. Several strategies are available to achieve those; the Generic meta-model driven strategy and the Meta-model knowledge driven strategy for the former goal, and the Extension formalisation strategy for the latter. -

The principle of the Generic meta-model driven strategy is to formalise the method’s core specific meta-model with the concepts defined in the generic core meta-model.

-

The Meta-model knowledge driven strategy, uses the conceptual knowledge of the method to refine the core specific meta-model that has already been formalised.

-

The purpose of the Extension formalisation strategy is to define using the extended generic metamodel formalism, the concepts that already exist in the method to specify change requirements.

Two remarks shall be made: (i) having formalised concepts in the core meta-model is a pre-requisite for defining concepts in the extension part, hence the flow from the “Formalise core meta-model” goal to the “Define extension” goal, and (ii) the method has so far not been modified as no supplementary extension has been made, the only improvement stands in the reformulation of its As-Is extended meta-model. At this point in time, it is possible to evaluate the As-Is extended meta-model using one of the six “Stop” strategies. Each of them proposes to perform this evaluation according to one of the six quality criteria described above. If the quality of the method is found sufficient, then no improvement is needed and the process terminates. Its added value is then to demonstrate the qualities of the existing method. In the opposite case, the quality criteria will provide input on the target of the method extension process. In addition to the Extension formalisation strategy, the map proposes to define the extended metamodel By extension typology based strategy. This strategy uses the generic gap typology to generate “from scratch” a gap typology that is adapted to the core specific meta-model. Once the collection of gap operators defined in the meta-model, it should be worked out to reach the chosen quality criteria. The required method improvements can be specified using the gap typology for operator object. This is the proposal made in the By application of meta-model modification operator strategy. This strategy is refined into eight sub-strategies each corresponding to an operator. The modifications on the extended meta-model can thus be made following the RenameOperator, the MergeOperator, the SplitOperator, the ReplaceOperator, the ChangeOrigin, the AddOperator, the RemoveOperator, or the MoveOperatorComponent strategy. Each of the six quality criteria can be evaluated at any moment using the corresponding “Stop” strategy. The modification process ends up when the quality of the To-Be extended meta-model meets the initial expectations. Start

Generic meta-model driven strategy

Formalise core meta-model

Extension typologybased strategy

By fitness for use strategy By minimality strategy By concistency strategy

Meta-model knowledge driven strategy Extension formalization strategy

Define extension

By application of metamodel modification operator strategy

Stop

By completeness strategy By exhaustiveness strategy By correctness strategy

Figure 6: Modification process of an extended specific meta-model

7

© Copyright EMSISE’03

Although the purpose of this process is to extend methods so that they allow the specification of change requirements, we believe it can be reused to improve their core too. For example, the second goal “Define extension” could be replaced by the more general goal “Define modification”, and Metamodel modification operator strategies could be additionally proposed for the core meta-model, e.g. to AddLink, RemoveElement, etc. Let us for instance take the case where temporal concepts such as the Calendar class are needed in the Orion method. The AddElement, and AddLink, strategies of this adapted process can be used to specify the need to add the Calendar class in the To-Be core metamodel, then link it to the Object class.

4

Example

This section proposes to illustrate our approach by extending the Orion method with an exhaustive typology of gap operators [Banerjee87]. The existing Orion meta-model proposes an already rich collection of gap operators. However, it can easily be shown that this collection is not exhaustive. For example, it does not allow to express change requirements such as mergeClass or splitClass with a single gap operator. The required extension should preserve the completeness, correctness and consistency qualities of the extended Orion metamodel. The To-Be meta-model extension should also be exhaustive. The next subsections indicate how the proposed process can be used to attain this goal.

4.1

Formalising the Orion core meta-model

First, the Orion core meta-model has to be formalised with the concepts defined in the generic metamodel. Figure 7 uses grey levels to emphasise which concept of the generic meta-model is instantiated. For example, a Class is a compound element that contains Methods and Instance Variables. These are simple elements with various properties. Two kinds of Links relate Classes: the Composition Link, and Is-A Links. The former are defined as link elements with Class elements as both source and target. The latter are defined as Link elements with Sub-Classes and Super-Classes respectively as source and target. This allows to associate the Order property to Super Classes to define priorities in case of multiple inheritance. Class Hierarchy Has for source

Composite Link

Object Has for target

Simple Compound Link Property

Class Super Class Has for target

Has a

1

1

Code Has for target

Order

Is-A Link Has for source

Method Has a

Instance Variable Sub Class Has a

1

* *

Domain Default Value Shared Value

Inheritance Link Has for source

Figure 7: Instantiation of the generic meta-model for Orion meta-model

4.2

Defining Orion’s extension by the typology-based strategy

It has already been identified that the As-Is extended meta-model is non exhaustive. A complete typology is thus constructed from the Orion specific meta-model and the generic gap typology, as reported in [Etien03]. The collection of gap operators generated that way is listed in Table 1. The table emphasises the instantiated generic operator (in row), and the object of the Orion meta-model on which the generated operator applies (in column). Four additional gap operators are generated (to add and remove an empty Class Hierarchy and its Object class). These are not presented in the table for the sake of space.

8

© Copyright EMSISE’03 Generic Operator Rename

Name of the operator RenameClass RenameMethod RenameInstanceVar RenameIsA RenameComposite RenameInheritanceLink MergeClass Merge MergeMethod MergeInstanceVar MergeIsA MergeComposite MergeInheritanceLink SplitClass Split SplitMethod SplitInstanceVar SplitIsA SplitComposite SplitInheritanceLink ChangeOriginIsA ChangeOrigin ChangeOriginComposite ChangeOriginInheritance AddClass AddComponent AddMethod AddInstanceVar AddIsA AddComposite AddInheritanceLink RemoveComponent RemoveClass RemoveMethod RemoveInstanceVar RemoveIsA RemoveComposite RemoveInheritanceLink RetypeClass Retype RetypeMethod RetypeInstanceVar RetypeIsA RetypeComposite RetypeInheritanceLink GiveCode Give GiveDomain GiveDefaultValue GiveSharedValue GiveOrder WithdrawCode Withdraw WithdrawDomain WithdrawDefaultValue WithdrawSharedValue WithdrawOrder ModifyCode Modify ModifyDomain ModifyDefaultValue ModifySharedValue ModifyOrder

As-Is Object Class Method InstanceVariable Is-A Link CompositeLink InheritanceLink Class, Class Method, Method, InstanceVar, InstanceVar Is-A Link, Is-A Link CompositeLink, CompositeLink InheritanceLink, InheritanceLink Class Method InstanceVariable Is-A Link CompositeLink InheritanceLink Is-A Link CompositeLink InheritanceLink Class Hierarchy Class Class Class Hierarchy Class Hierarchy Class Hierarchy Class Method InstanceVariable Is A Link CompositeLink InheritanceLink Class Method InstanceVariable Is A Link CompositeLink InheritanceLink Method InstanceVar InstanceVar InstanceVar Is A Link Code Domain DefaultValue SharedValue Order Code Domain DefaultValue SharedValue Order

To-Be Object Class Method InstanceVariable Is-A Link CompositeLink InheritanceLink Class Method InstanceVariable Is-A Link CompositeLink InheritanceLink Class, Class Method, Method, InstanceVar, InstanceVar Is-A Link, Is-A Link CompositeLink, CompositeLink InheritanceLink, InheritanceLink Is-A Link CompositeLink InheritanceLink Class Method InstanceVariable Is A Link CompositeLink InheritanceLink Class Hierarchy Class Class Class Hierarchy Class Hierarchy Class Hierarchy Method or InstanceVar Class or InstanceVar Class or Method Composite or Inheritance Is-A or Inheritance Is-A or Composite Code Domain DefaultValue SharedValue Order Method InstanceVar InstanceVar InstanceVar Is A Link Code Domain DefaultValue SharedValue Order

Table 1: Complete typology by instantiation of the generic typology

It can be noticed that the operators ChangeSource and ChangeTarget are only applicable to Link elements. Similarly, the Give, Withdraw and Modify operators only act on properties and are not relevant for the elements that do not have a property. These restrictions directly result from the exploitation of the Orion-specific meta-model structure which instantiates the generic meta-model.

4.3

Defining Orion’s extension using the extension formalisation strategy

Orion already proposes a number of operators to express change requirements as shown in [Banerjee87]. The purpose of this section is to show how these operators are formalised with our meta-model. According to the meta-model, each operator has a name and is composed of links with objects in As-Is models and links with objects in To-Be models. Table 2 emphasises for each of the Orion operators the list of objects it is linked to in As-Is models, and the list of objects it is linked to in To-Be models.

9

© Copyright EMSISE’03 Orion Operator As-Is concept Add a new instance variable to a class Class Drop an existing instance variable from a class InstanceVariable Change the name of an instance variable of a class InstanceVariable Change the domain of an instance variable of a class Domain Change the default value of an instance variable DefaultValue Add a shared value InstanceVariable Change the shared value SharedValue Drop the shared value SharedValue Drop the composite link of an instance variable CompositeLink Add a new method to a class Class Drop an existing method from a class Method Change the name of a method of a class Method Change the code of a method in a class Code Change the inheritance of a method InheritanceLink Make a class S a superclass of a class C Class Hierarchy Remove a class S from the superclass list of a class list Is-A Link of a class Change the order of superclasses of a class C Order Add a new class Class Hierarchy Drop an existing class Class Change the name of a class Class

To-Be Concept InstanceVariable Class InstanceVariable Domain DefaultValue SharedValue SharedValue InstanceVariable Class Hierarchy Method Class Method Code InheritanceLink Is-A Link Class Hierarchy

Corresponding operator AddInstanceVariable RemoveInstanceVariable RenameInstanceVariable ModifyDomain ModifyDefaultValue GiveSharedValue ModifySharedValue WithdrawSharedValue RemoveComposite AddMethod RemoveMethod RenameCode ModifyCode ReplaceInheritance AddIsA RemoveIsA

Order Class Class Hierarchy Class

ModifyOrder AddClass RemoveClass RenameClass

Table 2: Formalisation of the Orion existing operators

The last column of the table identifies the corresponding operators instantiated from the generic typology. As shown by the table, each of the operators proposed by Orion has a unique equivalent directly instantiated from the generic typology.

4.4

Application of the meta-model modification operator strategy

The Orion extended meta-model is now composed of a number of operators formalised from Orion, and of a number of operators generated from our generic typology. In order to achieve consistency, it is necessary to compare both lists of operators (as done in Table 2), and change the extended metamodel, as proposed by the meta-model modification operator strategy. For example, the operator AddInstanceVariable obtained from the generic typology (Table 1) and Orion’s operator “add a new instance variable to a class” (Table 2) are identical. Thus, an application of mergeOperator is required on those. This results into the AddInstanceVariable operator shown in Table 3. Besides, a number of the operators generated from generic typology, like RenameIsALink or RetypeComposite are meaningless with respect to Orion. Application of RemoveOperator is thus required. Therefore these operators do not appear in the resulting list. The same reasoning is applied on the other Orion operators and the other operators generated from the generic typology. The resulting consolidated list of operators is shown in Table 3. The operators that directly result from our generic typology are emphasised in bold. All the other operators result from a merge with Orion’s operators. Operator Rename

Class Method RenameClass RenameMethod

Instance Variable RenameInstanceVar

Is-A Link N/A

Composite Link Inheritance Link N/A N/A

Merge Split

MergeClass SplitClass

MergeInstanceVar SplitInstanceVar

N/A N/A

N/A N/A

Replace

ReplaceClass ReplaceMethod ReplaceInstanceVar

N/A

ReplaceComposite ReplaceInheritance

Change

N/A

ChangeSource ChangeSource

ChangeSource

Origin

N/A (not applicable)

ChangeTarget ChangeTarget

ChangeTarget

AddComponent

AddClass

AddMethod

AddInstanceVar

AddIsA

AddComposite

N/A

RemoveComponent RemoveClass RemoveMethod

RemoveInstanceVar

RemoveIsA

RemoveComposite

N/A

Retype

RetypeClass N/A

RetypeInstanceVar

N/A

N/A

N/A

Give

N/A

GiveDomain

N/A

N/A

N/A

N/A

N/A

N/A

ModifyOrder

N/A

N/A

MergeMethod SplitMethod

GiveCode

N/A

N/A N/A

GiveDefaultValue GiveSharedValue ithdraw

N/A

WithdrawCode WithdrawDomain WithdrawDefaultValue WithdrawSharedValue

Modify

N/A

ModifyCode

ModifyDomain ModifyDefaultValue ModifySharedValue

Table 3: Typology of gaps for the Orion system

10

© Copyright EMSISE’03

4.5

Verifying the quality criteria to stop the process

As shown in the previous sub-sections, an effort was made to achieve exhaustiveness (by exploiting the generic typology), and consistency (by cross-checking the operators generated from the typology and those initially proposed by Orion). Our process model proposes to evaluate the quality of the resulting extended meta-model to verify the quality criteria that were initially chosen. 4.5.1

Exhaustiveness

A typology can be considered exhaustive if any change requirement can be expressed without using a combination of gap operators. There is no formal way to demonstrate exhaustiveness. In this example, exhaustiveness was empirically evaluated using the examples of change requirements found in the Orion literature. The collection of operators shown in table 3 was found exhaustive as every change requirements could be formalised using a single operator. This confirms our findings reported in [Etien03] concerning the exhaustiveness of our approach on the generic level. 4.5.2

Completeness

On the one hand, [Banerjee87] demonstrates that Orion’s initial collection of gap operators is complete (i.e. every change requirements can be expressed using it, if necessary by combining several operators). On the other hand, no operator from this collection has been removed; only merges have been achieved with the operators generated from the generic typology when they had the same semantics. This formally demonstrates that the resulting extended meta-model proposes a complete collection of gap operators to express any change requirement in Orion. 4.5.3

Correctness

The proposed collection of gap operators can be considered as correct if and only if each operator definition is itself correct. As defined in [Rolland03], an operator is correct when it preserves the invariant properties of the model it applies to. In the case of Orion, Banerjee defines the five following invariant properties on the core meta-model: •

Class lattice invariant: “the lattice is a rooted and connected directed acyclic graph with named nodes and labelled edges. It has only one root and its nodes have a different name”.

•

Distinct Name invariant: “all instance variables and methods of a class have a distinct name”.

•

Distinct identity invariant: “all instance variables and method of a class have distinct identity”.

•

Full inheritance invariant: “a class inherits all instance variables and method from each of its superclasses, except when full inheritance causes a violation of the distinct name and distinct identity invariants”.

•

Domain compatibility invariant: “if an instance variable V2 of a class C is inherited from an instance V1 of a superclass of C, then the domain of V2 is either the same as that of V1 or a subclass of V1”.

For the sake of space, we do not present the formal definition of the 45 operators. These definitions are obtained by adapting those presented in [Rolland03]. For example, AddClass has the following formal definition: AddClass: {Class} → {Is-Alink}, Class AddClass({C i}) = Ij.has-for-source(C1) ∧ Ij.has-for-target(C) ∧ ∀k, C.name ≠ Ck.name ∧ [ ∀M1, M2, (C.composed-of(M1) ∧ C.composed-of(M2)) ⇒ M1.name ≠ M2.name] ∧ [ ∀IV1, IV 2, (C.composed-of(IV1) ∧ C.composed-of(IV2)) ⇒ IV1.name ≠ IV 2.name] | Ij ∈ Is-Alink, (C, Ci, Ck) ∈ Class, (M1, M2) ∈ Method (I1, I2) ∈ InstanceVariable.

11

© Copyright EMSISE’03

This definition indicates that the result of adding a class C should be such that: (i) C has one or several existing super-class(es) Ci (ii) C and Ci, are associated through Is-Alink Ij, (iii) there is no other class that has the same name as C, (iv) all methods in C have a different name, and (v) all variable instances of C have a different name. These two last properties are relevant because an added class implicitly inherits from its super-classes’ methods and instance variables. Cross checking this definition with Orion’s list of invariant properties shows that : -

the first invariant is preserved as the class is only added if it has a different name than the other classes of the hierarchy, and because the class is a leaf in the class hierarchy (it cannot belong to a cycle as it is not the source of any Is-A link);

-

the second, third and fourth invariants are preserved as the class can only be added if it isn’t composed of methods or instance variables with the same name, therefore, two methods or instance variables of the added class cannot have the same identity;

-

the fifth invariant is preserved as when a variable instance is inherited, it implicitly comes with its domain.

As a result, the AddClass operator is correct. A similar cross-checking of all operators with all Orion’s invariants shows that the proposal is correct. 4.5.4

Consistency

Both Orion’s collection of gap operators and the generated one are consistent. Each operator of the former collection has been merged with one of the latter when their semantic were the same. As a result there is no conflict between the operators. The resulting collection of gap operators is thus consistent. All the quality criteria are verified, the process to extend the gap typology for the Orion meta-model can thus be considered as terminated.

5

Conclusion

This paper proposes an approach to extend any method with concepts to express change requirements. A generic typology of gap operators and a generic meta-model have already been proposed to specify the concepts necessary when expressing change requirements. The approach presented here combines both of them to extend methods until they satisfy some quality criteria. The main assumption underlying this approach is that any of our gap operators can be regarded: (i) on the model level (to define change requirements), (ii) on the meta-model level (to define changes needed on meta-models), and (iii) on the generic meta model level (as part of a generic meta model). The proposed approach combines an extended version of the generic meta-model with a process to guide method extension. The processes offers a number of strategies to achieve two main goals: formalise the meta-model and define extension, and to evaluate the quality of the resulting method with respect to a number of quality criteria. So far, the main flaw of our approach is that it doesn’t tell what to do with models when the corresponding meta-models are extended. We believe this issue is similar to the one addressed when looking at what to do with the running instances of a system when the model that defines it evolves [Salinesi03b]. Addressing this issue is the main concern of the next stage in our research programme, together with undertaking an empirical investigation of our approach, and with developing a prototype tool to guide its application.

12

© Copyright EMSISE’03

6

References

[Banerjee87] J. Banerjee, W. Kim, H.-J. Kim, H.F. Korth, Semantics and Implementation of Schema Evolution in Object Oriented Databases, Proceedings of the ACM-SIGMOD Annual Conference, pp 311-322, San Francisco, CA, May 1987. [Casati96] F. Casati, S. Ceri, B. Pernici, G. Pozzi, Workflow Evolution, Proceedings of the 15th International Conference On Conceptual Modeling (ER'96), Cottbus, Germany, pp. 438-455, 1996. [Deneckère01] R. Deneckère, Approche d’extension de méthodes fondée sur l’utilisation de composants génériques, PhD Thesis, University of Paris1 Panthéon-Sorbonne, January 2001. [Etien03] A. Etien, C. Salinesi, Towards a Systematic Definition of Requirements for Software Evolution: A Case-study Driven Investigation, Proceedings of EMMSAD’03, Klagenfurt/Velden, Austria, June, 2003. [Harmsen94] A.F. Harmsen, S. Brinkkemper, H. Oei, Situational Method Engineering for Information System Projects, In Olle T. W. and A. A. Verrijn Stuart (Eds.), Methods and Associated Tools for the Information Systems Life Cycle, Proceedings of the IFIP WG8.1 Working Conference CRIS'94, pp. 169-194, North-Holland, Amsterdam, 1994. [Harmsen97] A.F. Harmsen, Situational Method Engineering, Moret Ernst & Young , 1997. [Jackson95] M. Jackson, Software Requirements and Specifications, Addison-Wesley, 1995. [Juran88] J. M. Juran, F. M. Gryna, Juran’s Quality Control Handbook, Mac Graw Hill, 1988. [Kradolfer00] M. Kradolfer, A Workflow Metamodel Supporting Dynamic, Reuse-based Model Evolution, PhD thesis, Department of Information Technology, University of Zurich, Switzerland, chap. 4, pp. 59-73, May 2000. [Lyytinen87] K. Lyytinen, Different perspectives on information systems : problems and solutions, ACM Computing Surveys, Vol 19, No1, 1987. [Ralyté99a] J. Ralyté, C. Rolland, V. Plihon, Method enhancement With Scenario Based Techniques, Proceedings of the 11th Conference on Advanced Information Systems Engineering (CAISE’99), Heidelberg, Germany, June, 1999. [Ralyté99b] J. Ralyté, Reusing Scenario Based Approaches in Requirement Engineering Methods: CREWS Method Base, Proceedings of the First International Workshop on the Requirements Engineering Process Innovative Techniques, Models, Tools to support the RE Process, Florence, Italy, September 1999. [Ralyté01] J. Ralyté, Ingénierie des méthodes à base de composants, PhD Thesis, University of Paris1 PanthéonSorbonne, January 2001. [Rolland01] C. Rolland, N. Prakash, Matching ERP System Functionality to Customer Requirements, Proceedings of the 5th International Symposium on Requirements Engineering (RE'01), Toronto, Canada, pp. 66-75, 2001. [Rolland93] C. Rolland, Modeling the requirements engineering Process, Information Modelling and Knowledge Bases, IOS Press, 1993. [Rolland94a] C. Rolland, Modeling the evolution of artifacts, Proceedings of the 1st IEEE International Conference on Requirements Engineering, Colorado Springs, Colorado, 1994. [Rolland94b] C. Rolland, A Contextual Approach to modeling the Requirements Engineering Process, Proceedings of the 6th International Conference on Software Engineering and Knowledge Engineering (SEKE'94), Vilnius, Lithuania, 1994. [Rolland96] C. Rolland, V. Plihon, Using generic chunks to generate process models fragments, Proceedings of the 2nd IEEE International Conference on Requirements Engineering (ICRE’96), Colorado Spring, 1996. [Rolland98] C. Rolland, V. Plihon, J. Ralyté, Specifying the reuse context of scenario method chunks, Proceedings of the 10th Conference on Advanced Information Systems Engineering (CAiSE’98), Pisa Italy, June 1998. [Rolland99] C. Rolland, N. Prakash, A. Benjamen, A Multi-Model View of process Modelling, Requirements Engineering Journal, Vol 4, pp 169-187, 1999. [Rolland03] C. Rolland, C. Salinesi, A. Etien, Eliciting Gaps in Requirements Change, To appear in Requirement Engineering Journal, 2003. [Saeki93] M. Saeki, K. Iguchi, K Wen-yin, M Shinohara, A meta-model for representing software specification & design methods, Proceedings of the IFIP¨WG8.1 Conference on Information Systems Development Process, Come, pp 149-166, 1993.

13

© Copyright EMSISE’03

[Salinesi02a] C. Salinesi, M. J. Presso, A Method to Analyse Changes in the Realisation of Business Intentions and Strategies for Information System Adaptation, Proceedings of the 6th IEEE International Enterprise Distributed Object Computing Conference (EDOC’02), Lausanne, Switzerland, September 2002. [Salinesi02b] C. Salinesi, J. Wäyrynen, A Methodological Framework for Understanding IS Adaptation through Enterprise Change, Proceedings of the 8th International Conference on Object-Oriented Information Systems (OOIS’02), Montpellier, France, September 2002. [Salinesi03a] C. Salinesi, C. Rolland, Fitting Business Models to Systems Functionality Exploring the Fitness Relationship, Proceedings of the 15th Conference on Advanced Information Systems Engineering (CAiSE’03), Klagenfurt/Velden, Austria, June, 2003. [Salinesi03b] C. Salinesi, A. Etien, Compliance Gaps: a Requirements Elicitation Approach in the Context of System Evolution, To appear in the proceedings of the 9th International Conference on Object-Oriented Information Systems (OOIS’03), Geneva, Switzerland, September 2003. [Slooten93] K. van Slooten, S. Brinkkemper, A Method Engineering Approach to Information Systems Development, In Information Systems Development process, N. Prakash, C. Rolland, B. Pernici (Eds.), Elsevier Science Publishers B.V. (North-Holand), 1993. [Teeuw97] W. B. Teeuw, H. van den Berg, On the Quality of Conceptual Models, Proceedings of the 16th International Conference on Conceptual Modeling (ER'97), Los Angeles, CA, November 1997.

14