Charlotte Hug
email: charlotte.hug@imag.fr

Agnès Front

Dominique Rieu

Brian Henderson-Sellers

A method to build information systems engineering process metamodels

Keywords: information systems engineering, method engineering, process metamodel, method, pattern

Several process metamodels exist. Each of them presents a different viewpoint of the same information systems engineering process. However, there are no existing correspondences between them. We propose a method to build unified, fitted and multi-viewpoint process metamodels for information systems engineering. Our method is based on a process domain metamodel that contains the main concepts of information systems engineering process field. This process domain metamodel helps selecting the needed metamodel concepts for a particular situational context. Our method is also based on patterns to refine the process metamodel. The process metamodel can then be instantiated according to the organisation's needs. The resulting method is represented as a pattern system.

Introduction

Many information systems engineering method definitions exist. According to Harmsen [START_REF] Harmsen | Situational Method Engineering for Information Systems Projects[END_REF]) "an Information Systems Engineering Method is an integrated collection of procedures, techniques, product descriptions, and tools, for effective, efficient, and consistent support of the IS engineering process" where, according to Booch [START_REF] Booch | Object Oriented Analysis and Design with Application[END_REF], a method is "a rigorous process to generate a set of models describing various aspects of software being built using some well-defined notation". Integration and rigour can best be appropriated by the use of a metamodel that defines the modelling language (to describe the work products) together with a metamodel describing process and producer elements and integrating with the modelling language (e.g. ISO/IEC, 2007). The former metamodel is used to ensure the correctness of the work product models and diagrams whilst the latter metamodel is used to underpin the process model (a.k.a. methodology). Process models offer approaches for developing information systems in a well-disciplined manner. Here, we will consider process modelling in the context of information systems engineering. An information systems engineering process is a complex endeavour. [START_REF] Cauvet | Modélisation des processus d'ingénierie des Systèmes d'Information[END_REF] presents the various arguments for the modelling of an engineering process. It is argued that the process must be modelled in order to depict its various stages, as well as to guide the different actors involved throughout the life cycle. The modelling of a process may also allow the subsequent monitoring of its progress in real time, that is to say its implementation, often called its enactment. Finally, the model allows the recording of what has been done, for reusing the most generic parts or for monitoring and improving the process. Organisations wishing to model their process -as accurately as possible and at all stages of the engineering life cycle -are faced with various problems. For example, the organisationally-agreed process model or methodology should be a good fit to the organisational maturity, skills level etc. [START_REF] Henderson-Sellers | Un outil d'aide à l'ingénierie de méthodes reposant sur l'approche OPEN[END_REF]. Creating such a methodology is the focus of situational method engineering (SME) [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF]. The definition of a process model as might be created using SME should be headed by concepts, rules and relationships; a process metamodel is therefore necessary for instantiating process models. Indeed, the need for industry adoption of metamodels for solving business problems, perhaps using a model-driven engineering (MDE) approach has been recently urged by Forrest [START_REF] Forrest | Business Process Oriented Requirements Modelling and Systems Fulfilment -a Meta Model Driven Approach[END_REF] based on his first-hand industry involvement. Many different process metamodels exist ( [START_REF] Harel | Statecharts: A Visual Formulation for Complex Systems[END_REF], [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF], (OPF, 2005), [START_REF] Potts | Recording the Reasons for Design Decisions[END_REF], [START_REF] Rolland | An Approach for defining ways-of-working[END_REF], and [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] among others); while there are others, such as (AS, 2004), (OOSPICE, 2002) that include process issues as part of an all-embracing software development methodology. Each of them defines different concepts: - [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF], (OPF, 2005) deal with the concepts of work unit, work definition and roles, - [START_REF] Harel | Statecharts: A Visual Formulation for Complex Systems[END_REF] comprises the concepts of product, state and transition, dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 2 - [START_REF] Potts | Recording the Reasons for Design Decisions[END_REF] includes the concepts of issue, alternative and argument, - [START_REF] Rolland | An Approach for defining ways-of-working[END_REF] deals with the concepts of situation and intention, - [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] include the concepts of intention and strategy.

Each of these different process metamodels represents a different viewpoint of the information systems engineering process. A viewpoint is a process perspective; it is not necessarily associated with a particular actor or role. [START_REF] Dowson | Iteration in the software process, Review of the 3rd International Software Process Workshop[END_REF], [START_REF] Mi | A meta-model for formulating knowledge-based models of software development[END_REF] and [START_REF] Rolland | A comprehensive view of process engineering[END_REF] define the different process metamodel categories, which we consider here as viewpoints. Based on this categorization, we can say that, overall, [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF] and (OPF, 2005) are activity-oriented process metamodels, [START_REF] Harel | Statecharts: A Visual Formulation for Complex Systems[END_REF]) is a product-oriented process metamodel, [START_REF] Potts | Recording the Reasons for Design Decisions[END_REF]) is decision-oriented, [START_REF] Rolland | An Approach for defining ways-of-working[END_REF] is context-oriented and [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] is strategy-oriented. There is obviously a link between these different process metamodels since they represent the same conceptualization but from a different viewpoint. However, these links have never been explicitly defined -a focus of our paper. The correspondences between the different viewpoints should be explicit in order to provide a complete vision of the information systems engineering process. Nowadays, to define a multi-viewpoint information systems engineering process, different process metamodels of the needed viewpoints have to be used, effectively independently, and instantiated since no formalized links exist to show the correspondences between the viewpoints. Furthermore, some of the existing process metamodels are so large that they can be difficult to understand. Large metamodels thus tend to be only partially used by most process/method engineers. Hence, existing CAME tools based on big metamodels may waste resources. For very many individual projects, one of these predefined metamodels will be an appropriate fit to the organizational requirements. Indeed, this is the reason that standards, such as those of ISO, exist. However, in many other instances, method engineers need to combine concepts from two or more metamodels i.e. they need: -Multi-viewpoints and unified process metamodels, -Metamodels fitted to the organisation or project specificities. [START_REF] Karagiannis | Metamodelling platforms, in E-Commerce and Web Technologies[END_REF] advocate the introduction of flexibility into metamodels. Consequently, in this paper, we propose a method that supports the building of fitted, multi-viewpoint and unified process metamodels in order to support the real-life situations when a predetermined, standardized metamodel is inadequate. To parallel SME but at a higher abstraction level, we name this approach as Situational MetaModel Engineering (SMME). This method is based on a process domain metamodel that contains the main concepts of the different existing process metamodels such as work unit, role, strategy etc. The first phase of the method consists of selecting the needed concepts from the process domain metamodel. A draft process metamodel containing the main concepts of the required process metamodel is produced. The draft process metamodel is then refined and extended in the second phase of the method, mainly using patterns. The method is represented thanks to a pattern system. The paper is organized as follow. Section 2 presents the different existing process metamodels, a brief synthesis and the main problems encountered. Section 3 describes the phases of the proposed method, selection and refinement, and the resources used: the process domain metamodel and the patterns. Section 4 presents the pattern formalism and the pattern system and Section 5 describes an example. Section 6 discusses the related works and Section 7 concludes this paper.

Existing process metamodels

In this section, we present the different existing process metamodels classified according to the different process viewpoints: activity, product, decision, context and strategy.

Activity-oriented process metamodels

Activity-oriented process metamodels allow building models concentrating on the activities and tasks performed in producing a product together with their ordering [START_REF] Rolland | A comprehensive view of process engineering[END_REF]. They typically comprise the concepts of Work Unit or Work Definition that have Products as inputs and outputs and are performed by a Role. SPEM [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF], The Open Process Framework (OPF, 2005), OOSPICE (OOSPICE, 2002), SMSDM (AS, 2004) andISO 24744 (ISO, 2007) are process metamodels, mainly activity-oriented. Some of them, such as SPEM and ISO 24744, include other viewpoints such as product varying degrees of detail. The process models of methods such as RUP [START_REF] Kruchten | The Rational Unified Process: An Introduction[END_REF], XP [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF] and SCRUM [START_REF] Schwaber | Agile Software Development with SCRUM[END_REF] are instances of activity-oriented process metamodels and thus are activity-oriented process models. dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 Figure 1 presents an extract of SPEM metamodel [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF]. A WorkDefinition can be an Activity, a Phase, an Iteration or a Lifecycle (the last two not shown). WorkDefinition describes the work performed in the Process. A ProcessRole defines responsibilities over specific WorkProducts, and defines the roles that perform and assist in specific activities. ProcessRole is the subclass of ProcessPerformer (not shown in Figure 1). A ProcessPerformer defines a performer for a set of WorkDefinitions in a process [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF]. The ActivityParameter meta-class allows the specification of the inputs and outputs (WorkProduct) of a WorkDefinition.

Figure 1. The activity-oriented process metamodel SPEM.

Product-oriented process metamodels

Product-oriented process metamodels permit the instantiation of models that couple the product state to the activities that generate this state [START_REF] Rolland | A comprehensive view of process engineering[END_REF]. They present the concepts of Product that have different States and transitions defined between the states. The product state represents the situation of a product at a precise moment of the process, the transitions being defined between these states to represent the order in which the states can change. The transitions are relations between a source state and a target state; they are triggered by an event.

The metamodel for Statecharts [START_REF] Harel | Statecharts: A Visual Formulation for Complex Systems[END_REF], State Machines [START_REF] Omg | Unified Modeling Language: Superstructure[END_REF], as well as the metamodel of the Entity Process Model (EPM) [START_REF] Humphrey | Software Process Modeling: Principles of Entity Process Models[END_REF] and the State-Transition template [START_REF] Finkelstein | ViewPoint oriented software development[END_REF], are examples of product-oriented process metamodels that use the above concepts. Figure 2 shows the simplified product-oriented process metamodel of the State-Transition approach [START_REF] Finkelstein | ViewPoint oriented software development[END_REF] as an example of this class of process metamodels. One or more States composed a Product, while Transitions are defined between the States.

Decision-oriented process metamodels

Decision-oriented process metamodels allow building models that present the successive transformations of a product due to decisions [START_REF] Rolland | A comprehensive view of process engineering[END_REF]. They count the concepts of Issues that need answers defined as Alternatives. Alternatives can be supported or objected by Arguments. An issue is a problem met during the information systems process engineering. Alternatives are different options to sole the issue. [START_REF] Kunz | Issues as elements of information systems[END_REF] first introduced the notion of decision-oriented process. It was then improved by [START_REF] Potts | Recording the Reasons for Design Decisions[END_REF], Potts [START_REF] Potts | A generic model for representing design methods[END_REF] and in the DAIDA project [START_REF] Jarke | DAIDA: An Environment for Evolving Information Systems[END_REF]. Figure 3 presents the decision-oriented process metamodel defined in [START_REF] Potts | A generic model for representing design methods[END_REF]. Steps during information systems engineering can raise Issues. Alternatives respond to Issues and are supported or objected by Arguments, citing Artefacts. Alternatives can contribute to Steps. An Issue can review an Artefact that can be modified by a Step.

Context-oriented process metamodels

Context-oriented process metamodels allow building models representing the situation and the intention of an actor at a given moment of the project [START_REF] Rolland | A comprehensive view of process engineering[END_REF]. The couple of Situation plus Intention forms a Context. The key concepts of this kind of metamodel are the Context that is composed of a Situation and an Intention. The situation is a part of a product under design that is the object of a decision. The intention represents the objective, i.e. the goal that an actor wants to achieve according to the situation [START_REF] Plihon | Un environnement pour l'ingénierie des méthodes[END_REF]. The notion of context was first defined in [START_REF] Grosz | Using Artificial Intelligence Techniques to Formalize the Information System Design Process[END_REF] and finalized within the context-oriented process metamodel NATURE [START_REF] Rolland | An Approach for defining ways-of-working[END_REF], in a European project of the same name. [START_REF] Rolland | A decision-making pattern for guiding the enterprise knowledge development process[END_REF] adapted the NATURE metamodel to Enterprise Knowledge Management. The concept of intention had replaced the concept of decision, which has also been done in the NATURE metamodel. It is also worth noting that Situation and Intention are the main concepts of Situational Method Engineering, as defined in [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF], as SME consist of building methods "on the fly" according to the method defined at a precise moment (Situation) and what method engineers need to add in the method (Intention). Figure 4 shows an extract of the NATURE context-oriented process metamodel [START_REF] Rolland | An Approach for defining ways-of-working[END_REF]. A Context is composed of a Situation (in respect to a product) and an Intention (an objective in respect to the product).

Strategy-oriented process metamodels

Strategy-oriented process metamodels allow building models representing multi-approach processes and plan different possible ways to elaborate the product based on the notion of intention and strategy [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF]. Strategy and Intention are the main concepts of this kind of metamodels. An intention is a goal, an objective to achieve. A strategy is a manner to achieve the intention [START_REF] Zoukar | MIBE : Méthode d'Ingénierie des Besoins pour l'implantation d'un progiciel de gestion intégré (ERP)[END_REF]. [As far as we know, MAP [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] is the only strategy-oriented process metamodel published to date, although a goalfocussed SME approach for process model construction is described in (Gonzalez-Perez et al., 2008) and the work product pool approach of (Gonzalez-Perez and [START_REF] Gonzalez-Perez | Methodology enactment using a work product pool approach[END_REF] is also loosely related in that context.] The process model of the requirement engineering method "CREW-l'Écritoire" [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] has been formalised using MAP. MAP has also been used to represent an engineering method for matching ERP functionalities and organisational requirements [START_REF] Zoukar | Using goal/strategy/maps to reduce the language disparity issue in ERP projects[END_REF]. Figure 5 presents the simplified strategy-oriented process metamodel for the MAP approach. A Section is composed of a Strategy, a Source Intention and a Target Intention. A MAP is composed of one or more Sections. It always has a Start Intention and a Stop Intention.

Figure 5. Extract of the strategy-oriented process metamodel MAP.

Synthesis

Table 1 synthesizes the concepts of the most representative process metamodels. We do not present all the concepts of every process metamodel but only the more significant. [In [START_REF] Henderson-Sellers | A comparison of four process metamodels and the creation of a new generic standard[END_REF], a similar but more limited comparison was done between the activity-oriented process metamodels of the dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 6 SMSDM, SPEM, OOSPICE, OPF and LiveNet. Table 1 includes two activity oriented process metamodels, SPEM and OPF, but also product oriented process metamodels, decision, context and strategy oriented process metamodels.] It can be seen that some concepts are common to various process metamodels, for example WorkDefinition, but these are frequently not at the same granularity level, e.g. WorkDefinition and WorkUnit are very general terms whereas Step and Action are very concrete. Almost all the process metamodels deal with the concept of Product, but only the State-Transition metamodel (and all the product-oriented process metamodels) focuses on States. In contrast, the concepts of Issue, Alternative and Argument are only defined in decision-oriented process metamodels. Some concepts, such as Precondition and Goal, seem very similar to Situation and Intention or Source Intention and Target Intention as they all correspond to the state of the process before or after an action, respectively; although they would appear to be located at different levels of abstraction. Pre-condition and Goal (a.k.a. Postcondition) are concrete, while Situation and Intention are more abstract. The first problem met is the mere existence of existing process metamodels, whatever the viewpoint. How can a method engineer, easily and quickly, choose the process metamodel corresponding to the organisation's needs? There is no existing framework to guide the method engineer through the selection of the most appropriate process metamodel. There are only frameworks that guide them in the selection of concepts from the framework process metamodel (OPF, 2005) for the OPF, Eclipse Process Framework (EPF, 2006) for SPEM and Xome [START_REF] Gonzalez-Perez | Tools for an Extended Object Modelling Environment[END_REF] for the SMSDM and a subset of OOSPICE. Therefore, there is a separate framework for each one process metamodel. Moreover, there is only a partial consensus on the vocabulary used in the different process metamodels. [START_REF] Henderson-Sellers | A comparison of four process metamodels and the creation of a new generic standard[END_REF] have presented a synthesis of the different concepts used in activity-oriented process metamodels and their correspondence. This comparison shows that the same word can be used to represent different concepts from one metamodel to another. For example, an "Activity" in SPEM does not correspond to an "Activity": in OPF. These differences can easily lead to difficulty in understanding the different process metamodels for method engineers, who need operational and comprehensible process metamodels quickly. Furthermore, the vocabulary and concepts used are different from one organisation to another, because of the enterprise culture, knowledge and practices collected over the years. However, existing process metamodels are not adaptable to the organisation's vocabulary. When using a process metamodel, why should the organisation not use its own vocabulary and concepts instead of being forced to use the existing process metamodel terms?

The existing process metamodels only propose one viewpoint and there are no correspondences between the concepts of process metamodels of different viewpoints. If the method engineer needs to represent many viewpoints, he/she can only use each metamodel by itself, and does not have the correspondences between their concepts.

Finally, the majority of the process metamodels do not propose extension or adaptation mechanism except SPEM [START_REF] Omg | Software Process Engineering Metamodel Specification[END_REF] and ISO 24744 (Henderson-Sellers and Gonzalez-Perez, 2006b). The method engineers cannot adapt the process metamodels needed to the organisational requirements. The objective of this paper is to allow method engineers to create: -Unified, -Multi-viewpoint, -Fitted process metamodels.

The term "unified process metamodel" means that all the concepts that the method engineers need to specify are grouped in only one metamodel, whatever the viewpoints they specify. If the process metamodels are unified, they are multi-viewpoint. All the viewpoints could be represented in the same process metamodel. process metamodels will be fitted to the organisational requirements. The method engineers will specify the vocabulary they want to use, the concepts and the associations between these concepts.

To do this, we propose that method engineers build themselves the process metamodel(s) that the organisation needs, following a two-phase method as described in the next section.

The method

In this section, we present the two phases of our method [START_REF] Hug | A Process Engineering Method Based on Ontology and Patterns[END_REF] and the resources made available to method engineers. The first phase, selection, consists of choosing the main required concepts from the process domain metamodel provided. The second phase, refinement, allows method engineers to refine, complete and extend the draft process metamodel obtained in the first phase, by applying metamodelling patterns and business patterns.

The process domain metamodel

The process domain metamodel, visualized in Figure 6, comprises the main concepts from the existing process metamodels of different viewpoints.

The concept WorkUnit is the main concept of an activity-oriented process metamodel. A WorkUnit can own Conditions and can be carried out by a Role. WorkProduct comes from a product-oriented process metamodel; however, we do not propose the concepts of State and Transition in the process domain metamodel because they are too detailed at this stage: these concepts are additional detail to the basic concept of WorkProduct. The concepts of Issue, Alternative and Argument come from the decision-oriented process metamodels. Based on the comparisons made in Table 1, we have easily linked these concepts to WorkUnit and WorkProduct. Context, Intention and Situation come from context-oriented process metamodels. The concept of Intention is linked to the Strategy concept, which comes from strategy-oriented process metamodels.

Figure 6. The process domain metamodel.

Furthermore, we introduce two levels of abstraction. These levels of abstraction are not linked to the abstraction levels of the OMG but correspond to a more or less concrete way by which to view the process. The intentional abstraction level represents the goals and objectives of an ISE process, while the operational abstraction level represents the actions needed to concretize these objectives. These levels are useful if ISE processes are defined in two steps: in the first step, the main objectives are defined, and in the second step, the objectives are detailed and described with operational terms. The levels can also be useful if two different kinds of actors participate in the ISE process since any stakeholders of the business field tend to think in terms of goals of the organisation whilst information systems providers think in terms of actions. The abstraction levels are represented in the process domain metamodel as valued attributes that can be either intentional or operational. Figure 7 represents the concepts of the process domain metamodel placed according to their viewpoint and abstraction level.

Figure 7. Concepts, viewpoints and abstractions levels.

The selection phase

During the selection phase, the method engineer completes a questionnaire (Table 2) -similarly to the approach of [START_REF] Henderson-Sellers | Un outil d'aide à l'ingénierie de méthodes reposant sur l'approche OPEN[END_REF] in selecting method fragments to build the process model. The answers to the questionnaire will help to determine which concepts are included in the draft process metamodel and which excluded. For example, if the method engineer answers "yes" to the first question, the draft process metamodel will include the Intention concept. Each question of the questionnaire corresponds to a concept of the process domain metamodel.

Condition

When the method engineers have answered all the questions, they obtain a draft process metamodel. Each time a concept is integrated in the draft process metamodel, the existing associations of the process domain metamodel are imported. If the method engineer chooses the concept of WorkUnit and then of WorkProduct; the associations "in" and "out" would be automatically imported into the draft metamodel. Moreover, some concepts of the process domain metamodel cannot be separated from other concepts i.e. there is an existence dependency between two elements in the process metamodel. Table 3 presents the depender concepts and their dependee concepts. For example, an alternative cannot exist without an issue, but an issue can exist without an alternative. Some concepts compulsorily depend on more than one concept: a context cannot exist without a situation and an intention. Other concepts depend on at least one concept; for example, a role can depend on a work unit, an alternative or a work product. The cardinalities in the process domain model partly represent these constraints. When the method engineer chooses a dependee concept, the depender concept is automatically added into the draft process metamodel, in order to ensure that this constraint is met. In order to facilitate the selection of concepts, the method proposes associated concepts to the method engineer when selecting one concept. For example, when the method engineer chooses the WorkUnit concept, the method will propose him/her the concepts of WorkProduct, Role, Condition, Issue, Alternative and Strategy. This allows the selection phase to be less irksome, notably answering all the questions of the questionnaire. Figure 8 represents the described above process followed during the selection phase. It is represented as a MAP, using the MAP formalism of [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF]. Nodes represent Intentions and edges represent Strategies. A MAP always begins with the "Start" Intention and Stops with the "stop" Intention. Each intention of the MAP corresponds to a step of the selection phase. The first strategy ("Yes answer") is the only way to integrate a concept in the draft process metamodel. The "Dependee strategy" has to be selected if there is a dependee concept; if not the "Associated concept strategy" or "Association strategy" can be selected. The "Associated concept strategy" permits integrating the concepts that are linked with the previously selected concepts while the "Association strategy" allows integrating the associations between the concepts in the draft process metamodel. The "Improvement strategy" will allow method engineers to improve their draft process metamodels. The "Completion strategy" is used when the draft process metamodel is complete. The strategies between the intentions show that not every step is necessary, for example, "Integrate dependee concepts" and "Integrate associated concepts".

The patterns

In this subsection, we present the resources used in the second phase of the method. These resources are patterns of two types: metamodelling patterns and business patterns.

Metamodelling patterns

A metamodelling pattern has the same purpose as a design pattern, in the sense that a design pattern describes a frequently occurring problem in a context and a general repeatable solution to resolve it [START_REF] Alexander | The Timeless Way of Building[END_REF]. We seek the same characteristics, but as a contribution to metamodelling rather than design [START_REF] Karagiannis | Metamodelling platforms, in E-Commerce and Web Technologies[END_REF]. Many design patterns already exist, such as the Object-Oriented Patterns of Coad [START_REF] Coad | Object-Oriented Patterns[END_REF], the GoF Design Patterns [START_REF] Gamma | Design patterns -Elements of reusable object-oriented software[END_REF] etc. These patterns are intended to be reused at the modelling level. Here, we seek analogous patterns that can be used at the metamodelling level. We begin by studying the published design patterns to determine if they can be reused in some way at the metamodelling level. Then, they will need to be adapted to metamodelling. Some metamodelling patterns have already been defined. The MP workshop of the French-speaking conference IDM aims to define a metamodelling patterns catalogue [START_REF] Mp | Bonnes pratiques de métamodélisation et patrons pour la méta-modélisation[END_REF] although it should be noted that these patterns do not concern process metamodelling. The Powertype [START_REF] Odell | Power Types[END_REF] can be used as a metamodelling pattern. This pattern allows the instantiation of metaclasses into objects that also inherit properties of another metaclass. (Gonzalez-Perez and Henderson-Sellers, 2006b)'s approach is based on the Powertype pattern to build a process meta-model for software development methodologies. The Powertype is therefore fitted for metamodelling. [START_REF] Hug | Ingénierie des processus: une approche à base de patrons[END_REF] present a metamodelling pattern, the purpose of which is similar to the Powertype pattern. The "Concept-Concept Category" pattern allows the categorization of specific concepts and the instantiation of properties at two modelling levels. This pattern is based on the "Item-Description" pattern [START_REF] Coad | Object-Oriented Patterns[END_REF] and on the Deep Instantiation idea of [START_REF] Atkinson | The Essence of Multilevel Metamodeling[END_REF]. It is thus an adaptation of the "Item-Description" pattern to metamodelling. Figure 9 presents the "Concept-Concept Category" metamodelling pattern. The superscript "2" on the attribute name represents the potency of the Deep Instantiation to indicate that the attribute or association will be instantiated at the second modelling level.

Business patterns

Business patterns represent process metamodel fragments. Process metamodel fragments are part of existing process metamodels that method engineers can reuse in order to detail one or more concepts of the process metamodel developing secondary concepts. They are generic specifications to create solutions suitable for a given application problem in the field, here information systems engineering processes metamodelling. For example, we may consider Figure 2 as a process metamodel fragment called "State-transition" business pattern. The major concept of this fragment is Product (equivalent to WorkProduct) of which the process metamodel domain is comprised. If the method engineer wants to develop the product-oriented viewpoint of their process metamodel, they can reuse the "State-transition" business pattern. The State and Transition concepts will be integrated in their draft process metamodel, as well as the associations between the concepts Product, State and Transition. Any process metamodels presented in Section 2 can be regarded as a business pattern. During the refinement phase, the method engineer selects the concepts they need to enrich in order to meet the organisational requirements. For each concept, they can choose to reuse an existing metamodelling pattern or a business pattern. They can choose a pattern based on the problem it resolves, to its adequacy or the frequency of its use: -The problem the pattern resolves is one of the items describing it. The paper describes later the pattern formalism used.

-The adequacy corresponds to a subjective measure that the method engineers give for reusing a pattern for a particular concept. This measure is given when the process metamodels have been regularly used.

-The frequency of use is a statistical measure that calculates the ratio of the number of times a pattern P i has been used for a concept C j divided by the number of times any pattern has been used for the concept C j . The measure is represented in Equation 1.

∑ ) , ( ) , ( j i j i C P R C P R
Equation 1. The frequency of use measure. The process followed by the method engineer in the refinement phase is presented in Figure 11 as a MAP. The method engineers select the concept they want to enrich; they can reuse a pattern or create a new pattern that will be validated later by experts so that it could be use by other method engineers. The method engineers restart the process as many times as necessary.

The method representation

In order to represent metamodelling patterns and business patterns homogeneously, we also choose to represent the method phases as process patterns. We use the P-Sigma formalism [START_REF] Conte | A Tool and a Formalism to Design and Apply Patterns, OOIS[END_REF] to represent all the patterns. These patterns form a pattern system. 4.1. The P-Sigma formalism P-Sigma is a formalism that allows the standardization of product and process representation. This formalism was introduced because of the increasing number of patterns libraries offering product or process patterns whose range and coverage are diversified (analysis, design or implementation patterns, general, domain or enterprise patterns). Such libraries, although complementary, are difficult to combine during application development. This is mainly because no common formalism for patterns representation exists. P-Sigma thus offers a way of expressing a semantics that is common to the majority of formalisms proposed in the literature, in order to make a uniform expression of product patterns and process patterns, to make explicit the pattern selection interface and to allow a better organization of patterns libraries [START_REF] Conte | A Tool and a Formalism to Design and Apply Patterns, OOIS[END_REF]. In other words, the representation of the metamodelling patterns, business patterns and process patterns of the method is homogenous, which will ease their comprehension and selection. The P-Sigma formalism is composed of three parts that comprise many items (cf.

Context

Describes the pre-condition of pattern application.

Problem

Defines the problem solved by the pattern.

Force

Defines the pattern contributions through a collection of quality criteria associated to a technology.

Pattern realization Process Solution

Indicates the problem solution in terms of a process to follow. An activity diagram allows representing the process.

Model Solution

Describes the solution in terms of expected products (a class diagram and optionally a set of sequence diagram).

Application Case

Describes application examples of the Model Solution. This item is optional, but recommended in order to facilitate the understanding of the pattern solution. Consequence Gives the consequence induced by the pattern application.

Patterns Relations

Uses, Refines, Requires, Alternative

The pattern interface part comprises the items that help the selection of patterns. The pattern realization part gives the model solution or the process solution. The relation part describes the relationship with other patterns. Not all the items can be filled for every pattern, particularly process solution and model solution.

The pattern system

The pattern system comprises: -Process patterns, to represent the method phases, -Metamodelling patterns, to represent design patterns for metamodelling, -And business patterns, to represent process metamodel fragments. All these patterns are represented in the P-Sigma formalism. We also use a tool, AGAP [START_REF] Conte | A Tool and a Formalism to Design and Apply Patterns, OOIS[END_REF], a development environment that allows building and managing pattern formalisms and pattern systems. All the patterns of our method are stored in the AGAP pattern system. Table 5 presents the process pattern corresponding to the selection phase of the method, using the P-Sigma formalism.

Table 5. The Selection process pattern.

Identification Selection Classification {process ^ phase ^ metamodel} Context This pattern does not need any pattern to be reused.

Problem

Helps choosing the needed concepts of the process domain metamodel, importing the dependee and associated concepts in order to obtain a draft process metamodel Force Guides the process through different strategies in order to obtain a draft process metamodel. Process solution Insert Figure8.tif near here 1. The first step consists of answering a question of the questionnaire. 2. If the answer is "yes", the corresponding question concept is integrated in the draft process metamodel. 3. If the concept has a dependee concept, it is also integrated into the draft metamodel. 4. If there is any associated concept, the method engineers can choose whether or not to integrate them at that moment. 5. The associations between the concepts of the draft metamodel dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 are integrated from the process domain metamodel. 6. If the draft metamodel needs to be improved, the process restarts. 7. When the draft process metamodel comprises all the main concepts required, the process terminates.

Example

Let us present a situation met by a method engineer in a small business dedicated to information systems engineering. The development team is used to working with the eXtreme Programming method [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF], which is an activity-oriented approach. The team would like to add a strategy-oriented approach; consequently, the method engineer has to build a new process metamodel representing:

-The intentions of the project the strategies to achieve them.

-A life cycle composed of phases, themselves composed of activities. Activities are carried out by one or more roles and produce and/or use one product. The phases and the activities are linked with guards if necessary.

-The different product categories, such as text, diagram etc. As the method engineer already knows, more or less, what is needed, the selection phase is easily accomplished. The questionnaire (Table 2) guides him/her through the selection of the concepts that correspond to the organisation's requirements.

The following concepts are imported from the process domain metamodel into the draft process metamodel: Strategy and Intention, WorkUnit, Role and WorkProduct. The associations and the link of concretization are automatically imported into the draft process metamodel, see Figure 12.

Figure 12. The draft process metamodel obtained in the selection phase.

As the process domain metamodel only contains the core concepts of information systems engineering process, it is easy and fast to understand it. Using the questionnaire, the method engineers do not manipulate directly the process domain metamodel: that facilitates the selection. However, the draft process metamodel does not yet meet all the requirements since the following requirements cannot be represented:

-The sequence of strategies and intentions -Distinguishing a life cycle from a phase etc., -The composition of the phase and activities, -The sequence or work units with a guard, -Distinguishing a document from a program. The refinement phase allows the method engineer to complete the process metamodel to meet the missing requirements.

Firstly, to represent a sequence of strategies and intentions, the method engineer can reuse the MAP business pattern. This pattern is a fragment of the MAP process metamodel comprising the concepts of Strategy, Intention, Section and MAP, which allow the representation of a comprehensive sequence of strategies and intentions.

Then, to represent the composition and the sequence of work units, the method engineer can reuse the metamodelling patterns "Add a composition" and "Add a reflexive association" on the concept WorkUnit. The method engineer can add the guard to the reflexive association using the metamodelling pattern "Add an association class". To allow distinguishing, for example, a work product that is a document from a work product that is a program, the method engineer needs to reuse the pattern "Concept-Concept Category" on the WorkProduct concept. In the same way, to distinguish a work unit that is a phase from a work unit that is an activity, the pattern "Concept-Concept Category" has to be reused on the WorkUnit concept.

The composition of work unit categories must also be modelled, to specify that activities compose a phase.

To distinguish a role that carries out an activity from a role that only assists this activity, the method engineer adds the association "assists" between the concepts of Role and WorkUnit. As all the associations will be instantiated at the process execution level, the method engineer needs to specify it in the process meta-model. By applying deep instantiation [START_REF] Atkinson | The Essence of Multilevel Metamodeling[END_REF] on every association, the method engineer states the association will be instantiated into links at the process execution level and not at the process model level2 . The superscripts "2" represent the deep instantiation.

The final process metamodel is obtained at the end of the refinement phase (see Figure 13).

Figure 13. The final process metamodel obtained in the refinement phase.

The use of metamodelling patterns and business patterns give the method engineers wide possibilities of extension, refinement and adaptation. At the beginning of the refinement phase, method engineers manipulate a small process metamodel only containing the selected core concepts. It is easier to understand a reduced process metamodel and to refine it than understanding a big metamodel and removing the concepts that are not needed.

The larger the metamodels are, the longer it is likely to take to understand all their concepts. Once the process metamodel has been completed, the method engineer can instantiate it to model the needed process model: XP and its strategy oriented viewpoint. Figure 14 represents an extract of the process model instantiated from the process metamodel for the planning phase of XP. The intention of the developers is to plan the releases; they can explore potential solutions if the estimates are uncertain. The intentions "Plan the releases" and "Explore potential solution" and the strategy "Uncertainty strategy" form a section; the sections together comprise the map. The strategies "Uncertainty strategy" and "Certainty strategy" are respectively concretized by the work units "Create a spike solution" and "Create a release plan". These work units belong to the work unit category "Activity". These activities compose the phase "Planning phase", which is part of the XP lifecycle. The activities are performed by a developer, and assisted by a customer and produce a release plan (which concretizes the intention "Plan the releases") of schedule work product category, and a spike solution (which concretizes the intention "Explore potential solution") of the code work product category. The process model clearly shows the correspondence between the strategy-oriented and the activity-oriented viewpoints. The method engineer could build the process model according to the organisation's needs, thanks to an adequate process metamodel. The process model can also be represented in the desired formalism, for a better understanding, instead of being represented as a class diagram. For example, Figure 15 represents the strategy-oriented viewpoint of the process model using the MAP formalism while Figure 16 Our method presents a number of advantages: -The cost of maintaining the process domain metamodel is minimal. An expert in process engineering, information systems engineering can maintain it thanks to technology watch in these domains. The maintenance of the process domain metamodel is easy, as it only contains a few concepts. Then, the impact of adding a new concept in the process domain metamodel will only consists of adding a few associations between the new concept and the older one.

-The cost of maintaining the pattern system is minimal. The users (method engineers) will add their own patterns that experts will validate and the users will naturally enrich the catalogue of patterns. Any users can use the validated patterns of the catalogue.

-The cost of education for the method users (method engineers) is also minimal. The process domain metamodel is small and its concepts are ordinary. The use of metamodelling patterns and business patterns might not be easy for beginners but pattern modelling is a common practice and it has often been shown that their use allowed time saving.

-The extension, refinement, adaptation of the draft process meta-model is unlimited. Method engineers are free to metamodel the process that the organisations really need. Our method allows flexibility and adaptability.

Discussion

In this paper, we have presented a method to build process metamodels for information systems engineering, thus supplying the "rigour" element sought by [START_REF] Booch | Object Oriented Analysis and Design with Application[END_REF] as noted earlier. In this section, we discuss some works related to the information systems engineering process in terms of modelling levels, coverage of the viewpoints, and thus flexibility and adaptability of the models. 6.1. Modelling levels [START_REF] Fiorini | Process Reuse Architecture[END_REF] present a Process Reuse Architecture. This architecture allows storing, classifying and retrieving process frameworks, process patterns or common processes in order to reuse them to build process models. Our solution is different because we provide a method to build process metamodels. [START_REF] Tran | Modeling Process Patterns and Their Application[END_REF] propose a similar approach to the Process Reuse Architecture. They provide process patterns to build or improve process models. To structure the process patterns, they defined a metamodel for process pattern, which is comparable to pattern formalism, a metamodel to represent the structural process model, a metamodel to represent the relations between the process elements and a metamodel to represent the behavioural process model. Then, they can reuse process patterns on existing process models, in order to improve or extend them, or they can build new process models. The result of this approach is different from ours in that method engineers work at the modelling level: they only modify process models without changing the process metamodels. Our proposed SMME approach utilizes ideas from SME and indeed provides the metamodel that can underpin method fragments from which a situational process model (method) can be constructed. From original ideas proposed by e.g. [START_REF] Bergstra | A Software Development Model for Method Engineering[END_REF], [START_REF] Kumar | Methodology Engineering: A Proposal for Situation-Specific Methodology Construction[END_REF], [START_REF] Harmsen | Situational Method Engineering for Information Systems Projects[END_REF], [START_REF] Harmsen | Situational Method Engineering for Information Systems Projects[END_REF] and [START_REF] Brinkkemper | Meta-Modelling Based Assembly Techniques for Situational Method Engineering[END_REF], the SME literature has grown rapidly, some of the more recent papers being presented at the IFIP Conference in 2007 (Ralyté et al., 2007). Overall, our approach is limited by the number of application instances. In other words, as noted earlier, for the majority of cases, SME using a pre-defined standardized metamodel will suffice and provide the organization with benefits in both time and quality of the situational method that they construct and utilize. However, the use of metamodels is still in its infancy in software engineering, although having matured rapidly over the last ten years (as detailed, for instance, in Gonzalez-Perez and Henderson-Sellers, 2008). Metamodels are now seen as central to a number of emerging areas in software engineering, including Model-Driven Engineering (MDE) as well as to agent-oriented software engineering. As standardized metamodels themselves become appreciated, understood and used more, some organizations will soon recognize the constraints of such pre-determination much as over the last ten years developers have realized the problems of a one-size-fits-all methodology and opted for the construction of a situated method. Much as SME has emerged from methodological thinking, SMME will itself emerge from the same perceived limitations but at a higher level of abstraction -an increasing level of abstraction over time being a general trend in very many aspects of computing, including information systems engineering.

Coverage

In the Process Reuse Architecture [START_REF] Fiorini | Process Reuse Architecture[END_REF] the definition of a process is restricted to our definition of activity-oriented process. In [START_REF] Tran | Modeling Process Patterns and Their Application[END_REF], their process metamodel does not include the product-oriented, decision-oriented, context-oriented and strategy-oriented concepts. Thus, the process models produced or worked are only activity-oriented. [START_REF] Henderson-Sellers | A comparison of four process metamodels and the creation of a new generic standard[END_REF] present a process metamodel for software development methodologies and their enactment. This process metamodel comprises producers, work products, work units and stages. However, there are no explicit decision, context and strategy viewpoints. Although the published literature is indecisive on the nature of the link between metamodels and ontologies, they are clearly closely affiliated (e.g. Gonzalez-Perez and Henderson-Sellers, 2006a) but not isomorphic. We therefore include in this discussion a recent and very interesting approach in which [START_REF] Leppänen | Towards an Ontology for Information Systems Development -A Contextual Approach[END_REF] presents an ontology for information systems development (ISD). This ontology aims to help understanding ISD, analyzing and comparing ISD artefacts and supporting the creation of new ISD artefacts. It is a low-level ontology and no method is provided to help building information systems using the ontology. This ontology comprises different domains: action (activity-oriented), actor, object (product-oriented) and purpose (decision and goal-oriented), facilities, time and location. The context in ISD is the composition of the seven domains, which differs from [START_REF] Rolland | An Approach for defining ways-of-working[END_REF]. However, there is no domain concerning strategy.

Flexibility

Working at the modelling level is much more restrictive than working at the metamodelling level. Therefore, approaches focusing on activity process models offer less flexibility and adaptability than our method, which allows the construction of process metamodels that include various viewpoints. The existing approaches can be appropriate only in the case when method engineers do not need to represent unusual concepts, for example, if they only focus on the activity oriented viewpoint of the process models. Nevertheless, once method engineers need to represent decisional concepts or intentional concepts linked with operational concepts in their process models, there is no existing method. Our SMME approach really satisfies the necessity for flexibility and adaptability according to the organisational and project context. In this paper, we present different existing process metamodels and their main concepts, distinguishing five categories of process metamodels called viewpoints: activity, product, decision, context and strategy. We expose the different problems linked with their use and their capability to fulfil the organisation's requirements. For situations when standard metamodels are inadequate, we propose a method to build unified, multi-viewpoint and fitted process metamodels. The two-phase method described here uses a process domain metamodel and patterns. The first phase, selection, allows the method engineer to select the main concepts necessary from the process domain metamodel by using a questionnaire. The second phase, refinement, allows the method engineer to refine and enrich the draft process metamodel obtained in the first phase, reusing metamodelling patterns and business patterns. The method engineer then obtains a complete process metamodel fulfilling the organisational needs. This process metamodel can include all the viewpoints if needed, and the correspondence between their concepts. The method engineer can then instantiate the process metamodel to model the different required process models. To improve the resources, we need to define which design patterns can be useful to metamodelling and then adapt them. The process domain metamodel can be improved by method engineer experts who are responsible for technology watch on methods, process models and process metamodels. If needed, they can add new main concepts to the process domain metamodel. Finally, the method could be implemented as a workflow, based on the system pattern stored in the AGAP tool. Future work includes the development of a CAME (Computer-Aided Method Engineering) tool [START_REF] Tolvanen | Incremental Method Engineering with Modeling Tools[END_REF] to model the process metamodel and instantiate it. The process model should be represented with the desired formalism. Industry evaluation will, in the future, supply more insights into the situations in which SMME as well as SME will be beneficial to the organisation.

Figure 2 .

 2 Figure 2. Simplified State-Transition product-oriented process metamodel.

Figure 3 .

 3 Figure 3. Potts decision-oriented process metamodel.

  Figure 4. Extract of the NATURE context-oriented process metamodel.

  dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742

  Figure 8. The selection phase.

  Figure 9. The "Concept-Concept Category" metamodelling pattern.

Figure 10

 10 Figure 10 shows the reuse of the "Concept-Concept Category" pattern for the Work Unit concept. The Work Unit and Work Unit Category concepts are part of the meta-model. General attributes such as the name or the description of Work Unit and Work Unit Category are instantiated in the process models because they are valid for all the process models defined within the organisation. Specific attributes as the date of beginning or the manager of the phase are instantiated at the enactment of the process.

Figure 10 .

 10 Figure 10. Reuse of the "Concept-Concept Category" pattern for the Work Unit concept.

  3.4. The refinement phase dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742

Figure 11 .

 11 Figure 11. The refinement phase.

Figure 14 .

 14 Figure 14. Extract of the process model.

  represents a part of the operational part of the process model using the use case formalism of SPEM and Figure 17 represents the extract of the operational part of the process model using the activity diagram formalism of SPEM. ISO/IEC 24744 (ISO, 2007) recommends several diagram types. For example, the phase and task information shown in Figure 16 would be depicted on a lifecycle diagram (Figure 18), while a high-level overview of how producers, work units and work products are inter-related can be shown on the new dependency diagram.

Figure 15 .

 15 Figure 15. Extract of the intentional part of the process model.

Figure 16 .

 16 Figure 16. Operational part of the process model.

Figure 17 .

 17 Figure 17. Extract of the operational part of the process model.

Figure 18 .

 18 Figure 18. Phases and activities from Figure 16 expressed using ISO/IEC 24744 notation.

  dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 20

  dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730

Table 1 .

 1 The concept of Context is only present in the context-oriented process metamodel NATURE and the concept of Strategy only exists in the strategy-oriented process metamodel. dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742 Synthesis of the different representative process metamodels and their concepts.

	SPEM	OPF	State-	Potts	NATURE	MAP
			Transition
	Work	Work		Step	Action
	Definition	Unit
	Work	Work	Product	Artefact	Product part
	Product	Product
	Process	Producer
	Performer
			State
			Transition
				Issue
				Alternative
				Argument
	Pre				Situation	Source
	condition					intention
	Goal				Intention	Target
						intention
					Context
						Strategy
	2.7. Problems

Table 2

 2

	. The questionnaire
	Question	Synonyms, also known	Concept
		as, examples
	Do you need to represent goals or	Objective, goal, subgoal	Intention
	objectives of the ISE 1 process?
	Do you need to represent how an	Tactics, approach, manner Strategy
	intention is achieved?
	Do you need to represent the situation	Circumstance		Situation
	of an actor at a given moment of the
	ISE process?
	Do you need to represent both			Context
	intention and situation?
	Do you need to describe problems	Problem,	toughness,	Issue
	encountered during the ISE process?	question, difficulty
	Do you need to represent answers to	Answer,	choice,	Alternative
	an issue?	possibility, contingency,
		option, dilemma
	Do you need to represent an argument,	Proof, reason		Argument
	a proof to object or support an
	alternative?
	Do you need to represent something	Product,	document,	Work
	that is produced, used or modified	model, software, program	product
	1 Information Systems Engineering

Table 3 .

 3 The depender concepts and their dependee concepts.

	Depender Strategy Context	Dependee {Source Intention ∧ Target Intention} {Situation ∧ Intention}
	Argument	Alternative
	Alternative	Issue
	Condition Role	Work Unit {Alternative ∨ Work Unit ∨ Work Product}

Table 4 )

 4 . dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742

Table 4 .

 4 The P-Sigma formalism. Pattern interface Identification Defines the couple (problem, solution) that references the pattern. Classification Defines the pattern function through a collection of domain keywords (domain terms).

  dx.doi.org/10.1016/j.jss.2009.05.020 Journal of Systems and Software -Volume 82, Issue 10, October 2009, Pages 1730-1742

A similar result is achievable using powertypes. Since elements in the model domain are clabjects, they can both represent associations in the model and also links in the endeavour domain where the process enactment takes place.

Acknowledgment

We would like to express our special thanks to the Association Française des Femmes Diplômées des Universités (AFFDU) of Grenoble branch, for its financial support. This is contribution number 08/02 of the Centre for Object Technology Applications and Research of the University of Technology, Sydney.


Charlotte Hug
email: charlotte.hug@imag.fr

Agnès Front
email: agnes.front@imag.fr

Dominique Rieu
email: dominique.rieu@imag.fr

A PROCESS ENGINEERING METHOD BASED ON ONTOLOGY AND PATTERNS

Keywords: Information system engineering, process meta-model, process engineering method, ontology, patterns

Many different process meta-models offer different viewpoints of a same information system engineering process: activity oriented, product oriented, decision oriented, context oriented and strategy oriented. However, the complementarity between their concepts is not explicit and there is no consensus about the concepts themselves. This leads to inadequate process meta-models with organization needs, so the instantiated models do not correspond to the specific demands and constraints of the organizations or projects. Nevertheless, method engineers should be able to build process meta-models according to the specific organization needs. We propose a method to build unified, fitted and multi-viewpoints process meta-models. The method is composed of two phases and is based on a process domain ontology and patterns.

INTRODUCTION

An information system engineering method is composed of one or more product meta-models and one of more process models that guide the conception of product models. For example, the Rational Unified Process [START_REF] Kruchten | The Rational Unified Process: An Introduction[END_REF] guides the use of UML [START_REF] Omg | Software Process Engineering Metamodel, version 1.1[END_REF] to build product models.

A product model prescribes the expected caracteristics of the products. Research and applications in product models have been very important; a large consensus has been reached around UML for example. The diagrams proposed by UML allow representing multiple viewpoints of a product; a class diagram represents the static viewpoint of a product, whereas a sequence diagram represents the collaborative viewpoint of the same product. In addition, the profile mechanisms of UML allow adapting and extending the existing meta-model according to the applicative or technologic domain. In process models, research is moving on but there is no strong consensus yet. There is a multitude of process meta-models, each of them representing a particular viewpoint of the process without explicit mapping between them. Finally, most of the existing process meta-models do not propose extension mechanisms, except SPEM [START_REF] Omg | Software Process Engineering Metamodel, version 1.1[END_REF].

In this paper, our goal is to propose a method based on unifying modelling techniques to allow building process meta-models that are:

-unified: only one process meta-model represents all the requirements, -fitted: the process meta-model fits the organization or project requirements, -multi-viewpoints: only one process meta-model represents all the needed viewpoints.

Our proposition consists of a Process Engineering Method Based on Ontology and Patterns (PEMBOP) that allows method engineers building unified, fitted and multi-viewpoints process meta-models according to the organization needs. These process meta-models can then be instantiated and executed, in concordance with the project specificities.

PEMBOP (see Figure 1) is composed of two phases: conceptualization presented in section 3, and conception presented in section 5. The conceptualization phase is intended to identify the process meta-model concepts; it is based on an ontology described in section 2 and produces a conceptual model. The conception phase is intended to enrich the conceptual model. Each concept can be represented as a set of meta-classes. These transformations lean on meta-modelling techniques described as design patterns and process meta-model fragments described as business patterns, explained in section 4. Section 6 presents the instantiation of a process meta-model. Section 7 presents the related works and section 8 concludes this paper.

THE PROCESS DOMAIN ONTOLOGY

The proposed process domain ontology contains the main concepts of existing process meta-models. In this paper, an ontology is the representation of a set of concepts within a domain and the relationships between these concepts. The concerned domain here is the information system engineering process. This high-level ontology does not include secondary concepts. The ontology is composed of two different abstraction levels: the intentional abstraction level, which represents the goals, the objectives of an information system engineering process, and the operational abstraction level, which represents the actions to concretize these objectives. The ontology comprises different viewpoints or modeling axis of a process. A viewpoint is a process perspective; it is not necessarily associated to a particular actor or role as other viewpoint definitions [START_REF] Sommerville | Process viewpoints[END_REF], [START_REF] Finkelstein | Viewpoint oriented software development[END_REF]. Let us briefly describe the different concepts of the process domain ontology presented in Figure 2. We do not aim to explain the different process meta-models here, it has already been done in previous papers [START_REF] Rolland | A comprehensive view of process engineering[END_REF], [START_REF] Hug | Ingénierie des processus: une approche à base de patrons[END_REF].

Operational and intentional levels are represented as stereotypes. We use different kinds of graphical links to distinguish the different associations between the concepts. A classic association represents an association between two concepts in the same abstraction level. For example, Work Unit and Role are both at the operational level; they are linked by a classic association. The dashed lines with an arrow represent the materialization of one concept of the intentional level into another concept of the operational level. For example, a Work Unit concretizes a Strategy.

The concept Work Unit represents something that is done during the process. A Work Unit has conditions, creates (out), uses (in) or modifies (in/out) Work Products, and raises new Issues. This concept comes from activity oriented process metamodels such as SPEM [START_REF] Omg | Software Process Engineering Metamodel, version 1.1[END_REF], Open Process Framework (OPF, 2005), OOSPICE [START_REF] Oospice | Software Process Improvement and Capability Determination for Object-Oriented/ Component-Based Software Development[END_REF] and SMSDM (SA, 2004)which present the activities and their scheduling for the conception of a product [START_REF] Rolland | A comprehensive view of process engineering[END_REF].

A Work Product is something produced or used, during the process, that can be a deliverable (a software for example). The Work Product concept proceeds from product oriented process metamodels, as the State Transition which is a ViewPoint template presented in [START_REF] Finkelstein | Viewpoint oriented software development[END_REF], the Statecharts meta-model [START_REF] Harel | Statecharts: A visual formulation for complex systems[END_REF], the Entity meta-model [START_REF] Humphrey | Software process modeling: principles of entity process models[END_REF], and the Statemachine meta-model [START_REF] Omg | Software Process Engineering Metamodel, version 1.1[END_REF]. Product oriented process models couple the product state to the activity which generates this state [START_REF] Rolland | A comprehensive view of process engineering[END_REF].

A Role does something during the process. A Role carries out a Work Unit, is responsible for a Work Product and can select alternatives to issues. This concept comes from activity oriented process meta-models.

Issues are problems rising during the execution of a process. When an Issue appears, some alternatives respond to it. An Alternative is supported or objected by one or more arguments. An Argument can cite work product(s) to object or support an alternative and to contribute to the advance of a Work Unit. Issue, Alternative and Argument concepts come from decision oriented process meta-models such as CAD° (Conversation among Agents on Decisions over Objects) of the DAIDA project [START_REF] Jarke | Daida: an environment for evolving information systems[END_REF], inspired from Potts and Brun [START_REF] Potts | Recording the reasons for design decisions[END_REF], and IBIS [START_REF] Kunz | Issues as elements of information systems[END_REF]. Decision oriented process models present the successive transformations of a product or elicitations due to decisions [START_REF] Rolland | A comprehensive view of process engineering[END_REF]. A Context is composed of a Situation and an Intention. The Intention is a goal, an objective that the application engineer has in mind at a given point of time [START_REF] Rolland | A multimodel view of process modelling[END_REF]. The Situation represents the part of the product undergoing the process [START_REF] Plihon | Modelling ways-ofworking[END_REF]; it is concretized by a Condition as well as an Intention is concretized by a Work Product. The notion of context was introduced in the European project NATURE from which a meta-model of the same name was defined [START_REF] Rolland | An Approach for defining ways-of-working[END_REF]. The context oriented process models consider the situation and the intention of an actor (analyst, method engineer…) at a given moment of the project [START_REF] Rolland | A comprehensive view of process engineering[END_REF].

At last, a Strategy is an approach, a manner to achieve an Intention. It allows joining a source intention to a target intention. A Strategy is concretized by a Work Unit. The strategy concept comes from the strategy oriented process models that allow representing multi-approach processes and plan different possible ways to elaborate the product basing on intention and strategy notions [START_REF] Rolland | A multimodel view of process modelling[END_REF]. As far as we know, MAP [START_REF] Rolland | A multimodel view of process modelling[END_REF] is the only strategy oriented process meta-model to date. This meta-model allows representing different strategies to achieve intentions.

The ontology is composed of different abstraction levels and viewpoints: Table 1 sums up for each concept, which are its viewpoint and its abstraction level. The concepts of Role, WorkProduct and Work Unit are used in activity, product and decision viewpoints. The concept of Intention is used by Strategy and Context viewpoints. 2 presents the depender concepts and their dependee concepts. For example, an alternative cannot exist without an issue, but an issue can exist without an alternative. Some concepts compulsorily depend on more than one concept: a context cannot exist without a situation and an intention. Other concepts depend on at least one concept, for example: a role can depend on a work unit, an alternative or a work product. Though the ontology only contains the main concepts of process engineering for information system engineering, it is lead up to be enriched by method engineering experts if new viewpoints are found in new process meta-models. The next section presents the conceptualization phase, which is based on the process domain ontology.

THE CONCEPTUALIZATION PHASE

During the conceptualization phase (see Figure 3), the method engineers choose the needed concepts from the ontology to produce a process meta-model called conceptual model. There are different ways of choosing the right concepts. Firstly, the method engineers can choose the concepts according to their abstraction level: intentional or operational. If the method engineers want intentional (respectively operational) process models to be developed, they select intentional (respectively operational) concepts. The method engineers can also choose the concepts according to their viewpoint. The work unit and work product concepts selection that represent the activity and the product viewpoints, allows creating activity oriented process models and product oriented process models.

When choosing a concept, the dependee concepts and the associations between them are "imported" in the conceptual model. The dependee strategy partially ensures the integrity of the conceptual model each time the method engineers add a new concept from the process domain ontology. Nevertheless, our objective is not to check the consistency and the integrity of the process metamodel. This task is not in the scope of our research.

The conceptualization phase in Figure 3 is represented in the MAP formalism [START_REF] Rolland | A multimodel view of process modelling[END_REF]: the strategies are represented by edges between intentions, represented by nodes. To exemplify our proposition, let us present a problem a method engineer can meet. He wants to represent an information system engineering process model showing two viewpoints: strategy and activity. First, he has to build a process meta-model including these two viewpoints. Figure 4 shows an example of a conceptual model where the method engineer chooses the following concepts: Strategy, Intention to represent the strategy viewpoint of the process, and, Work Unit and Work Product to represent the activity viewpoint of the process. All the associations between the selected concepts are imported into the conceptual model. The constraint of the depender-dependee is observed: the concept Strategy has source intentions and target intentions.

PATTERNS

The conception phase consists of completing the conceptual model using meta-modeling techniques (design patterns and process meta-model fragments) to obtain a conception model. Design patterns describe a frequently occurring problem in a context and a general repeatable solution that resolves it. Design patterns can be reused to enrich the conception model. A lot of design patterns already exist, but they still have to be adapted for process meta-modelling. Figure 5 shows the "Concept-Concept-Category" design pattern [START_REF] Hug | Ingénierie des processus: une approche à base de patrons[END_REF]. This pattern allows the partition of concept knowledge: specific knowledge on the one hand, and common knowledge to many concepts on the other hand, using the Item-Description Pattern [START_REF] Coad | Object-Oriented Patterns[END_REF]. The pattern also allows instantiating the properties of the concepts at different instantiation levels, to define general properties at the model level and specific properties at the process level, using the Deep Instantiation [START_REF] Atkinson | The Essence of Multilevel Metamodeling[END_REF]. The potencies "2" on the association and the attributes comes from the Deep Instanciation. The "Concept-Concept category" pattern is strongly useful for process meta-modelling. Process meta-model fragments are part of existing process meta-models that can be reused to detail one or more concepts of the conceptual model developing secondary concepts. Figure 6 Process meta-model fragments are represented as business patterns to standardize their representation with design patterns. The design patterns and the business patterns are created by method engineers when they need to. Experts in information system engineering validate the new patterns to make them available to other method engineers. Experts can also create new patterns from technology watch in information system engineering and method domains. PEMBOP is presented as a pattern system composed of process patterns (the method process itself) and product patterns (design and business patterns) in order to standardize their representation. All the patterns (process, design and business) are represented in the formalism P-SIGMA [START_REF] Conte | A tool and a formalism to design and apply patterns[END_REF], a common formalism for patterns representation that allows the clarification of the patterns selection interface and facilitates the organization of pattern systems.We also dispose of a tool, AGAP [START_REF] Conte | A tool and a formalism to design and apply patterns[END_REF], a development environment for defining and using patterns. This tool integrates a repository consisting of the design patterns, the business patterns (fragments) and the process patterns.

THE CONCEPTION PHASE

During the conception phase, the method engineers select the concepts from the conceptual model they want to enrich. A list of appropriate patterns is proposed. Reports of experts and measures constitute this list. The method engineers choose to reuse a particular pattern according to different strategies: by the resolved problem, by its frequency of use or by its adequacy with the chosen concept. Every pattern description details the problem it resolves. The frequency of use indicates if the pattern is often reused with the chosen concept. The adequacy is a subjective measure filled in by the method engineers who reuse the pattern for this concept and indicate if it is relevant or not. If no existing patterns satisfy the method engineers, they can complete the list of appropriate patterns adding a new pattern. Experts have to validate this new pattern later, so that other engineers could reuse it. The method engineers can add or delete associations, aggregations, or compositions between concepts. The method engineers can choose to continue the improvement of the conception model or to stop the process. The conception phase can also be represented as a MAP, but we do not present it in this paper because of lack of space. In our example, the method engineer carries out these actions on the conceptual model to obtain a conception model specific to the organization needs shown in Figure 7: 1. Reuse the "Concept-Concept Category" pattern for the Work Unit concept, because he needs to distinguish a phase from an activity, and he needs to define properties about an activity in general and properties of the execution of an activity in a particular project. For example, he needs to define properties for the activity "Functional use cases generation" in general and properties of the execution of this activity in a particular project.

INSTANTIATION

Once the conception model (process meta-model) is ready, the method engineer can instantiate it for particular process models.

Figure 8 shows the instantiation of the conception model of Figure 7 for the intentional abstraction level of an information system engineering process model. The example describes the situations met at the beginning of a project, when the business process analyst and the use cases analyst have to define the business processes involved in the project. The example details three intentions and the strategies to achieve them. For example, when the use cases analyst has described the business processes, and if he wants to link the functional business processes, he can use four strategies: extension, inclusion, update, or generalization. Figure 9 shows the instantiation of the conception model of Figure 7 for the operational abstraction level of an information system engineering process model, inspired from Symphony [START_REF] Hassine | Symphony: a conceptual model based on business components[END_REF]. "Organizational specification requirements" is a Work Unit of "Phase" Work Unit Category. "Functional use cases generation" and "Functional use cases description" are Work Units of "Activity" Work Unit Category. The "Functional use cases generation" activity produces a "Functional use cases model" of "Use case diagram" Work Product Category. The work product "Complete functional use cases model" in the operational part of the process model (Figure 9) concretizes the intention "Link functional business processes" in the intentional part of the process model (Figure 8). Different scenarios of the Activity "Functional use cases connection" can concretize the various strategies to achieve the intention "Link functional business processes".

These process models can be then instantiated for each information system project. This first example shows that the PEMBOP is structuring and allows building unified, fitted, and multi-viewpoints process meta-models and models.

RELATED WORKS

In this section, we discuss some works related to information system engineering process. [START_REF] Fiorini | Process reuse architecture[END_REF] present a process reuse architecture. This architecture allows storing, classifying, and retrieving process frameworks, process patterns, or usual processes. Our solution is different because we provide a method to build process meta-models, whereas the process reuse architecture allows building process models. [START_REF] Tran | Modeling process patterns and their application[END_REF] provide a meta-model to define process patterns to build and improve process models. This solution focuses on process models while our solution focuses on process meta-models. However, some mechanisms could be adapted to process meta-modelling (pattern searching, selecting, etc.). [START_REF] Leppanen | Towards an ontology for information systems development[END_REF] presents an ontology for information system development (ISD). This ontology aims to help understanding ISD, analyzing and comparing ISD artefacts and supporting the creation of new ISD artefacts. It is a low-level ontology and the author does not provide a method to help building information systems using the ontology. This ontology comprises different domains: action (activity oriented), actor, object (product oriented), and purpose (decision and goal oriented). It does not include intentional level as strategy and context.

At last, [START_REF] Henderson-Sellers | A comparison of four process metamodels and the creation of a new generic standard[END_REF] present a process meta-model for software development methodologies and their enactment. This process meta-model comprises producers, work products, work units and stages. There are no decision, strategy, and intention viewpoints.

CONCLUSION

This article presents a process domain ontology whose main concepts come from different types of existing process meta-models. This ontology is the base of the Process Engineering Method Based on Ontology and Patterns that helps building unified, fitted and multi-viewpoints process meta-models for information system engineering. PEMBOP is composed of two phases: the first phase, conceptualization, allows the method engineer choosing the different needed concepts from the ontology to build a first version of the process metamodel called the conceptual model. The second phase, conception, allows enriching this model mainly using patterns. This phase produces a new version of the process meta-model called conception model. Then, the method engineer can instantiate the process meta-model according to the needs of the organization or the project.

In the future, we have to validate the method, rebuilding existing process meta-models and models using case studies. Once we validate the method, we will then have to implement a tool that will easily guide the users in the construction of their process meta-models: a workflow could assist the two phases, conceptualization, and conception.

Figure 1 :

 1 Figure 1: The Process Engineering Method Based on Ontology and Patterns.

Figure2:

  Figure2: The process domain ontology.

Figure 3 :

 3 Figure 3: The conceptualization phase represented as a MAP.

Figure 4 :

 4 Figure 4: Example of a conceptual model.

Figure 5 :

 5 Figure 5: The "Concept-Concept Category" design pattern.

  shows a process meta-model fragment which can be reused in order to detail the concept of Work Product. New classes are added in the conception model: State and Transition. This fragment comes from the State-Transition product oriented process meta-model.

Figure 6 :

 6 Figure 6: Example of a process meta-model fragment extracted from State-Transition.

Figure 7 :

 7 Figure 7: Example of a conception model.

  2. Reuse the "Concept-Concept Category" pattern for the Work Product concept, because he uses different kinds of work products: use case diagrams, documents, etc. He also needs properties defined at the model level and at the execution level. For example, he needs to define properties for a "Functional use cases model" in general and for a functional use cases model in a particular project. 3. Add a reflexive association called "Parallel" to the Work Unit concept because two work units can be executed in parallel. Add a reflexive association called "precedes-follows" to the Work Unit concept to represent a sequence of work units. Add a reflexive aggregation to the Work Unit concept to represent the fact that a work unit belongs to an other work unit. Finally, add a reflexive aggregation to the Work Unit Category concept to represent the fact that a work unit category can comprised work unit categories.

Figure 8 :

 8 Figure 8: Extract of an intentional process model.

Figure 9 :

 9 Figure 9: Extract of an operational process model.

Table 1 :

 1 Abstraction levels, viewpoints and concepts. Some concepts of the ontology cannot be separated from other concepts. Their existence depends on other concepts existence. Table

	Abstraction level	Viewpoint	Concept
		Strategy	Strategy
	Intentional	Context	Context Situation	Intention
			Issue	Role,
		Decision	Alternative	Work
	Operational		Argument	Product,
		Product		Work
		Activity	Condition	unit

Table 2 :

 2 The depender concepts and their dependee concepts.

	Depender	Dependee
	Strategy	{Source Intention  Target
		Intention}
	Context	{Situation  Intention}
	Argument	Alternative
	Alternative Issue
	Condition	Work Unit
	Role
		Work Product}

{Alternative  Work Unit 