A META-MODELLING APPROACH

TO EXPRESS CHANGE REQUIREMENTS

Anne Etien, Colette Rolland, Camille Salinesi

CRI - Université Paris 1 – Sorbonne, 90, rue de Tolbiac, 75013 Paris – France

Keywords: Meta-modelling, Change requirements, Evolution.

Abstract: Organisations have to evolve frequently in order to remain competitive and to take into account changes in

their environment. We develop a co-evolution approach to jointly make evolve the information system and

the business processes. This approach relies on an explicit specification of change requirements defined

with operators expressing gaps between the As-Is and the To-Be situations. However, such gaps based

approach can also be used in an other evolution context, when a database or a workflow model evolves.

Thus, instead of specifying new operators associated to the Map meta-model used in this co-evolution

approach, we propose to define a generic typology of gaps to facilitate a precise definition of change

requirements under the form of gaps. The paper presents the approach to generate a gap typology and

illustrates it with the Map meta-model.

1 INTRODUCTION

Changes often affect an organization in its whole

from business processes to information system. If

they want to remain competitive, organisations have

to react quickly to changes of their clients’ needs or

organization goals.

We propose the Alignment and Co-Evolution

Method (ACEM) to help in jointly evolving the

business processes and the system. In that method,

the change movement is modelled from the current

situation to the future situation as gaps between the

As-Is model and the To-Be model. Intuitively a gap

expresses a difference between these two models

such as the deletion or addition of an As-Is element

in the To-Be model. Gaps are related to operators,

which transform elements of model.

We believe that an ad-hoc development of a gap

typology for each project is error prone because: (i)

it relies on the knowledge and know-how of some

persons; (ii) it is not systematic and (iii) it can be

influenced by the context of the project.

We thus could define a typology associated to

the Map meta-model used in ACEM. However, such

a typology would have been dependent of the used

formalism.

Furthermore, developing a specific typology for

each meta-model (e.g. XML DTD (Al-Jadir, 2003),

DB meta-model (Banerjee, 1987), process meta-

model (Soffer, 2004), workflow meta-model (Casati,

1996)…), leads to a situation where the typologies

depend on different specific meta-models and are

difficult to compare (Estublier, 2000).

In order to solve these issues, we propose to

introduce a generic typology relative to a generic

meta-model. This provides independence towards

the project and the meta-model. The generic meta-

model can be instantiated by each used meta-model.

The generic typology associated to the generic meta-

model is adapted to correspond to each specific

meta-model. Such an approach allows to

systematically identify the semantic and structural

aspects that compose the specific meta-model and

can be affected by a gap.

In the next section we provide an overview of the

approach. In section 3, we present the generic meta-

model and the generic gap typology. Section 4

outlines the process to generate a specific gap

typology and illustrates it with the Map meta-model

used in ACEM. Conclusions are drawn in section 5.

287

Etien A., Rolland C. and Salinesi C. (2006).

A META-MODELLING APPROACH TO EXPRESS CHANGE REQUIREMENTS.

In Proceedings of the First International Conference on Software and Data Technologies, pages 287-293

DOI: 10.5220/0001322102870293

 SciTePress

2 OVERVIEW OF THE

APPROACH

The approach, we propose to express change

requirements, relies on a three levels structure: the

model level, the meta-model level and the generic

meta-model level, as shown in Figure 1.

At the model level, are defined the models before

and after evolution. At this level are also defined the

change requirements (represented in the figure by

the Greek letter ∆) under the form of gaps. In so far

as in the ACEM As-Is model and To-Be model are

defined with the Map meta-model, we make the

hypothesis that the two models As-Is and To-Be are

described in the same language. We are thus not

interested in evolutions where As-Is and To-Be

models are instances of two different meta-models

as in (Terrasse, 2003) or (Bezivin, 2001).

The meta-model level contains the specifications

of a specific meta-model and the associated gap

typology. The specific meta-model specifies the type

of elements used in the As-Is and To-Be models.

From the same way, the specific gap typology

specifies the type of gap operators defined at the

model level. The gaps identified between the As-Is

and the To-Be models are instances of the specific

gap typology.

The generic meta-model level proposes a generic

gap typology and a generic meta-model from which

are respectively defined the specific typology and

the specific meta-model. The generic meta-model

identifies the generic concepts necessary to the

definition of generic operators gathered in the

generic gap typology. The generic meta-model

allows to make explicit the elements and the

structures of the specific meta-models.

For example, if the Entity-Relationship meta-

model is used to represent the database, then the

gaps are expressed at the model level between two

Entity-Relationship models. The gaps between the

As-Is and the To-Be models expressed what changes

or should be adapted between the two situations.

They instantiate the operators of the specific

typology. They can express that the Reservation

Entity type should be split into two Entities type

Reservation and Demand and that the ‘correspond’

Relationship type (whose source is Reservation and

target is Demand) should be added.

3 THE GENERIC TYPOLOGY

The generic gap typology takes the form of a set of

operators applicable to generic elements that

compose any model.

3.1 A Meta-model for Defining the

Generic Gap Typology

A number of attempts have been made to make

explicit the elements that compose any model, i.e. to

define meta-models (IRDS, 1990), (Marttiin, 1994),

(Prakash, 1999). There are different meta-models

depending on the meta-modelling purpose. For

example IRDS (IRDS, 1990) is a standard to

facilitate the evolution of model representation in

CASE tools, Prakash (Prakash, 1999) aims at a

formal definition of a method and Marttiin (Marttiin,

1994) searches for a generic repository structure of

meta-Case environments.

Instance of

Typology of

operators

Applied on

elements of

Instance of

Typology of

operators

Instance of

Typology of

operators

Applied on

elements of

Applied on

elements of

Generic Meta-

model

Instance of

Generic

Meta-model

level

Generic Meta-

model

Instance of

Generic Meta-

model

Instance of

Generic

Meta-model

level

Generic

Meta-model

level

Generic Gap

Typology

Applied on

elements of

Generic Gap

Typology

Applied on

elements of

Applied on

elements of

Model

level

Specific

Meta-model

level

Meta-

model

Instance of Instance of

Specific

Meta-model

level

Meta-

model

Instance of Instance of

Meta-

model

Instance of Instance of

As-Is

model

To-Be

model

Instance of

∆

Instance ofInstance of

∆

Figure 1: Overview of the approach.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

288

The generic meta-model, that we propose, aims to

identify the key elements and the structure of any

meta-model having a graphic representation in order

to define the elementary transformations that can

occur on the elements of a meta-model.

This meta-model is drawn in Figure 2 using UML

notations. It shows that any model is made of

Elements, every element having a Name and is

characterised by a set of Property. In the E/R model

for example, Entity type, Attribute and Relationship

type as well as the Is-A relationship are elements.

Domain is a property of Attribute.

According to the generic meta-model, any meta-

model is composed of a collection of elements that

have properties. As shown in Figure 2, Elements are

classified into two clusters. First, a distinction

between Simple and Compound Elements is made.

Second, elements can be classified into Link and

NotLink.

Compound elements are composed into elements

that can be simple or at their turn compound. In

particular, any model is a compound element.

Link Elements are connectors between pairs of

elements. Links can be oriented; therefore one of the

linked elements plays the role of Source and the

other of Target. In the E/R model an Entity type is a

compound element made of Attributes, which are

simple elements. An Is-A relationship of the E/R

model is a Link: it connects a source Entity type to a

target Entity type. Vice versa, an Entity type is

NotLink.

Figure 2 shows that an element is-a another

element, i.e. might inherit from another element

Finally, any model is a compound element which

can be reduced to the root element (such as the

Object class in a class diagram).

3.2 The Generic Gap Typology

The generic gap typology is composed of a set of

operators applicable to Element. Each operator

identifies a type of change that can be performed on

an As-Is model. The operator identifies the

difference between the As-Is model and the To-Be

model

3.2.1 Three Types of Change

The generic gap typology identifies three major

types of change: naming changes, element changes

and structural changes.

Table 1: Meta-model elements and related operators.

Object Operator Description

Element Rename

Add

Remove

Merge

Split

Replace

Change the name of the element in the To-Be model

Add an element in the To-Be model

Remove an element of the As-Is in the To-Be model

Two separate As-Is elements become one in the To-Be model

One As-Is element decomposes into two To-Be elements

An As-Is element is replaced by a different To-Be one

Link ChangeOrigin The source or target of the link is changed

Compound AddComponent

RemoveComponent

MoveComponent

A component is added in the To-Be element

An As-Is component is removed in the To-Be element

A component is repositioned in the structure of the To-Be element

Property Give

Withdraw

Modify

Retype

Add a property to the To-Be element

Remove an As-Is property in the To-Be element

Change the property of the To-Be element

The As-Is and To-Be elements have different types

Figure 2: The meta-model for gap typology definition.

Not Link

source

target

Link

Compound

Simple

Element

Name

Is-aIs-a

Property

has a

Root

Type

0..*

0..1 0..1

A META-MODELLING APPROACH TO EXPRESS CHANGE REQUIREMENTS

289

Naming changes are defined with the Rename

operator. It only affects the way organisations want

to refer to an element.

Element changes affect elements and are

circumscribed to the elements themselves: adding an

attribute to an entity type is an example of such

localised change. Table 1 proposes four operators to

specify element changes, namely Modify, Give,

Withdraw and Retype.

Structural changes correspond to a modification

of the set of elements which composes the model.

There are nine operators to specify structural

changes in Table 1: ChangeOrigin, AddComponent,

MoveComponent, RemoveComponent, Replace,

Split, Merge, Add and Remove. For example adding

or removing Relationship types and Entity types in

an As-Is E/R schema to form the To-Be schema is a

structural change. Table 1 sums up the generic gap

typology composed of 14 operators classified

according to the type of Element they are applied on.

3.2.2 Structure of a Generic Operator

The definition of the operators relies on two

concepts: a signature and a predicate as shown in

Figure 3.

The signature identifies the type of the elements

involved in the As-Is model (before the operator is

executed), and in the To-Be model (after the

execution of the operator). The predicate is

composed of two elements: a first order logic

formula and eventually some parameters. The

formula does not indicate how to modify the As-Is

model but specifies the conditions that must be

fulfilled in the To-Be model. It relies on the

concepts of the specific meta-model (a concept

being an Element or a Property). A parameter refers

to a concept.

3.2.3 Structure of a Generic Operator

The definition of the operators relies on two

concepts: a signature and a predicate as shown in

Figure 3.

The signature identifies the type of the elements

involved in the As-Is model (before the operator is

executed), and in the To-Be model (after the

execution of the operator). The predicate is

composed of two elements: a first order logic

formula and eventually some parameters. The

formula does not indicate how to modify the As-Is

model but specifies the conditions that must be

fulfilled in the To-Be model. It relies on the

concepts of the specific meta-model (a concept

being an Element or a Property). A parameter refers

to a concept.

In order to take into account the concepts of the

generic meta-model and the links that exist between

them, we introduce some functions that are used in

the formula such as has-for-source() that is applied

on a Link and that takes in parameter an Element.

This function allows to specify the Element that is

the source of the Link element. We can thus write

L.has-for-source(E) where L is a Link and E is an

Element.

From this structure, this function and four other

ones, the fourteen operators of the generic typology

can be formally defined.

The operator Add is differently defined

depending on whether the element to add is a Link

element of a Not Link element:

(signature) AddLink: NotLink² → Link,

NotLink²

(predicate) AddLink (NL

, NL

) = L ∈ M ∧ L.

has-for-source(NL

) ∧ L. has-for-

target (NL

) | L ∈ Lien, NL

, NL

∈ NotLink, M ∈ Model

(signature) AddNotLink: Model → NotLink

(predicate) AddNotLink (M) = NL ∈ M | NL

∈ NotLink, M ∈ Model

The operator AddLink allows to add a Link L

between two NotLink elements NL

and NL

. After

application of the operator, in the To-Be model, L is

an element of the model M. L has for source NL

and for target NL

The operator AddNotLink allows to add the

NotLink element NL in the model M. After

application of the operator, NL belongs to the model

The model is always present before and after the

application of the operator. It appears as element in

the signature, only when it is the only element

specifying the As-Is or the To-Be situation, as in the

definition of the AddNotLink operator.

All the other operators are described from the

same way (more details can be found in (Etien,

2006)).

3.2.4 Properties of the Generic Typology

From the literature, we identify properties that a gap

typology should fulfil: a typology is considered as

(i) complete if any model can be derived from any

other model (Kradolfer, 2000); (ii) correct if each

operator is correct i.e. it does not leave the model in

an incorrect state (Banerjee, 1987), (iii) consistent if

the definition of its operators do not conflict each

other (Teeuw, 1997), (iv) semantically rich if any

type of change can be expressed using only one

operator and (v) minimal if any operator can be

considered as the composition of others (Casati,

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

290

Operator

Signature

Predicate

Formula

Name

Parameter

Concept

refers

0..*

1..*

0..*

uses

As-Is

To-Be

0..*

1..*

Figure 3: Model of operator.

1996). These two last properties are contradictory

and can not be fulfil at the same time.

The generic typology verifies each of these

properties. Based on (Banerjee, 1987), we

demonstrate in (Rolland, 2004) and (Etien, 2006)

that the generic typology is complete. The

verification of the consistency and correctness relies

on the formal definition of the operators. Finally, it

is clear that the typology is semantically rich what

allows to better answer to the customer requirements

expressing, e.g. merger or replacement of elements.

4 GENERATION OF A SPECIFIC

GAP TYPOLOGY

We propose a process to generate a typology

associated to a given specific meta-model from the

generic typology. We then illustrate it by specifying

a typology associated to the Map meta-model.

4.1 Description of the Generation

Process

The process that allows to generate a gap typology

associated to a specific meta-model, is composed of

six steps:

1. To choose the properties to reach, particularly the

minimality or the semantic wealth of the specific

typology. Indeed, the set of operators to

instantiate are not the same. To reach the

minimality, only the generic operators Give,

Withdraw, Add, Remove, AddComponent and

RemoveComponent are instantiated. To satisfy the

semantic wealth property all the operators of the

generic typology are instantiated in the third

steps.

2. To instantiate the generic meta-model. This step

aims to build the specific meta-model by

instantiation of the generic meta-model.

3. To instantiate the generic typology. This step uses

the generic typology to generate, by instantiation

a specific typology. According the choice made in

the first step, all operators or only those forming

the minimal set are instantiated for each concept

according to its generic type Link, NotLink,

Composed, Simple or Property.

4. To remove the non-sense operators. This step

allows to prune the operators that would not have

sense or would not be used in the context of the

specific meta-model.

5. To formally define the operators. This step relies

on the formal definition of the generic operators

and on the knowledge of the specific model in

order to formally define each specific operator.

Source IntentionSource Intention

h.p.t

h.p.s

Strategy

Stop

Start

Target Intention

Thread

Bundle

Path

1..*0..*0..*

0..* 1

Intention

Map

0..*

0..1

0..*

Section

Business rules

Refinement

0..*

has

Simple

Composed

Link

Property

Root

Caption

Post-condition

Pre-condition

Figure 4: Instantiation of the generic meta-model for the Map meta-model.

A META-MODELLING APPROACH TO EXPRESS CHANGE REQUIREMENTS

291

To verify the different properties. This last step

corresponds to the evaluation of the properties

previously identified. During this step, the specific

typology can be modified in order to satisfy the

different properties.

4.2 llustration of the Generation

Process

The Map meta-model (Rolland, 1999) used in

ACEM provides an intentional representation of the

system and the business processes. A map is a

labelled directed graph from Start to Stop with

intentions as nodes and strategies as edges. A map is

composed of several sections; one section being an

aggregation of two intentions linked through a

strategy (cf. Figure 4).

We chose to construct a semantically rich

typology in order to better express the change

requirements. For sake of space, we do not detail

each of the six steps; we give the intermediary

important results.

4.2.1 Instantiation of the Generic

Meta-model

Figure 4 shows the instantiation of the generic meta-

model for the Map meta-model.

An intention is a NotLink element corresponding

to a goal that can be achieved by the performance of

a process.

A strategy is a manner or a means to achieve an

intention. In Figure 4, a Strategy is shown as a Link

element. As a link, a strategy has a source which is

the Source Intention and a target which is the Target

Intention.

A section is an aggregation of the source

intention, the target intention, and a strategy. A

section is thus a composed element. Furthermore, a

section can be seen as the transition from an initial

situation obtained by the realization of the source

intention towards a final situation resulting from the

enactment of the target intention by application to

business rules linked to the section. These aspects

are specified by three Properties associated to the

section element: the pre-condition (characterising

the initial state), the post-condition (reflecting the

final state) and the business rule.

Sections are connected one another according to

three different links: a path (establishing a

precedence/succedence relationship), a thread

(specifying that sections between a pair of intentions

are alternative) or a bundle (when sections between

a pair of intentions are mutually exclusive). These

three elements are of type Link.

Finally, let us mention that it is possible to refine

a section of a map at level i into an entire map at a

lower level i+1 to view an intention together with its

strategy as a complex graph of intentions and their

associated strategies. Refinement as defined here is

an abstraction mechanism by which a complex

assembly of sections at level i+1 is viewed as a

unique section at level i. The refinement is a Link

element.

4.2.2 Instantiation of the Generic Typology

The instantiation of the fourteen generic operators

(Table 2) for the specific elements of the Map meta-

model allows to obtain a table with eight columns

corresponding to the number of elements in the Map

meta-model (intention, strategy, section, map,

refinement, path, bundle and thread).

The nature of the elements (Link, NotLink, Simple,

Composed) helps in reducing the number of specific

operators in the typology. For example, the operator

ChangeOrigin can only be instantiate for the

elements strategy, refinement, path, bundle, thread,

relationship and alignment relationship that are Link

elements.

Some operators have been removed from the

typology insofar as they have no sense (step 4), as

for example AddComponentSection or

RemoveComponentSection. Indeed, the structure of a

section is immutable: a source intention, a target

intention and a strategy.

Operator Intention Strategy Section Map pivot Refinement

Rename

RenameIntention RenameStrategy N/A RenameMap

N/A

Add

AddIntention AddStrategy N/A AddMap AddRefinement

Remove

RemoveIntention RemoveStrategy N/A RemoveMap RemoveRefinement

Merge

MergeIntention MergeStrategy MergeSection MergeMap N/A

Split

SplitIntention SplitStrategy SplitSection SplitMap N/A

Replace

ReplaceIntention ReplaceStrategy ReplaceSection ReplaceMap N/A

Change

N/A ChangeSourceIntention

Origine

(Non Applicable) ChangeTargetIntention

Retype

RetypeIntention RetypeStrategy N/A N/A N/A

N/A. N/A. N/A.

Table 2: Extract of the t

olo

associated to the Ma

meta-model.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

292

Finally some operators are removed in order to

satisfy the chosen properties (step 6). Thus, for

example, a typology containing the operators

AddSection and AddSectionMap is not consistent

since these operators have the same formal

definition. Table 2 shows an extract of the obtained

table at the end of the generation process.

This approach has been used in different industrial

projects as for example with DIAC, the financial

branch of the French constructor Renault. We

developed a typology for the Map meta-model. The

evolution based on gap elicitation allows to

construct the To-Be model by focussing on change

without defining again what remain unchanged.

5 CONCLUSION

System adaptation is done under intense time

pressure: the new system must be put in place

yesterday. Therefore, it is not possible to develop a

To-Be model from scratch, given the time and

resources involved. A workable strategy under these

circumstances is to use and modify what is available,

and add the remaining. This is the thrust of the gap

drive proposed in this paper.

In this paper, we have proposed an approach to

identify operators expressing change requirements.

This approach relies on the existence of a generic

meta-model and a generic typology.

The process that we have defined in this paper

allows to systematically generate a specific typology

satisfying the properties of completeness,

correctness, consistency and semantic wealth. From

this way: (1) any change can be expressed by the set

of the typology operators; (2) the application of each

operator let the system in a coherent state without

introducing new errors; (3) the operators definitions

are clear and non ambiguous and (4) each type of

change can be expressed by using only one operator.

Furthermore, there are some advantages of

proceeding following the proposed approach: (i) the

generic typology serves as a guide to define the

specific typology: the latter is just an instance of the

former and (ii) specific typologies are consistent

with each other as they are generated from the same

mould: this is important when several typologies are

used in the same method.

The illustration of this process to define a

specific typology associated to the Map meta-model

has shown its relative simplicity and its systematic

aspect. We have use this process in (Rolland, 2004)

to define a specific typology associated to the

intentional Map meta-model and in (Etien, 2003),

we generated typologies respectively associated to

WIDE (Casati, 1996) and ORION (Banerjee, 1987).

REFERENCES

Al-Jadir L. 2003 “Once Upon a Time a DTD Evolved into

Another DTD” Object Oriented Information Systems,

Lecture Notes in Computer Science, Vol.2817,

pp.226-237, 2003.

Banerjee, J., Kim, W., Kim, H.-J., Korth, H. F, 1987.:

Semantics and Implementation of Schema Evolution

in Object Oriented Databases In Proc. of the ACM-

SIGMOD Annual Conference, pages 311--322, San

Francisco, CA, May 1987.

Bezivin J., 2001 From Object Composition to Model

Transformation with the MDA, Proceedings of

TOOLS, USA, Santa Barbara, August

Casati F., Ceri S., Pernici B., Pozzi G., 1996 Workflow

Evolution. In Proc. of 15th Int. Conf. On Conceptual

Modeling (ER'96), Cottbus, Germany, pp. 438-455

Estublier J. and Nacer M. Schema Evolution in Software

Engineering Databases -- A new Approach in Adele

environment CAI Computer and Artificial Intelligence

Journal. June 2000. Vol 19. pp. 183-203.

Etien, A, 2006 Ingénierie de l’alignement : Concepts,

Modèles et Processus Thèse de Doctorat, Université de

Paris I, Mars

Etien, A., Salinesi, C, 2003. Towards a Systematic

Definition of Requirements for Software Evolution: A

Case-study Driven Investigation. Proc of

EMMSAD’03 Velden, Austria.

Information Technology-Information Resource Dictionary

System (IRDS) , 1990 – Framework, ISO/IEC

International Standard.

Kradolfer M. , 2000 A Workflow Metamodel Supporting

Dynamic, Reuse-based Model Evolution. PhD thesis,

Department of Information Technology, University of

Zurich, Switzerland, chap. 4, pp. 59-73

Marttiin, P., 1994, Methodology Engineering in CASE

shells: Design Issue and Current Practice, PhD thesis,

Computer science and information systems reports,

Technical report TR-4

Prakash, N. , 1999 On Method Statics and Dynamics.

Information Systems 24(8), pp. 613-637.

C. Rolland, C. Salinesi, A. Etien, 2004, “Eliciting Gaps in

Requirements Change”. Requirement Engineering

Journal Vol. 9, N°1, pp1-15

Rolland, C., Prakash, N., Benjamen, A, 1999.A Multi-

Model View of process Modelling, Requirements

Engineering Journal, 4 : 169-187

Soffer P, Wand Y 2004 Goal-Driven Analysis of Process

Model Validity. Proceedings of CAiSE’04, Riga,

Latvia.

Teeuw W. B., van den Berg H. 1997, On the Quality of

Conceptual Models, Proceedings of the 16th

International Conference on Conceptual Modeling

(ER'97), Los Angeles, CA, November 1997

Terrasse M-N, Savonnet M., Becker G., Leclercq E., 2003

"UML-based Metamodeling for Information System

Engineering and Evolution", Proceedings of OOIS'03,

LNCS 2817, Springer Verlag, pp. 83-94

A META-MODELLING APPROACH TO EXPRESS CHANGE REQUIREMENTS

293