Deliverable DTG2.3

13 downloads 551 Views 3MB Size Report
May 15, 2007 - Study, 'Demo TelCo', at different levels of abstraction and a first set of experiences on model ...... RDF data model is a generic (labelled) graph. ... the input file via an API (e.g. to have the possibilities to call method such as ... Python-based rule engine) could be used to realize the UML to OWL translation.
INTEROP Interoperability Research for Networked Enterprises Applications and Software

Network of Excellence - Contract no.: IST-508011 www.interop-noe.org

Deliverable DTG2.3 REPORT ON MODEL DRIVEN INTEROPERABILITY Classification Project Responsible: Authors: Contributors

Task Status: Date:

Public Ecole Centrale de Lille (EC-Lille#25) / Universitat Jaume I (UJI#50) / ADELIOR #54 / SINTEF #16 Jean-Pierre Bourey (EC-Lille) / Reyes Grangel (UJI) / Guy Doumeingts (ADELIOR) / Arne J. Berre (SINTEF) Stelios Pantelopoulos (Singular#33), Kostas Kalampoukas (Singular#33), Fulvio D’Antonio (LEKS#11), Yves Ducq (UB1#2), Michel Bigand (EC-Lille#25), Kleber Corrêa (UJI#50) TG2.3 Model Driven Interoperability Final Version (1.4) 15th of May 2007

Deliverable DTG2.3

1/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Versioning and Contribution History Version

Date

Description

Contributor Contributor organisation EC-LilleTaking into account the discussions UJI performed in the TG2 meeting that took place in Roissy (Paris) on September 2006

0.0

2006-09-20 First draft of the content structure

0.1

2006-11-13 Addition of the first draft/big picture EC-LilleUJI for the Reference Model of MDI, and Class Diagrams at the CIMbottom level on the selected scenario First draft analysis for CIM2PIM approaches Refinement of some sections and assignment of tasks/sections to each partner

Taking into account the discussions performed in the TG2 meeting that took place in Nancy on November 2006 and the contributions provided for EC-Lille and UJI partners

0.2

2007-02-15 Addition of the content of section II.3.3 Update of figures II.5 and II.6 Addition of content (text and class diagrams) for section II.5.3.2 Bottom CIM- Models using UML, II.5.3.3 PIM Models using UML, II.5.3.4 PSM Models using UML

EC-LilleUJI

Kleber Corrêa (UJI), Reyes Grangel (UJI), Michel Bigand (EC-Lille)

0.3

2007-03-02 Refinement of section II.5.3 Addition Figure II.15 Refinement of some sections of part II First draft MDI Method Section II.4

UJI

Kleber Corrêa (UJI), Reyes Grangel (UJI)

0.4

2007-03-09 Refinement of section II.5.3 Change on deliverable topics (section II.3 moved) Addition Figures II.3 and II.4 Addition Table 9 (MDI Method first draft) Addition of content section II.4, MDI Method Section

UJI

Kleber Corrêa (UJI), Reyes Grangel (UJI)

0.5

2007-03-29 Reorganisation of the document according to the new template

EC-LilleUJI-UB1

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI), Yves Ducq (UB1)

0.6

2007-04-02 First Draft of Section II.1 (Introduction of PART I) Section II.1, II.2, II.3.2 updated Section II.7 moved to III.4 Figure IV.8 (MDI Activities) updated Section IV.4.3 updated References updated Section II.1 inserted

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

Deliverable DTG2.3

2/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

0.7

2007-04-19 Refinement of general structure and reorganisation of the contents Inputs for MDI Method in Part II and III Link to other works Contents to summarise the objectives and results of the whole project

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

0.8

2007-04-23 Link to other works completed Executive Summary Content added References Checked and updated Conclusion of Part I added Conclusion of Part II added

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

0.9

2007-04-23 Section I.2, I.3.2 updated Content for section II.2.6.1 added

SINTEF

Arne J. Berre (SINTEF)

1.0

2007-04-25 General revision and improvement of the conclusions Delivered version for internal review

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

1.1

2007-04-27 Correction of minor spelling mistakes

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

1.2

LEKS2007-05-02 Semantic support to MDI added in Part II CNR-IASI UML to OWL transformation added in Part III

1.3

2007-05-02 References corrected and updated Reformatting of figures in part II and III Correction of spelling mistakes

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

1.4

2007-05-15 Correction according to the comments of the internal review

EC-LilleUJI

Jean-Pierre Bourey (EC-Lille), Reyes Grangel (UJI)

Deliverable DTG2.3

Fulvio D’Antonio (LEKS-CNRIASI)

3/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Table of Contents I.1

Introduction ................................................................................................................ 8

I.2

Methods to Produce the Deliverable ........................................................................ 10

I.3

Main Results since the Last Deliverable .................................................................. 12

I.3.1

MDI Method......................................................................................................... 12

I.3.2

Dissemination of the Results................................................................................ 23

I.4

Conclusion................................................................................................................ 23

II.1

Objectives of the Task Group over the Project ........................................................ 25

II.2

Main Results............................................................................................................. 25

II.2.1

State of the Art ................................................................................................. 26

II.2.2

MDI Method..................................................................................................... 26

II.2.3

Model Transformations .................................................................................... 27

II.2.4

Semantic Support ............................................................................................. 27

II.2.5

Case Study........................................................................................................ 30

II.2.6

Links to Other Works....................................................................................... 31

II.3

Discussion/Evaluation of Workpackage/Task Results with Regard to the Objectives 36

III.1

Introduction .............................................................................................................. 38

III.2

CIM2PIM Approaches ............................................................................................. 38

III.2.1

Overview .......................................................................................................... 39

III.2.2

Analysis of CIM2PIM Approaches.................................................................. 41

III.2.3

Conclusion........................................................................................................ 44

III.3

GRAIEA2UMLAD Transformation ........................................................................ 44

III.3.1

GRAI Extended Actigram Metamodel............................................................. 44

Deliverable DTG2.3

4/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.3.2

UML Activity Metamodel................................................................................ 45

III.3.3

Proposed Mapping............................................................................................ 46

III.3.4

Experimentation with a Transformation Language.......................................... 47

III.3.5

Obtained Results .............................................................................................. 47

III.3.6

Conclusion........................................................................................................ 50

III.4

UML to OWL Transformation................................................................................. 50

III.4.1

XML to RDF Transformation (preprocessing) ................................................ 50

III.4.2

Metamodel Mapping of UML and OWL ......................................................... 53

III.4.3

Overview of the Process of Transformation .................................................... 55

III.5

MDI Method............................................................................................................. 58

III.5.1

Principles of the MDI Method ......................................................................... 58

III.5.2

Activities and Steps of the MDI Method ......................................................... 60

III.5.3

Conclusion........................................................................................................ 70

III.6

Application to the Case Study.................................................................................. 70

III.6.1

Selected Scenario ............................................................................................. 73

III.6.2

Models Performed Following the MDI Method .............................................. 74

III.6.3

Conclusion........................................................................................................ 87

Deliverable DTG2.3

5/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Executive Summary Interoperability is one of the main outcomes that collaborative enterprises need to reach in order to become competitive in the new global economic environment. A lot of solutions have been provided by the research community in the last decades in order to improve interoperability at the technological level, however full interoperability is not still achieved. Since, it is needed more global solutions that take into account business and knowledge levels. In this context, the Task Group 2 (TG2) on ‘Model Driven Interoperability’ (MDI) aims to apply model-driven approaches and semantic support to solve interoperability problems between enterprises that wants to interoperate by means of Enterprise Software Applications. The main TG2’s contribution to this issue is the MDI Method for guiding enterprises in finding interoperable solutions to interact with each others starting at the Enterprise Modelling level. At this time, the main objective of this deliverable DTG2.3, named ‘Report on Model Driven Interoperability’, is to describe a method that collects all the experiences performed by TG2 so far in order to understand how a model-driven approach can support interoperability. Thus, the research work depicts in this deliverable was produced from a synthesis of the practical experiences performed on the Case Study Extended provided by Singular, and especially from the selected scenario, ‘After Sales Service Process’, that shows interoperability problems between a Franchisor and a Dealer, which have an ERP and a CRM system respectively. The main result since the last deliverable is the formalisation of a method that can be followed for two enterprises that want to achieve interoperability between their computer systems by following three principles: (1) to start the interoperation at high level, that is to say, at the Enterprise Modelling Level; (2) to achieve the interoperability at low level by means of successively transformations of models performed at different level of abstraction, that is to say, following a MDA approach; and finally, (3) to support both the interoperability problems that arise in this process and the model transformations by semantic support. To make it possible, the MDI Method proposed in this deliverable is divided into three main process workflows and organised iteratively in four phases. A complete description of the main activities, expected outcomes, techniques and tools for each one is provided in PART I of this document. In PART II, the main results since the beginning of the project are shown, which are mainly several inputs on the Case Study proposed to be able to define a model-driven method for solving interoperability problems. The TG2 comes from the WP7, which main objective was to analyse the State of the Art on Enterprise Modelling and Software Engineering Methods in order to determine which were the possibilities to generate ESA from enterprise models, and focusing it on interoperability issue. The main result of this analysis was the TG2 definition, in which the Model Driven Architecture (MDA) approach was chosen in order to achieve interoperability for generating code from enterprise models. In TG2 period the two first tasks were dedicated, first, to analyse how it was possible to follow a MDA approach in the context of Enterprise Modelling and with the objective of generating ESA, and second, to determine interoperability needs among models. As a result of the first task, several enterprise and system models, including parameter models, were performed on a real Case Study on a company that used an ERP, at technological level. Besides, a first set of model Deliverable DTG2.3

6/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

transformation experiences were developed in order to follow a typical MDA approach but with the contribution of starting from Enterprise Modelling level, using traditional Enterprise Modelling Languages such as GRAI or IDEF0. The results of the second task were focused on model transformations at the same time that trying to solve interoperability problems. The main objective of these transformations was to demonstrate the feasibility of the MDI Framework proposed at this time previously to the MDI Method, from both points of view, conceptual and technological. Finally, and as it is previously mentioned and shown in PART I, the MDI Method defined from this MDI Framework and more complex experiences on model transformations were developed in the third task of TG2. The main objective of TG2 is achieved providing the MDI Method, since it tries to combine the MDA approach with ontology domain in order to show a path of activities that should be followed by enterprises that want to improve interoperability not only at technological level. This Method combines the three main domains proposed by INTEROP: (1) business, since it starts at the Enterprise Modelling level, solving interoperability problems at this level by means of model transformations, and introducing the parameter models; (2) architectures & platforms, since it uses as key issue model transformations following MDA, not only at vertical level, but also at horizontal level to solve interoperability problems; and finally, (3) knowledge, since it uses ontologies to support interoperability problems and to add the needed knowledge in model transformations. Even this method is a step forward in the application of model-driven approaches to solve interoperability problems, it is needed more real experiences in its application in industrial domain in order to improve it. At this time, from our point of view, there are two main difficulties for the application of the MDI Method. The first one is from technological point of view, the immaturity of some proposed tools and the needed integration of them to make easier their use by end users. The second one is from conceptual point of view, enterprises need to have the appropriate culture and the adequate competences to achieve the ‘Common Interoperability Ontology’ proposed in this Method.

Deliverable DTG2.3

7/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

I PART I Activity and results (last period)

I.1 Introduction The TG2's ultimate objective is to provide a model-driven method that can guide enterprises in using enterprise models to generate Enterprise Software Applications (ESA), and more particularly to solve interoperability problems. The research work inside TG2 in order to achieve this goal is organised in the following tasks: • Task TG2.1: Model establishment (M). • Task TG2.2: Model Interoperability (MI). • Task TG2.3: Model Driven Interoperability (MDI). The main results obtained in task TG2.1 and presented in the deliverable DTG2.1 ’Report On Model establishment’ [1], were different enterprise models performed on the Case Study, 'Demo TelCo', at different levels of abstraction and a first set of experiences on model transformation at vertical level, from which a first framework to parameterise ERP from enterprise models using model transformation in a vertical approach was provided [2]. In the next deliverable DTG2.2 ‘Report On Model Interoperability’ [3] related to task TG2.2, a more detailed framework called ’big picture’ or MDI Framework (see Figure I.1) was proposed to emphasise both interoperability problems (vertical and horizontal) and the different abstraction levels. Two sub-levels at the CIM level was introduced, called Top CIM level (TCIM) and Bottom CIM level (BCIM). In the Top CIM level, the problem is tackled from Enterprise Modelling point of view and Enterprise Modelling Methodologies and Languages were used. The experiments carried out on an extension of the previous Case Study in order to introduce more concrete interoperability problems that arise when one Franchisor with an ERP wants to interoperate with a Dealer with a CRM. This case study will be called Case Study Extended in the following. GRAI was chosen as Enterprise Modelling Methodology at the Top CIM level. In the Bottom CIM level, the issue takes the system under development point of view that means that it aims at defining the requirements of the Enterprise Software Application to develop. In this case, UML was chosen as modelling language and a first set of transformations between GRAI and UML were experimented. The main reason to be focused on the CIM level is that on the one hand, it is very complex since there are a lot of concepts to be represented at this level and the most of the interoperability problems happen at this level. On the other hand, there are not a lot of experiences of CIM to PIM transformations in the literature.

Deliverable DTG2.3

8/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Franchisor

CIM

In fo r m a t io n s E x t e rn e s

F ra n c h is o r S e rvi c e Dpt

In fo r m a t io n s In t e rn e s

F

II

IE

Franchisee Customer’s data

S e rvi c e a n d P r i c e P o l ic ie s

Request repairs

S t ra t

F r an c his e e i n fo r m a t io n s

C o s t re fe re n c e , R e p a iri n g a n d q u a li t y r u le s , F ra n c h is e e re la t io n s h ip m a n a ge m e n t

C u s t o m e r re p a i r in g c o s t a c c ep ta ti o n

F r a n c h is e e r ec e p t io n , To d e a l w ith th e p r o b le m a t ic de v ic e , C o s tin g , R e p a ir ma n a g e m e n t , In v o ic in g

R ec eip t, C o s t , In vo i c e

IE

F

II

Ta c t

In fo r m a t io n s E x t e rn e s

F ra n c h i s e e R e c e p t i o n (S t o re )

F ra n c h is e e S e rvi c e D p t (S t o r e )

In fo r m a t io n s In t e rn e s

F

F

II

S e rvic e p o l i c y

P ric e p o li c y

IE

S t ra t

C us tom e r in fo r m a t io n s

C us to m e r re l a t i o n s h i p m an a g em e nt

C o s t re f e re n c e , R e p a i rin g a n d q u a l it y ru le s , F r a n c h is o r re l a t io n s h i p m an ag e m e nt

C u s t o m e r re p a i ri n g c os t ac c e p ta tion

E nd c us tom er re c e p t i o n , T o d e a l w it h th e p ro b le m a t ic d e vic e

T o s e a rc h t h e p ro b l e m , re p a ir m a n a ge m e n t , c o s t in g , F ra n c h is o r t ra n s fe r , In vo i c i n g

IE

F

F

T ac t

O pé r

R e c e ip t , S e rvi c e re q u e s t , C o s t , C o s t a c c e p ta ti o n, In vo i c e II

O p ér to inform the franchisor for the acceptation

franchisee service reques t franchisee

to analyse the device and determine the cost of repairing Pr

cost of repairing

Invoicing data

franchisee

franchisee

product information

to receipt the device

end cus t

Pr

fixed device

to fix the device receipt

acceptation franchisee

end cust

c ost of service (repairing)

Pr

charges

franchisee

franchisee

problematic device

invoice

Production system IT: ERP Model: GRAI Grid + GRAI Extended Actigram Level: CIM (top level) Interoperability problem Case Study: After Sales Service non acc eptation

ask for the problematic device

to retrieve and prepare t he problematic device Pr

franchisee

end cust

receipt

problematic device

franchisee

Invoice

PIM Customer’s data

franchisor

end cust

Pr Pr charges to perform the invoice

com dept frs

invoic e

end c ust

Pr

problem identified

franchisor

non acceptation of cos t

to search the problem

Pr

servic e request

franchisor

to as k for the problematic device to the franchisor Pr

franchisor

problem not found

customer informations product information

as k for the device

problematic device

franc hisor

service dept store

Interoperability Model

Invoice

fixed device to fix the problem

problematic device

Final repair

acceptation Pr

ans wer

to c alculate the cost to the end customer

Commercial system IT: CRM Model: GRAI Grid + GRAI Extended Actigram Level: CIM (top level) Interoperability problem Case Study: After Sales Service

customer dept store

Customer’s data

Production system IT: ERP Model: UML Level: PIM Interoperability problem Case Study: After Sales Service

product information

to process (rec eipt and prepare) the service request

servic e reques t

end cust

service dept of franchisor

Production system IT: ERP Model: UML Level: CIM (bottom level) Interoperability problem Case Study: After Sales Service

Proc

customer informations

customer and product informations

To perform the invoice Proc

servic e dept of franchisor

non acceptation

To retrieve customer and product informations

ac ceptation of cost

cost of repairing

receipt

problematic device problematic device

franc hisor

franchisor

customer informations franchisee

to inform the franchisor on the non acc eptation Pr

franchisor

to give back the problematic device

non acceptation

franchisor

Pr

problematic device

Problematic device

end cust

Request repairs

Invoicing data Final repair

Commercial system IT: CRM Model: UML Level: CIM (bottom level) Interoperability problem Case Study: After Sales Service

Request repairs

Invoicing data Invoice Final repair

Commercial system IT: CRM Model: UML Level: PIM Interoperability problem Case Study: After Sales Service

PSM ESA

ERP

CRM Figure I.1. MDI Framework presented in DTG2.2

Deliverable DTG2.3

9/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

This deliverable presents the results of task TG2.3, which is focused mainly on the definition of the Model Driven Interoperability Method (MDI Method) and on obtaining a concrete definition of the Interoperability Model proposed in the MDI Framework (see Figure I.1).

I.2 Methods to Produce the Deliverable Different meetings were organised inside the INTEROP General Workshops and specific meetings of TG2 in order to discuss on the progress of the Interoperability Model, to illustrate them with different models performed on the Case Study Extended, and to synthesise the results obtained so far in the MDI Method. •





INTEROP Pre-Workshop on Case Study Extended at Bergen on 30th of April and 1st of May 2006. o Participants: Arne BERRE (SINTEF), Jean-Pierre BOUREY (EC-Lille), Guy DOUMEINGTS (ADELIOR/ITREC), Reyes GRANGEL (Universitat Jaume I), Stelios PANTELOPOULOS (SINGULAR). o Objectives: ƒ To present and disseminate the TG2 Case Study Extended to the other task groups to determine the relationships with the other works. o Results: ƒ A map of the interaction of the TG2 with the other working groups. TG2 Meeting in the General INTEROP Workshop at Bergen, one formal meeting on 2nd and two informal meetings on 3rd and 4th of May 2006. o Participants: Arne BERRE (SINTEF), Marco BERTONI (POLIMI), JeanPierre BOUREY (EC-Lille), Fulvio D'ANTONIO (CNR-IASI), Guy DOUMEINGTS (ADELIOR/ITREC), Yves DUCQ (UB1), Martine GRANDIN-DUBOST (ADELIOR/ITREC), Reyes GRANGEL (Universitat Jaume I), Axel HAHN (UoO), Christian HAHN (DFKI), Andreas LIMYR (SINTEF), Stelios PANTELOPOULOS (SINGULAR), Arne SOLBERG (SINTEF). o Objectives: ƒ To work on the Case Study Extended and to select a scenario o Results: ƒ First models at the CIM level for the selected scenario for study of the after sales service of the Case Study Extended. INTEROP Workshop on Semantic Reconciliation in Oslo in June/July 2006, combined with mobility stays with people from LEKS, DFKI and SINTEF. o Participants: Fulvio D’ANTONIO (LEKS/CNR), Christian HAHN (DFKI), Arne J. BERRE (SINTEF), Andreas LIMYR (SINTEF), Tor NEPLE (SINTEF), Brian ELVESÆTER (SINTEF), Svein Johnsen (SINTEF), Unni LØLAND (SINTEF). o Objectives: ƒ To resolve issues related to the complementarities of a model-based versus and ontology-based approach to Interoperability. o Results: ƒ Presentations and discussions: Fulvio D'ANTONIO (LEKS/CNR), Semantic reconciliation with Ontologies - the ATHENA toolset, Deliverable DTG2.3

10/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software







Business Rules at the CIM and PIM level, Unni LØLAND, OMG ODM Ontology metamodel and UML profiles with QVT transformations - for OWL, RDF, CL, Topic Maps and UML. ƒ Paper: "Comparing Model-transformation approaches by applying a simple evaluation framework" - by Christian HAHN, Tor NEPLE and Andreas LIMYR. TG2 Meeting at Roissy (Paris) on 19th and 20th of September 2006. o Participants: Arne J. BERRE (SINTEF), Michel BIGAND (EC Lille), JeanPierre BOUREY (EC Lille), Fulvio D'ANTONIO (CNR-IASI), Guy DOUMEINGTS (ITREC/ADELIOR), Yves DUCQ (UB1), Reyes GRANGEL (Universitat Jaume I). o Objectives: ƒ To present the different work performed by each partner since the last meeting. ƒ To work on the semantic support in MDI based on the Case Study Extended. o Results: ƒ New metamodel for GRAI Extended Actigram. ƒ Combination of model-driven approach and ontology-based approach can be considered as the technical part of the Interoperability Model box of the big picture of TG2. ƒ Establishment of a map showing the relation with the other TGs. ƒ Identifying different approaches for CIM2PIM, in order to understand which kind of concepts are represented at the CIM level with the objective to categorise them, and then to take some ideas on how these approaches solve the problem of transforming CIM models into PIM model. ƒ Definition of the dissemination activities especially the papers to submit to I-ESA’07. ƒ Definition of the initial structure of DTG2.3. TG2 Meeting in the General INTEROP Workshop at Nancy, one formal meeting on 7th of May 2006, and another one informal on the same date. o Participants: Salah BAÏNA (LORIA-NANCY) (first part of the formal meeting), Arne J. BERRE (SINTEF), Marco BERTONI (POLIMI), Jean-Pierre BOUREY (EC-Lille), Fulvio D'ANTONIO (CNR-IASI), Martine GRANDIN (ITREC/ADELIOR), Yves DUCQ (UB1), Reyes GRANGEL (Universitat Jaume I), Dechen ZHAN (Harbin Institute of Technology), Kostas KALAMPOUKAS (SINGULAR). o Objectives: ƒ To present the final version of the transformation from GRAI Extended Actigrams to UML Activity Diagram. ƒ To present the first class diagram at the CIM and PIM levels for the Case Study. ƒ Presentation of the transformation from UML to RDF/OWL. o Results: ƒ New MDI Framework showing the AS-IS and the TO-BE vision at CIM Level in order to highlight the interoperability needs. TG2 Meeting in I-ESA 2007 on 29th March 2007. Deliverable DTG2.3

11/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

o Participants: Jean-Pierre BOUREY (EC Lille), Yves DUCQ (UB1), Reyes GRANGEL (Universitat Jaume I). o Objectives: ƒ To define the final structure of the deliverable DTG2.3. o Results: ƒ Final structure of the DTG2.3. The assigned work to each partner as well as its contribution can be seen in the minutes of these meetings and the versioning and contributing history of this deliverable.

I.3 Main Results since the Last Deliverable Since the last deliverable, the work has been focused on the definition of the MDI Method. It has been done from several points of view, conceptual and technological, and especially from methodological point of view. Therefore, the main tasks performed are the following: • •



From the conceptual point of view: o Refinement of the developed MDI Framework to support interoperability following a MDA approach in order to be focused on Interoperability Model. From the methodological point of view: o Formalisation and the complete definition of the MDI Method. o Formalisation and the complete definition of a generic method for model transformation which can be used at vertical and horizontal level. From the technological point of view: o Finalisation of the transformation from the Top CIM level to the Bottom CIM level in order to demonstrate the feasibility of the vertical transformation. o Definition of the transformation from UML to OWL in order to demonstrate the feasibility of the horizontal transformation and to emphasise the links between enterprise models and ontological models.

In the following sections, the main results of this work, that is to say, the MDI Method is summarised from these three points of view.

I.3.1 MDI Method Model Driven Interoperability Method (MDI Method) is a model-driven method that can be used for two enterprises that need to interoperate not only at the code level but also at Enterprise Modelling level with an ontological support with the final aim of improving their performances. This method is supported by the conceptual framework called so far MDI Framework and presented in Section I.3.1.1 as a Reference Model for MDI. The following presents the main contributions of this method: •

It uses model transformations to achieve interoperability defining models and an Interoperability Model at different levels of abstraction according to an MDA Deliverable DTG2.3

12/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software



approach and dividing the CIM level into two sub-levels, that is to say, Top CIM level (TCIM) and Bottom CIM level (BCIM). It uses a Common Ontology to support these transformations and to solve interoperability problems at the semantic level.

A summary of this Method is shown in Section I.3.1.2 detailing the phases, activities, tools and expected results for each phase, etc. Finally, technological issues related to the method and the conceptual framework are shown in Section I.3.1.3.

I.3.1.1 From the Conceptual Point of View The framework shown in Figure I.2 is the Reference Model proposed for the MDI approach, which shows the different kinds of models that it is possible to perform at different levels of abstraction, and the successive model transformations that are needed to carry out. The different levels of abstraction are needed in order to make possible model transformations reducing the gap existing between enterprise models and code level. The definition of the several levels was based on the MDA that defines three levels of abstraction: CIM, PIM and PSM. Moreover, we introduced a partition of the CIM level into two sub-levels in order to reduce the gap between the CIM and PIM levels. Figure I.2 shows a refinement of the previous MDI Framework presented in the deliverable DTG2.2, and that now we call Reference Model for MDI, since it can be used inside the method we proposed in this document as a reference model. The main modifications introduced at this time in the framework are focused on the Interoperability Model. Taking into account that the final objective of the method is to solve interoperability problems, the Interoperability Model has been also defined at the different levels of abstraction proposed above. Enterprise E1 Top CIM Level

ESA 1 transformation

Bottom CIM Level

ESA 1

transformation

PIM Level

ESA 1

transformation

PSM Level

ESA 1 transformation

Code Level

ESA 1

Enterprise E2 Interoperability Model (TCIM) transformation

Interoperability Model (BCIM) transformation

Interoperability Model (PIM) transformation

Interoperability Model (PSM) transformation

Interoperability code

ESA 2 transformation

ESA 2

transformation

ESA 2

transformation

ESA 2 transformation

ESA 2

Figure I.2. Reference Model for MDI

Deliverable DTG2.3

13/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

I.3.1.2 From the Methodological Point of View The MDI Method proposed to solve interoperability problems, like its name indicates, is based on the MDA approach. Moreover, from the methodological point of view we analysed several methods or approaches to transform CIM models into PIM, called here CIM2PIM approaches (see Section III.2). The main reason to analyse this kind of approaches is that we need to integrate the Enterprise Modelling context with the OMG proposal at the CIM level. For the other levels, we follow a complete MDA approach. The analysis of CIM2PIM approaches shows that the problem of transforming CIM models into PIM models is not still solved, since all of them produce this transformation manually or almost manually. However, from the methodological point of view, some common features can be observable and they could become really valuable for MDI Method, as well as others that are specific for one or two approaches, but they have become useful in the context in which they are used, such as iterative and incremental process and the use of prototypes within EUP, or the possibility of customisation offered by ARIS and DEM. Using ARIS or DEM when the targeted software is well identified (SAP/R2 or SSA ERP) is interesting because of their completely integrated vertical approaches, however the objective of MDI Method is to provide a more general method. The CIM to PIM transformation could be achieved through an iterative method and by so doing prototypes could be generated. On the other hand, it would be a good idea to utilise the SBVR as a standard for semantic support towards horizontal interoperability, including them in Interoperability Model as semantic reference. Finally, from Enterprise Modelling dimensions, these approaches are complementary and cover all of them, in particular COMBINE Project seems to be interesting for its ’Vision and Risks Statements’, and ’Goal Model’, offering a complementary view at the CIM level. The following principles were applied to the definition of this Method based on the obtained conclusions of this analysis: • • •

The MDI Method is organised as an iterative process like EUP. The MDI Method takes into account the possibility of parameterisation like ARIS or DEM/BAAN approaches. The MDI Method also proposes semantic support like SBVR.

Figure I.3 shows the MDI Method describing like in a EUP approach and which are: • •

its main phases, represented on the columns: they describe four phases corresponding to the passage from one level of abstraction to a lower one; its main workflows, especially the three process workflows related to the three main components of the MDI method: the Interoperability Model, the Common Interoperability Ontology and the Model transformation.

On this figure, the green areas give the estimated effort related to each phase and workflow.

Deliverable DTG2.3

14/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

TCIM2BCIM

BCIM2PIM

PIM2PSM

PSM2Code

Interoperability Model Definition Common Interoperability Ontology Definition Model Transformation Configuration Management Project Management

ITERATIONS

Preliminary Iterations

iter #1

iter #2

iter #n

iter #n+1

iter #m

Data

Services

Process

Business

Data

Services

Process

Business

Data

Services

Process

Business

Data

Services

INTEROPERABILITY CONCERNS

Process

Quality Management

Business

Support Workflow

Process Workflow

LIFE CYCLE

iter #m+1

Figure I.3. MDI Method

A summary of the MDI Method is shown in Table I.1 describing the phases, process workflows, techniques, expected outcomes and supporting tools proposed for the Method.

Deliverable DTG2.3

15/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Phase

I

II

Process Workflow

TCIM2BCIM

BCIM2PIM

Techniques

Expected Outcomes

Examples of Supporting Tools

Interoperability Model Definition • To capture enterprise knowledge • To compare and determine the interoperability needs for business, processes, services and data

GRAI, IEM, EEM, ARIS Language, CIMOSA UEML, POP*

Points of Interoperability represented in the Interoperability Model at the TCIM level (model TO-BE)

GraiTools 1.0, MO2GO, Metis, ARIS Process Platform, Cim Tool, etc.

Common Interoperability Ontology Definition • To define Business Vocabulary • To perform ontology engineering

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Enterprise Interoperability Model at the BCIM level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Interoperability Model Definition • To define computer system requirements

UML for Enterprise Modelling Software Engineering

Points of Interoperability represented in the Interoperability Model at the PIM level

MagicDraw CE 11.5, Poseidon CE 4.2.1-0, Visual Paradigm for UML 5.2 Community Edition, StarUML 5.0, Eclipse/Omondo, Objecteering PE 6.0.0, IBM Rational Software Modeller, etc.

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation

• General purpose programming

Enterprise Interoperability Model

• Dedicated model transformation tools: ADT, MTF, MTL,

Deliverable DTG2.3

16/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Phase

Process Workflow

Techniques languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Expected Outcomes at the PIM level

Examples of Supporting Tools Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Interoperability Model Definition • To define the features of the target specific platform

UML (PIM4SOA)

Points of Interoperability represented in the Interoperability Model at the PSM level

MagicDraw CE 11.5, Poseidon CE 4.2.1-0, Visual Paradigm for UML 5.2 Community Edition, StarUML 5.0, Eclipse/Omondo, Objecteering PE 6.0.0, IBM Rational Software Modeller, etc.

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Enterprise Interoperability Model at the PSM level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Interoperability Model Definition

Java, Database (SQL), Process Engine (BPEL), Interfaces Functionalities (WSDL/ERP), Rule Engine (Ilog Rules)

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

• To develop and/or get metamodels • To create mappings • To implement and execute transformations

III

IV

PIM2PSM

PSM2Code

Deliverable DTG2.3

Java, Database (SQL), Process Engine (BPEL), Interfaces Functionalities (WSDL/ERP), Rule Engine (Ilog Rules) Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

17/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Phase

Process Workflow Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

Techniques • General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Expected Outcomes

Examples of Supporting Tools

Enterprise Interoperability Model at the Code level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Table I.1. Description of the MDI Method

Deliverable DTG2.3

18/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

In order to apply the MDI Method, the different steps to follow are described on the UML Activity Diagram of Figure I.4. This Activity Diagram is composed of two main partitions. The first partition called ‘Top CIM’ describes the actions to be performed at the highest level of abstraction that means at the Top CIM level. The second partition called ‘Level (n-1)’ describes the actions to be performed for the lower levels of abstraction and it is presented as a generic method chunk [4] [5], that means that the same sequence of actions is performed at the Bottom CIM, PIM, PSM and Code levels. The two main supports of the MDI Method that means the Interoperability Model and the Common Interoperability Ontology are represented as object nodes: the Common Interoperability Ontology is presented as a single object node because it is used as a reference support all along the development of the MDI Method, and it is enriched when the lower levels of abstraction models are built. Besides, the Interoperability Model is represented by an object node at each level of abstraction according to the MDA approach in which a distinct model is built at each level by both, a transformation of the model at the upper level, and an enrichment of the model with additional information. For example, the Interoperability Model at the PSM level is obtained by the transformation of the Interoperability Model at the PIM level including information about the targeted platform described in the Platform Description Model (PDM) as proposed in MDA. The main steps of the proposed method are the following (a more detailed description of it is presented in Section III.5.2.) Top CIM Partition The first main step consists in establishing the AS-IS model in order to obtain comparable models making it possible to produce the Interoperability Model at the Top CIM level. Several cases are studied according to the existence or absence of Enterprises Models (EM) in the both enterprises. If such models do not exist in both or are missing in one, all the models must be created using the same Enterprise Modelling Language (EML). If enterprise models exists in both enterprise, the actions to perform depends on the fact that the same EML is used or not. If the two EML are different, POP* and UEML approaches can be used as common support and then the specific enterprise models are imported/exported. In the other cases, a dedicated transformation must be developed in order to “convert” the models into a common basis. The generic method to build this transformation is presented on the Activity Diagram of Figure I.5. After this first main step, we get comparable enterprise models and the Interoperability Model at the Top CIM level can be built. The second main step consists in defining the Common Interoperability Ontology. As for the previous step, several cases are studied depending on the existence or not of the ontological models in both enterprises. Depending on the case, the Common Interoperability Ontology will be built from scratch or by merging, aligning, transformation, etc. of the existing ontologies. At the end of this first part of the MDI Method the Interoperability Model at the Top CIM level and the Common Interoperability Ontology are built.

Deliverable DTG2.3

19/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Level (n-1) Partition This partition is a ’generic’ partition that is to say that all the actions in this partition are performed iteratively for all lower levels of abstraction (Bottom CIM, PIM, PSM, and Code). The first action consists in transforming the Interoperability Model at the upper level (for example: Top CIM level) into an Interoperability Model at the current level (for example: Bottom CIM level) according to a “classical” MDA approach that means by adding all additional knowledge needed to produce this model. Then the existence of models for both enterprises at this abstraction levels is checked. If no such models exist, then they are produced from three sources: the models at the upper level, the Interoperability Model just obtained at the current level and all additional ’external’ knowledge. Therefore, the horizontal interoperability between the models of both enterprise models is automatically ensured through the Interoperability Model and the consistency with the upper level is ensured thanks to the MDA approach. If models pre-exist for the enterprise at the current level, then transformations must be developed between the Interoperability Model and the existing models. After this step, the updating of the Common Interoperability Ontology is performed if needed.

Deliverable DTG2.3

20/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure I.4. Steps to follow in the MDI Method represented by means a UML Activity Diagram

Deliverable DTG2.3

21/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Moreover, from the methodological point of view, a framework was proposed showing the several steps to perform in order to build and execute transformations from a source model to a target model. This method which is formalised as a UML Activity Diagram presented in Figure I.5 can be used for vertical transformation as well as horizontal transformations at all levels of abstraction.

Figure I.5 Steps to perform a model transformation represented by means of a UML Activity Diagram

I.3.1.3 From the Technological Point of View In order to prove the feasibility of the implementation of this proposal, some experiments have been carried out. The first one deals with the transformation from models at the Top CIM level to models at the Bottom CIM level and more precisely from GRAI Extended Actigram to UML Activity Diagram. A first version was proposed in [3]. This version has been completed during the last period taking into account more precisely: o the transformation of Structured Activities, o the detection and transformation of initial and final activities, Deliverable DTG2.3

22/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

o the recent metamodel evolution from UML2.0 to UML2.1.1, o and the latest version of the Atlas Transformation Language [6] used for this experiment. The second one is related to the transformation from UML models to OWL in order to demonstrate the feasibility of the horizontal transformation and to emphasise the links between enterprise models and ontological models.

I.3.2 Dissemination of the Results The main results obtained during the last period were disseminated through papers, tutorials and master courses, and they are the following: •

• •

Papers: o Model transformation results have been published in [7] [8]. o First CIM2PIM approaches analysis in [9]. o General description of the MDI Method in [10]. o Model transformations for Agents [11] [12]. o Model based semantic Mapping Framework [13]. o Ontology-based versus Model-based mappings [14]. I-ESA Tutorial: o A 3-hours tutorial entitled ’From Model Transformation to Model Driven Interoperability’ was performed during the I-ESA’07 Pre-Conference [15]. INTEROP Academic MASTER: o TG2 partners are involved in the INTEROP Academic Master and especially in the module O02 entitled ’Model Driven Interoperability’. A first session of this course took place in Valencia from 17th until 20th of April.

I.4 Conclusion The MDI Method proposed in this deliverable is the result of the TG2’s work on models and model transformations in a real Case Study. This Case Study is focused on interoperability issue at the technological level, however, the experiments carried out were started at the Enterprise Modelling level, and following an MDA approach, they were finished at PSM level. These experiments were performed in order to demonstrate the feasibility of model transformations: • •

at vertical level, to follow a complete MDA approach. at horizontal level, to ensure the interoperability of enterprise at different level of abstractions by means of model transformations.

The MDI Method, after the analysis of the different CIM2PIM approaches, was based mainly on ‘Tasks-Roles Oriented Engineering’, especially ‘Enterprise Unified Process (EUP)’. The main contribution taken from this method is the iterative feature, since it is tested feature in Software Engineering domain. Thus, the definition of MDI Method is organised as an iterative method in which there are three workflow, the two firsts dedicated to define the Interoperability Model and the Common Interoperability Ontology, and the last one for Deliverable DTG2.3

23/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

doing Model Transformation. These three workflows are repeated along the four phases defined to cover all the process from Enterprise Model until ESA. Besides, other convenient features for the method were chosen from the analysis performed on CIM2PIM approaches, such as the possibility of parameterisation from DEM of BAAN, or the semantic support from SBVR (Semantic Business Vocabulary). Moreover, the MDI Method constitutes a roadmap that can be used for enterprises to locate their starting and target points in order to achieve interoperability following a model-driven approach using models transformations. In addition, the MDI Method provides also a generic model transformation method, this method has been tested on an effective Case Study. The model transformation method takes handles several interoperability problems based on different interoperability concerns, those concerns have been identified within the ATHENA Interoperability Framework.

Deliverable DTG2.3

24/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

II PART II Results over the whole project

II.1 Objectives of the Task Group over the Project The objectives of the Task Group 2 (TG2) were to analyse and propose solutions for ‘Model Driven Interoperability’ (MDI). This focus idea came out of the initial work in WP7 named ‘Method and specification to generate customised Enterprise Software’. The objectives of this WP were the following: • • •

to establish an exhaustive state of the art of the empiric methods and techniques to derive IT specifications from Business Process models and from Enterprise models, to establish a state of the art of existing methods and techniques to develop complete software tools and software modules based on IT modelling, to contribute to the definition of a systematic method to derive IT specifications from enterprise and business process models based on MDA.

This initial work enabled on month 18 of the project, the emergence of the TG2, based on the initial objectives of the WP7 and also based on the various States of the Art it was proposed to decompose the TG2 work in three tasks – to establish the basic ingredients of MDI. •





Task TG2.1: Model establishment. The objective of this task was to focus on how to establish relevant models and relationships between models. The main originality is to combine the MDA model principles with Enterprise Techniques particularly using the Modelling point of view as Process, Product, Decision, Information, Business rules. Task TG2.2: Model Interoperability. The objective of this task was to provide a baseline for ESA system interoperability, by establishing interoperability mappings between the respective system models, relating to interoperability mappings between related ontology models and enterprise models. The conceptual approach is to ease the system interoperability mappings by the use of platform independent system models, and to ease the platform independent model mappings through appropriate use of semantic annotations and references to ontologies and enterprise models. Task TG 2.3: Model Driven Interoperability. The objective of this task we are focusing on how the ESA system interoperability could be driven by the established interoperability models. One goal is to be able to generate appropriate Mapping Software (ms) that can support the mapping between the external interoperable models, and internal representations – with ease of configuration for the internal mappings.

II.2 Main Results The main results obtained over the Project, that is to say, related to WP7 and TG2 are summarised in the following sections: Deliverable DTG2.3

25/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

II.2.1

State of the Art

The analysis of the three States of the Art reports coming out of WP7 has provided a good basis for further work [16]. •

The State of the Art performed by the task 7.1.1 demonstrates that the CIM level corresponds to the Enterprise Modelling domain. The second State of the Art, developed by the task 7.1.2 is on Software Engineering, with a focus on Enterprise/Business Model to System Model mappings. It analyses various approaches to mappings from Enterprise and Business models to System models (i.e. from Analysis to Design), as a typical part of various Software Engineering methodologies. These will give examples on possible approaches to employ, formalise and automate mappings, as a basis for the generation of customized ESA from models. But to reach the defined objectives it is underlined the need to combine such approach with ontology. The third State of the Art gives an overview on model Transformation based on various works developed in OMG.





In Model-Driven Development processes, it is possible to develop an extensive set of different interrelated models at different abstraction levels. These may range from business models, requirements models and design models to deployment models and code, code generation, and model synchronization. This part gives methods and tools to transform one model at one level to another model at the next level (vertical transformation) as well as to transform models at the same level of abstraction (horizontal transformations).

II.2.2

MDI Method

The first result concerning the MDI method deals with the definition for the MDI framework presented first deliverable DTG2.2 [3] and then updated in this deliverable (see Section I.3.1.1). This proposal is an extension of the vertical approach based on MDA and model transformations which was obtained in the first task of TG2, TG2.1. This extension deals with two main aspects: •



The decomposition of the CIM level into two sublevels: o Top CIM level: to represent a company from a ‘holistic’ point of view, showing its domain, business, strategy, etc. at high level of abstraction and without considering any software application features. o Bottom CIM level: to represent the part of Top CIM level, this needs to be implemented in a computer system, that is to say, to show the system requirements but without linking them to any specific kind of technology. The use of an Interoperability Model as support of interoperability at horizontal level, which is taking into account an ontology-based approach to provide semantic support for solving interoperability problems. This semantic support is ensured by the definition of a Common Interoperability Ontology.

The second result deals with the method associated to this framework. This method defined the steps to follow in order to solve interoperability problem at code level starting form the Deliverable DTG2.3

26/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

enterprise level. It defines how to elaborate an Interoperability Model at each level of abstraction and a Common Interoperability Ontology. The main steps of this Method are presented on the UML Activity Diagram shown in Figure I.4

II.2.3

Model Transformations

As mentioned in the previous section, model transformation is one of the key approaches used to support the MDI Method. This approach is used in both horizontal and vertical dimension of the Reference Model for MDI presented in Figure I.2 . All model transformations performed are based on to the generic transformation architecture presented in Figure II.1. According to this architecture, the work of TG2 was focused: •



From the methodological point of view, on the formalisation of a method composed of different step to perform in order to build and execute transformation from a source model into a target model. This method which is formalised as an activity diagram presented in Figure I.5 can be use for vertical transformation as well as horizontal transformations at all levels of abstraction. From the technological point of view, on a feasibility demonstration of the proposed approach by experimenting a transformation language and its supported tool on the transformation of GRAI models to UML models. MetaMetaModel

Mi+2

Conforms to

Mi+1

Source Metamodel

Conforms to

Target Metamodel

Mapping

Conforms to

Conforms to

Conforms to

Mi Transformation

Source Model

Target Model

Figure II.1 Transformation Architecture

II.2.4

Semantic Support

In this section we want to investigate the potential contribution of semantic technologies to MDD software engineering process and in particular to MDI objectives.

Deliverable DTG2.3

27/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Semantic techniques (and especially ontologies) are gaining more and more interest also because of a project called Semantic Web (SW) [17] [18]. The objective of SW is to re-define and to structure resources on the web so that they can be accessible not only by human users but also by software applications allowing them to understand the meaning of resources in order to manipulate, integrate and make them available to other applications. In such context a number of languages for Knowledge Representation have been created: syntax oriented languages (such as XML and RDF [19][20]) and semantics-oriented languages (such as RDFS, DAML, OIL and OWL [21][22][23]), i.e. languages which constructs are capable of representing conveniently, with axioms and statements, concepts and relationships among concepts belonging to a given domain of interest. The advantages afforded by SW promise to be noticeable; automatic reasoning, flexible query processing, enhanced data and services integration. On the other side, the MDA, a project of Object Management Group (OMG), has the objective of standardizing the process of software applications development through a stepwise approach consisting of models of the system under development at different levels of abstraction. The different levels (or views) of the systems are realized by means of transformations. Transformations from on level to another are essential for the whole process, and in practice they are mainly realized manually. Important benefits that should be obtained by the adoption of the MDA are on one hand time saving and costs reduction for software development, on the other hand the increase of interoperability (it will be shown how in the rest of the deliverable) and portability of software applications. In the context of these two big projects, SW and MDA, a lot of interesting techniques, tools, and methodologies have been developed, however, they seem to be restricted to their own ambit: it could be interesting to realize a bridge allowing these two universes to make synergy, having the possibilities to integrate the instruments coming from both sides. One could think how many benefits transformation techniques could gain from automatic reasoning techniques [24][25][26] coming from SW: - Verification of the consistency of models - Support to automatic mapping discovery among heterogeneous models - Definition of semantic preserving transformation The above listed services can support MDI to tackle both vertical and horizontal issues. • Vertical issues Semantic support aiming at: 1. Giving a logic-based formalization of portions of models via semantic annotations easing reuse, cross reference, unambiguous terminology. 2. Tracing the changes (among the different layers of MDD transformations). 3. Formalizing the delta-knowledge used in semantic enriching transformations (i.e. the transformations from more abstract models to more detailed ones)

Deliverable DTG2.3

28/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

• Horizontal issues Semantic support aiming at: 1. Performing semantic mismatches analysis among the models of different enterprises 2. Representing model correspondences across enterprises through semantic annotations 3. Creating reconciliation rules for performing data, service and business process reconciliation. We have decided, therefore, in order to ease the communication between the world of Model Driven approaches and the Semantics domain, to realise a tool for the automatic translation of UML models into OWL ones. The requirements that such a tool should satisfy are the following: •

The tool has to support the automatic translation of (a subset) of UML constructs and diagrams into corresponding OWL models. • The tool must be easily extensible to support an increasing number of UML diagrams/constructs. • The tool must be easily integrable with Athos and A*, the Ontology Management System and Semantic Annotation system developed by the Athena project (realized using Zope/python) The latter requirement is meant for giving the possibility of experimenting tools developed within the Athena project in MDI tasks. Operationally the tool translates models written in XMI language into OWL models. XMI is a standard OMG for metadata exchange; it is an XML dialect. As the target of the translation we have the OWL language; OWL is specified as an RDF vocabulary; an RDF vocabulary is simply a set uniform resource identifiers (URIs). Although it is not the only serialization, OWL models are usually encoded using the RDF/XML format. One should notice that while the underlying data model of XML is a tree (acyclic graph), RDF data model is a generic (labelled) graph. Concerning the concrete syntaxes to be manipulated several options for performing the translation are available: 1. Using XML to XML transformation tools (e.g. XSLT stylesheets) [27] 2. Using XML and RDF parsers and corresponding APIs (e.g. the Java DOM parsers and the Jena HP package) [28] 3. Performing a pre-processing of UML models encoded using XMI to transform it into RDF format and then using RDF to RDF rule engines to transform it into OWL.

In the first case (XML to XML) the transformation could be realized writing XSLT sheets. XSLT is an XML-based language for transforming XML documents; applying an XSLT sheet to an input document will not modify the original one and instead the result of the application of transformation rules will be stored in a “brand new” file. In our case the approach based on such technology doesn’t seem to be the best choice: Deliverable DTG2.3

29/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

1. XSLT stylesheets are hard to design and to debug 2. XMI and OWL/RDF data can be expressed equivalently in many different ways: this means that there are several syntactically different XML trees that denote to the same semantics in RDF or XMI. This means that for each syntactical variation an XSLT rule or sheet should be designed, causing redundancies, obfuscating understanding, possibly missing important cases and so on. In the second case (XML to RDF translation), the hypothesis could be to use an XML parser, e.g. a Java DOM parser, to parse and to have the possibility of accessing the information in the input file via an API (e.g. to have the possibilities to call method such as getChildElements or getElementByID). An RDF API could be used to create accordingly the output model. The transformation can be realized using traditional programming code (e.g. Java), calling programmatically the API provided methods. Also this approach presents a number of disadvantages: •

The realized translation code would be hardly scalable and factorizable: in case of willing to support new constructs of UML the whole software should be modified. • The criteria of translation should not clearly understandable but they would be “hidden” in the programming code • The control of transformation properties (such as termination or confluence) would be very hard Concerning the third case (pre-processing+ RDF to RDF transformation), the strategy could be the following. With a simple pre-processing step the XML input format should be transformed into RDF; than an RDF rule engine (such as the Jena generic rule reasoned or a Python-based rule engine) could be used to realize the UML to OWL translation. This last choice is the one that better satisfies the requirements of extendibility, modularity, ease of integration with Athos and A* tools (if a Python-based rule engine is used) and possibility of formally verifying transformation properties [29].

II.2.5

Case Study

During the entire project, TG2 worked with the view to demonstrating the feasibility of its proposals by experimenting on a real Case Study named ‘DEMO Telco’ and provided by the Singular Company. This Case Study deals with interoperability problems in the context of a company organised in a network Franchisor/Franchisees/Dealers in the mobile phone sector. In the first deliverable, TG2 focused on the ’Sale department’ showing how Enterprise Modelling techniques can be used at the CIM level and how these models can transform the towards the PIM level. Three modelling techniques were selected, UML, GRAI and IDEF. For each modelling techniques models at the CIM level have been elaborated. The transformation model between the CIM level and the PIM level was analysed and the principles of the transformation were proposed. The use of the semantics techniques was discussed and some propositions formulated. In order to tackle the problem of horizontal interoperability, the Case Study ‘Demo TelCo’ of the DTG2.1 was extended and used in DTG2.2 and in this deliverable. This second case study Deliverable DTG2.3

30/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

was related to the ‘integration’ of Enterprise Software Applications (ESA) of the main branch of the Telco Company and its subcontractors (Franchisees and Dealers). One scenario was selected to be used as validation support of definition of both the Reference Model for MDI proposed by TG2 and the MDI Method developed in DTG2.2 and Part I of this deliverable.

II.2.6

Links to Other Works

The work developed in TG2 is naturally connected to the work performed in the other parts of INTEROP NoE. These connections can be represented in terms of inputs/outputs. The main links to the other Task Groups, Work Packages, and Domains are summarised in Figure II.3. TG4

TG3 Recommendations for Model Tranf. Semantic Participation to annotation the definition of needs. the MoMo ontology.

TG1

Sync. Of EM.

BP,EP alignment techniques.

TG2 Model Driven Interoperability

Ontology support.

DO

Formal description used to perform semantic annotation.

DI

Methods.

A&P support.

Interop support.

TG5

DA&P

TG6

EM support.

DEM

Figure II.2 Main links to other TG/WP/Domain inside INTEROP

The Table II.1 gives a more detailed view of the interactions with the others Task Groups, Work Packages, Domains and Task Forces by expressing what are the outputs or inputs from TG2 point of view. TG / WP / TF / Domain

Outcomes from TG2

Inputs to TG2

TG1

Problems detected in the transformation of models at different levels of abstraction requiring synchronisation methods to be solved Need for managing model evolutions

Synchronisation of models at horizontal and at vertical level, synchronisation provides a methodology for solving problems related to different cultures, working methods, policies, etc., this can help in the process of transforming models Support to the life cycle defined by TG1 in order to be sure that the transformation of the models is possible in a dynamic way Methodology to manage models, can give us some advices on how manage models at different levels

TG3

Return of experience on model

Recommendations for model

Deliverable DTG2.3

31/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

TG / WP / TF / Domain

Outcomes from TG2

Inputs to TG2

mapping/transformations Input for the TG3’s ontology on model morphisms Use of the tool box

mapping/transformations

TG4

Semantic annotation needs

Formal description to performed semantic annotations

TG5

Connection of Business models with the generation of code using MDI approach

Alignment of BP/EM and IT for vertical transformations

TG6

Inputs for the method repository Classification of interoperability problems that we found in the model transformation at different levels

Elements of methods for interoperability (chunks)

DI

Classification of interoperability problems (dependent/independent) Mappings between this nomenclature and the definition of interoperability inside DI (integrated, unified, and federated)

Patterns for interoperability

DO

Needs for connecting our enterprise/interoperable ontology with the business ontologies used inside DO

Ontology support to define the interoperability model Method and techniques for the transformations from PIM to PSM

DAP DEM

Matrix for CIM characterisation

TFKI

Results of TG2

TFET

Module O02 on MDI for the INTEROP Master Programme performed in the Valencia session of the INTEROP Master in April 2007

WP10

3 Tutorials related to MDA and Model transformations examples related to MDI

WP11

Inputs for acting on international standards on enterprise modelling at the CIM level

Elements for defining the interoperability model at the CIM level UEML support for mappings at horizontal level

Table II.1Main links to other TG/WP/TF/Domain inside INTEROP

Figure II.3 shows the complete TG2 framework and the relationships with the other Tasks Groups detailed in Table II.1.

Deliverable DTG2.3

32/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

TG2 Business strategy

TG

TG5

TG2

Bus Proc Serv Data

PIM

TG6

Common Interoperability Ontology

I-P I-O I-P I-*

P O P *

CIM

MDA

4

I-B I-P I-S I-D

TG1

Common Interoperability Ontology

TG3

P O P *

MDA

PIM ADM

Bus Proc Serv Data

I-B I-P I-S I-D

TG3

Bus Proc Serv Data

ADM

Code

M D I

Bus Proc Serv Data

ADM

PSM

CIM

MDA

PSM ADM

DataBase & Documents (SQL) Process Engine (BPEL) Interface (functionalities)(WSDL) Rules engine (IlogRules)

M E T H O D

MDA

Code

Figure II.3. Main links to other TG/WP/Domain inside INTEROP

II.2.6.1

Links to the ATHENA Project

The ATHENA Interoperability Framework and the ATHENA Interoperability Methodology also addresses a model-driven approach to interoperability. The focus in ATHENA was on identifying model-based mapping solutions for the technical areas of data, services and processes in particular, but also with support for business/enterprise model interoperability. The TG2 work has been identified as an interesting complementary study for the ATHENA work.

Deliverable DTG2.3

33/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Enterprise A

Enterprise B

Business

Business

Business

Processes

Processes

Processes

Services

Services

Services

Data

Data

Data

internal communication

external communication

Figure II.4 ATHENA’s View

II.2.6.2 Link to the MoMo Ontology (TG3) The contribution of TG2 can be positioned within the MoMo Ontology developed by TG3 [30] as represented in Figure II.5.

Deliverable DTG2.3

34/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure II.5 Contribution of TG2 with regards to the MoMo Ontology [30]

According to this ontology, TG2 has: • • • • • •

used Modelling languages: UML, GRAI formalisms, Ecore, ATL, etc., experimented Software Tools: GRAI Tool, UML modellers (IBM Rational Software Modeler, MagicDraw), Eclipse, Atlas Development Toolkit, defined a Methodology for tackling the implementation of transformation (see Figure I.5), elaborated Models in the framework of the case study, proposed a ModelMorphism corresponding to the mapping from GRAI to UML in order to demonstrate the feasibility of the approach, and implemented the mapping into a transformation language in order to experiment the Model Transformation.

II.2.6.3 Links to the Method Chunk Repository (TG6) The contribution of TG2 can be positioned within the Method Chunk Metamodel developed by TG6 [4] [5] represented in Figure II.6.

Deliverable DTG2.3

35/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure II.6 Metamodel of Method Chunk proposed by TG6 [4] [5]

According to this metamodel, the global MDI method is an instance of Method. The Reference Model for MDI shown in Figure I.2 can be considered as the Product Model component of this method due to the structural framework it proposes. The Activity Diagram presented in Figure I.4 represents the Process Model of MDI. It is composed of two partitions which are Method Chunks. The first one is intended to solve Interoperability Problems at Top CIM level which is a Product Part of the MDI Reference Model. The second partition is another Method Chunk, more generic, because it applies in the same way to other Interoperability Problems arising in lower level of abstractions (Bottom CIM, PIM, PSM, code) which are the other Product Parts of the Reference Model for MDI. Finally, Table I.1 which gives techniques, expected outcomes, examples of Supporting Tools for each phase of the MDI Method can be considered as Interfaces of each method chunk proposed.

II.3 Discussion/Evaluation of Workpackage/Task Results with Regard to the Objectives Taking into account the initial objectives described in Section II.1 for WP7 and TG2, the main results achieved are the following: •



WP7 had the main objective of analysing the State of the Art of the Enterprise Modelling context and in methods and techniques to derive IT specifications from enterprise models. The analysis on the three States of the Art performed caused the redefinition of the problem to tackle and the creation of the Task Group 2 (TG2). The first task proposed by TG2 had the objective of applying a MDA approach jointly with the main principles of Enterprise Modelling. So that, several kinds of enterprise models were performed on the Case Study. The definition of the parameter metamodel has been proposed. Connections between Enterprise Modelling domain and Software Engineering domain have been investigated as well as the use of UML for EM. Thus, Deliverable DTG2.3

36/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software





the vertical dimension of the MDI approach has been elaborated and validated on the first case study called ‘DemoTelco’. Taking into account the performance indicator proposed for this period, the objective was achieved since two papers [2][31] were produced in order to disseminate the results of this task. For the second task, TG2 focused more on horizontal interoperability and a first set of transformation experiments. Therefore the case study was extended and the first obtained results on model transformation have demonstrated the feasibility. The first draft of the MDI method has been also defined through the proposal of a general framework. Taking into account the performance indicator proposed for this period, the objective was achieved, since three papers [8] [11] [12] were produced in order to disseminate the results of this task. The last task was devoted to the MDI method definition. For this, the general framework called Reference Model has been refined and models have been first elaborated on the selected scenario of the case study for each level it order to express the target of each phase. Thanks to the acquired experiences on horizontal and vertical model transformations, the semantic support and the analysis CIM2PIM approaches the MDI Method has been proposed but not well completely applied to the case study within a prototype demonstrator due to two main difficulties. The most important deals with the industrial property which leads to obstacles to get information about the lower levels of the software (i.e. PSM and code). The second main difficulty is linked to the immaturity or instability of model transformation platforms which are still under development and therefore it needs an important effort to develop a complete demonstrator. Taking into account the performance indicator proposed for this period, the objective was achieved since two papers [9] [10] were produced in order to disseminate the results of this task.

Deliverable DTG2.3

37/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III PART III Technical documents

III.1 Introduction This section presents technical results obtained during the tasks of the last period in order to prepare the deliverable DTG2.3. The first subsection presents the analysis performed on approaches for the transformation from CIM to PIM levels in order to define how the ‘classical’ approach can contribute to the definition of the MDI Method. The second subsection presents the last results obtained for the transformation of GRAI Extended Actigrams to UML Activity Diagrams. These results have been generalised to define the generic method for developing transformations. The third subsection gives more details on the MDI Method especially on way to develop the connection with the Interoperability Model according the existence or not of models in the enterprises. The last section deals with the application to the Case Study.

III.2 CIM2PIM Approaches Model Transformation is the main issue in the MDA and research on methods, techniques and technologies to perform this kind of transformation is one of the most active domains in the field of modelling [32]. Moreover, the difficulty involved in transforming CIM into PIM models is where the greatest difficulty is to be found. More specifically, the trouble lies in how to perform this transformation, that is to say, in finding a method and a technique which make the transformation process easy and in trying to automate it as much as possible. The main difficulty in model transformation at these levels is the high degree of abstraction of the models. The models developed at the CIM level are enterprise models achieved by means of distinct Enterprise Modelling Languages [32] and thus they cover all dimensions of the enterprise: process, organisation, product, decision, and so forth [33]. This means that a very large number of things can be modelled at this level and therefore the problems and specific cases that we can find when transforming models are already bigger and very complex. On the other hand, the target models are system models, which collect the requirements of the enterprise models that have to be implemented in a computer system. However, taking into account that these system models are independent of any specific platform or technology, they also have a high level of complexity. Table III.1shows the different approaches analysed in this paper from different points of views and with the aim of learning how this approaches solve the gap between CIM into PIM level, since all of them are related in some way with the kind of models that is possible to perform at CIM or PIM level and with the process that are carried out. The main reason to choose these examples is that they are representative of each approach.

Deliverable DTG2.3

38/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Nº 1 2

Approach Tasks-Roles Oriented Engineering Enterprise Modelling and ERP Customisation

3 4

Model Driven Engineering Business Process Modelling

5

Business Rule Community Approach

Examples Enterprise Unified Process (EUP) COMBINE Project Architectures of Integrated Information Systems (ARIS) and SAP R/3 DEM of BAAN BP to requirements and task roles BP Modelling to BP/Service Execution, OMG Business Modelling Approach and other (BPMN, BPEL, BPMI/OMG) SBVR (Semantic Business Vocabulary Rules) from OMG for Digital Ecosystems (DBE)

Reference [34] [35] [36]

[37] [38] [39]

[40]

Table III.1. Analysed approaches

In the following sections, the approaches shown in Table 1 are analysed from different points of view.

III.2.1

Overview

The main objective of this section is to give a brief description of the examples proposed here for each approach. These examples were chosen because they are the most representative and already have practical applications in the specific approaches. Thus, by evaluating the practical results, the information that is obtained is more consistent. In Table III.2 we offer a brief overview as well as the goal of each example, together with a conclusion of which levels of the development of a system they perform. Examples Enterprise Unified Process (EUP)

Overview This is an extension of the Rational Unified Process (RUP), which divides one system development cycle into six consecutive phases, namely the Inception, Elaboration, Construction, Transition, Production and Retirement phases, by promoting small cycles of iteration besides the waterfall method

Goal To ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The software uses RUP, which does not contain the two last phases of the EUP.

Level CIM /PIM/ PSM

COMBINE Project

This is a support model-driven development of enterprise systems - using Components. This requires further development of methods, infrastructures and tools as well as business solutions for modelling, designing, deploying, testing and running components successfully on an enterprise-wide scale.

To improve software development productivity by providing a holistic approach to component-based development, integration and evolution of Enterprise systems. It is one of the first practical implementations of the OMG's vision of MDA.

CIM/ PIM/ PSM

Table III.2. Tasks Roles Oriented Engineering approaches

Deliverable DTG2.3

39/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Examples Architectures of Integrated Information Systems (ARIS) and SAP R/3

Dynamic Enterprise Modeller (DEM) and SSA ERP

Overview Focuses on the analysis and definition of requirements phase during the design of management information systems, and not on the execution of business processes. It uses a graphic modelling system supported by software which models data movements and tasks. The organisational structure is modelled topdown from high-level business processes to low-level processes. This model is used as a roadmap of the organisation which is compatible with the structural roadmap of the software package. By having both roadmaps, the software package and the organisational structure are alienable. It also enables business processes to be recorded in the system as well as the full integration of components, which allows changes to be reflected immediately in user roles.

Goal To define the requirements, the design and, ultimately, the implementation of business processes.

Level CIM/ PIM

The SSA Company uses this approach to align, implement and customise the SSA Enterprise Resource Planning system in the organisational architecture of the end-user company.

CIM/ PIM/ PSM

Table III.3. Enterprise Modelling and ERP customisation approaches

Examples BP to requirements and task roles

Overview This framework defines transformations, mappings and refinements at two levels of abstraction. The first concerns the transformations between requirements models and architecture models. The second deals with transformations between architecture models and implementation code.

Goal A proposal of a framework for model transformation and code generation.

Level CIM/ PIM/ PSM

Table III.4. Model Driven Engineering Modelling approaches Examples BP Modelling to BP/Service Execution

Overview A model of a business process models a set of activities. This set (the process) can be described by inputs, outputs and roles.

Goal To position the model at the centre of the software development, while current development practices mostly focus on a certain technology or platform.

Level CIM/ PIM/ PSM

Table III.5. Business Process Modelling approaches

Examples SBVR (Semantic Business Vocabulary Rules) from the OMG for Digital Ecosystems (DBE)

Overview It is typically a statement about one or more business processes. A single element of guidance that does not require additional interpretation to undertake Strategies or Tactics.

Goal This specification defines the vocabulary and rules for documenting the semantics of business vocabulary, business facts and business rules, as well as an XMI schema for the exchange of business vocabularies and business rules among organisations and between software tools.

Level CIM

Table III.6. Business Rule Community approaches

Deliverable DTG2.3

40/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.2.2

Analysis of CIM2PIM Approaches

In this section we show the analysis and conclusions obtained of previous CIM2PIM presented approaches. These analyses were made by two points of view: methodological and Enterprise Modelling dimensions. From the methodological point of view, each approach has its methodology to follow and, therefore, they all have their own specific form and function. However, we have determined certain features that could represent them, and which sometimes exist in more than one approach. These characteristics are as follows: • • • • • •

Iteration: this means that small cycles of iteration are promoted instead of performing everything just once (waterfall method). Prototypes: prototypes are developed during the progression of the application of the approach, and consequently before the final version of the system. Dynamic: each adjustment can be performed easily during the process and it is, at the same time, flexible. UML: models make use of Unified Modelling Language as the standard language to develop them. Standard Proposal: whether the approach brings with it a language proposal to be followed as a standard during its application. Customisation: when the example provides tools to directly customise a specific system. Methodology Features

Example

Phases

Iteration

Prototypes

Dynamic

UML

Standard Proposal

Customisation

Yes

Yes

Yes

Yes

No

No

No

No

Yes

Yes

No

Yes

No

No

Yes

Yes

No

Yes

X

No

No

Yes

No

No

Yes

X

No

No

Yes

Yes

No

No

No

Yes

Yes

Yes

Yes

Yes

No

No

Yes

Yes

Yes

No

Enterprise Unified Process (EUP)

Inception, Elaboration, Construction, Transition, Production and Retirement

COMBINE Project

Business and Requirements Model, Architecture & Design Model, Platform Specific Model and Business Application Requirements, Design and Implementation

ARIS and SAP R/3 DEM and SSA ERP BP to requirements and task roles BP Modelling to BP/Service Execution SBVR from OMG for DBE

CIM, PIM and PSM

X

Table III.7. Analysis from the methodological point of view

Deliverable DTG2.3

41/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

From the Enterprise Modelling dimensions point of view, the approaches are analysed taking into account the different enterprise dimensions that can be modelled at the CIM level; these dimensions are[41] [42]: • • • • •

Organisation: this represents how the organisation is structured, arranged, administrated, and so forth. Process: this describes a sequence of operations or events (possibly taking up time, space, expertise or other resources), which produces some outcome. Product: the models in this dimension show all the information about the products used and provided by the enterprise. Decisional: the models in this dimension represent how an enterprise performs decisional processes. Infrastructure: this characterises the basic facilities, services and installations needed for the functioning of the enterprise, and is what provides them.

Therefore, for each different enterprise dimension, we identified the instrument that the approach utilises to achieve the respective model. Description

Organisation

Enterprise Unified Process (EUP)

Organisation Model

COMBINE Project

Vision and Risk statements, Goal model

Aris and SAP R/3

Organisational View

DEM and SSA ERP

Business Organisation Model

BP to requirements and task roles BP Modelling to BP/Service Execution

Requirements Model Business Process Modelling

SBVR from OMG for DBE

X

Process Enterprise Business Process Model Business Process and Roles model Function View and Control View Business Process and Business Control Model Requirements Model

Enterprise Modelling Products Portfolio Management

Decision Enterprise Business Process Model

Infrastructure Organisation Model

Business Resources Model

X

Data View and Product View

X

Organisational View

Business Function Model

X

Business Organisation Model

X

X

X

X

Business Process Modelling

Business Process Modelling

X

X

X

X

X

X

Table III.8. Analysis from the Enterprise Modelling dimensions point of view

A detailed analysis of these approaches would enable us to reach a number of conclusions about how transformation from the CIM to the PIM level occurs. In this section we explain how this transformation takes place in each approach. With the Enterprise Unified Process (EUP), the passage from the CIM to the PIM level occurs when we move from the Inception phase (where we do most of the business modelling and identify basic requirements) to the Elaboration phase, where we define and validate the architecture of the system. The strong points in this passage are that we have a well-defined methodology, object-oriented programming and all the process is carried out in an iterative Deliverable DTG2.3

42/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

way. In spite of this, the weak points are the need for manual work and the existence of few support models for the operations in the phases. COMBINE Project is focused on what is necessary for a rigorous, deterministic model of an IT element’s behaviour and its position in the organisation that owns and uses it. A combine business model comprises seven work products. Three of these are relatively informal (Context statement, Vision statement and Risk analysis) and the other four are a set of linked rigorous models that can be expressed in UML (i.e. Goal model, Business process and Roles model, Business resource model and Work analysis refinement model). This framework integrates several modules: business modelling, requirements modelling, architecture planning and underlying leading to automated code generation. The passage from CIM to PIM occurs in these frameworks when the architecture planning is generated from the requirements model. ARIS (Architecture of Integrated Information Systems) supports the following services in customising SAP/R3: • • • • • • •

Navigation through SAP/R3 reference models and adaptation to the company case. Design of allocation of resources to processes. Provide customised help texts for SAP transactions. Generation of database structures from ARIS data definitions. Management of different variants of process definitions, for different subsidiaries of a company. Recording and replaying the performance of SAP business processes (as test cases). Bi-directional synchronisations between SAP business process definitions and ARIS process definitions.

The passage from the CIM to the PIM/PSM level occurs when we use its tools to customise the ERP system. The main strength of ARIS is the possibility of customising the SAP/R3; however, this is also a weakness because this customisation cannot be performed in other ERP systems. DEM and SSA ERP: similar to the ARIS approach, the transformation from CIM to PIM/PSM occurs automatically when we use the Dynamic Enterprise Modelling provided by the SSA ERP to customise it. We find the same strength and weakness, because it is provided only for the SSA platform. BP to requirements and task roles is a framework for model transformation and code generation which is a metamodels-based transformation profile; transformations, mappings and refinements are defined at two levels of abstraction. The first involves the transformations between CIM and PIM, i.e. requirements models and architecture models, and uses them to define traceability criteria between use cases and interfaces/operations, in the requirements and architecture model, respectively. SBVR (Semantic Business Vocabulary Rules) defines the vocabulary and rules for documenting the semantics of business vocabulary, business facts and business rules, as well as an XMI schema for the exchange of business vocabularies and business rules among Deliverable DTG2.3

43/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

organisations and between software tools. It does not therefore promote conversion from CIM to PIM models, but the proposal of a standard vocabulary can facilitate this transformation if adopted by other approaches.

III.2.3

Conclusion

The main conclusions about the approaches analysed here that can be considered for inclusion as best practices in the MDI Method are the following: • • •

• • •

EUP: this is an iterative process. Taking the iterative and incremental process of EUP as a way of developing models has proved its efficiency in Software Engineering. ARIS and DEM: they offer the possibility of customisation. Using ARIS or DEM when the targeted software is well identified (SAP/R2 or BAAN) is interesting because of their completely integrated vertical approaches. It would be a good idea to utilise the SBVR vocabulary as a standard, and then perform the modelling with the UML method, working with the frameworks proposed by the COMBINE Project. The CIM to PIM transformation could be achieved through an iterative method and by so doing prototypes could be generated. COMBINE Project seems to be interesting for its Context and vision statement, Risk analysis and Goal model; it offers a complementary view at the CIM level. SBVR is more oriented towards horizontal interoperability. It could be included in the interoperability model (semantics reference). All are based on UML, which means that the writing of transformations for horizontal interoperability is made easier if, for example, “BP modelling to BP/service Execution” is used on the left and “BP Modelling to BP/service Execution” on the right.

III.3 GRAIEA2UMLAD Transformation In order to illustrate the model transformation proposal presented in Section I.3.1.3, in this section we describe a practical example to demonstrate its feasibility. It consists in transforming one GRAI Extended Actigram at the Top CIM level into a UML 2.0 Activity Diagram at the Bottom CIM level. This example includes the metamodels and models needed to perform the transformation, the proposed mapping between GRAI and UML, and the experiences carried out with a tool for implementing model transformations.

III.3.1

GRAI Extended Actigram Metamodel

The GRAI Extended Actigram is presented on the two next figures. Figure III.1 highlights the composition relations between the main constructs, and Figure III.2 focuses on the connections between the concepts through the Flow concept.

Deliverable DTG2.3

44/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.1. GRAI Extended Actigram Metamodel: composition diagram

Figure III.2. GRAI Extended Actigram Metamodel: flow connections

III.3.2

UML Activity Metamodel

An excerpt of the UML Metamodel [43] concerning the Activities is shown in Figure III.3. Only the used metaclasses and their relations have been represented.

Deliverable DTG2.3

45/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.3. Excerpt of the UML 2.1.1 Activity Metamodel

III.3.3

Proposed Mapping

The objective is to find correspondences between the constructs and relations of the GRAI Extended Actigram Metamodel and the UML Activity Metamodel. The proposed mapping is shown in Table III.9. These correspondences must be defined from both syntactic and semantic point of view. From syntactic point of view, the mapping must ensure the consistency of the produced target model. For example, GRAI Flow can be mapped on UML Object or Control Flow depending on its ends: if one of its extremities is connected to a GRAI connector or Resource, then the flow is mapped onto an UML Object Flow, otherwise it is mapped onto a UML Control Flow.

Deliverable DTG2.3

46/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

GRAI Extended Actigram Extended Actigram Process Activity

Condition

it is a not structured Activity it is a structured Activity

Connector (all types) Resource Flow (all types)

LogicalOperator

not connected to a Resource or to a Connector connected to a Resource or to a Connector Converging OR Converging AND Diverging OR Diverging AND

UML Activity Diagram UML Model Activity OpaqueAction Activity + CallBehaviorAction ActivityParameterNode ActivityParameterNode ControlFlow ObjectFlow MergeNode JoinNode DecisionNode ForkNode

Table III.9. GRAI Extended Actigram to UML Activity Diagram Mapping

III.3.4

Experimentation with a Transformation Language

In order to demonstrate the feasibility of these model transformations from GRAI to UML, a transformation language and its associated transformation tool were used, i.e. Atlas Transformation Language (ATL), which was developed by the ATLAS INRIA and LINA Research Group [44] to answer to the OMG MOF/QVT RFP. This is a model transformation language specified both as a metamodel and as a specific textual concrete syntax. It is a hybrid of declarative and imperative language based on OCL [45]. The preferred style of transformation writing is declarative, which means simple mappings can be expressed simply. However, imperative constructs are provided so that some mappings that are too complex to be handled declaratively can still be specified. Once complex mapping patterns are identified, declarative constructs can be added to ATL in order to simplify transformation writing. An ATL transformation program is composed of rules that define how source model elements are matched and navigated to create and initialise the elements in the target models [44]. The ATL is provided with its execution environment (ADT) as an Eclipse plugin. To implement the previously presented mapping, 19 ATL rules have been written.

III.3.5

Obtained Results

The GRAI Extended Actigram of the after sales process of the Dealer is presented in Figure III.4.

Deliverable DTG2.3

47/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Get Repair Request from problematic Customer

End Customer item

Front-Office employee

customer exists

Send Customer Customer Record into Record Franchisor's CRM Network

Retail system

Retail system

Transfer Data

Repair receipt

Repair request data

Franchisor

Network

Send Item to the Franchisor repaired

Retail system

Franchisor

not repaired

Try to repair

Issue the Repair Receipt

Network

Customer Record in RS

Franchisor

Insert Repair Request into Retail System

Receive Customer Record into Retail System

customer Does not exist

Item

Franchisor

External Transportation company

Technician

Inform the customer

End Customer Dealer Invoice Data

Franchisor

repaired Item

Franchisor

Network Phone

Message

Generate Automatically the Customer Invoice

Invoice Repaired Item

End Customer

End Customer

Figure III.4. GRAI Extended Actigram describing the Dealer ‘After Sales Service Process’ The execution of ATL rules produce a XMI-serialised UML file which can be imported into a UML Tool like IBM Rational Software Modeler. Figure III.5 shows the resulting UML Activity Diagram after importing into IBM Rational Software Modeler 7.0.

Deliverable DTG2.3

48/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.5. UML Activity Diagram after transforming and importing into IBM Rational Software Modeler 7.0

Deliverable DTG2.3

49/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.3.6

Conclusion

This experiment developed according to the method proposed in Figure I.5 has demonstrated the technological feasibility of the development of transformation using a transformation language. This experiment has been led from Top CIM level model to Bottom CIM level, but the method experimented is not limited to these kinds of formalism, neither to these abstraction levels nor to vertical transformations. This generic approach can also be at horizontal level.

III.4 UML to OWL Transformation III.4.1

XML to RDF Transformation (preprocessing)

We now describe a simple mechanism to transform XML-based models into RDF-based ones. Some considerations will clarify how this step can be considered trivial and realized with a simple procedure. • The RDF and XML data model are fundamentally different RDF data model corresponds to a labeled oriented graph while XML has a tree-based structure but since every tree is a graph there should be no problem in representing every XML document into an RDF one. •

The order of the elements in XML is meaningful while in RDF the statements are considered without ordering However RDF allows this kind of ordering to be represented using special constructs such as rdf:seq or rdf:List. • In RDF all the resources (except for Literals) are identified by URIs This is not the case for every XML document (even if the best practice should be to assign a precise namespace prefix for every XML element). We will now describe the criteria for performing the translation: 1. Every XML element can be transformed into a type RDF node (i.e. a triple (X,rdf:type,Y)). In Figure III.6, the highlighted element will be transformed on the left side is transformed into the RDF graph on the right side

Deliverable DTG2.3

50/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.6. XML Elements translation

2. Every XML element having an ID attribute is transformed into a node which URI is determined by the value of the attribute prefixed by a given namespace (e.g. ex=”http://www.example.com#”)

Figure III.7. Elements with ID attribute

3. Every XML text node can be translated into an RDF literal.

Figure III.8. Transformation of Text Nodes

4. Every attribute is translated into an RDF triple having as subject the name of the element the father of the attribute, as predicate the name of the attribute and as object an RDF literal representing the value of the attribute.

Deliverable DTG2.3

51/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.9. Transformation of XML Attributes

The tool XML2RDF, developed at LEKS, (realized in python programming language), is built upon the RDFLib library, and realizes the translation of a generic XML document into an RDF equivalent. The RDFLib library furnishes the APIs for programmatically creating the output RDF model and the python XML parser is used to access the input one. In Figure III.11 and Figure III.11 a complete example of the output of the tool (represented using the RDF diagrammatic notation) is shown.

Figure III.10. XML Input Example

Deliverable DTG2.3

52/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.11. RDF Output Example

III.4.2

Metamodel Mapping of UML and OWL

In performing the translation from one modeling language to another, the relationship of the constructs at metamodel level should be clarified (see for example TG3 and TG2 previous deliverables). This means that the M2 (using MOF/MDA terminology) mapping must be explicitly clarified/designed. In this we will therefore concentrate in individuating which constructs or aggregations of constructs at M2 level despite of being syntactically different (pertaining to two different modeling languages) present the same (or similar) semantics. For example the two metamodels both have constructs such as “Class” or “association/property” that are clearly expressing the same semantics, and others that needs a more complex mapping. Classes Both UML and OWL consider the concept of Class. We will denote the two constructs respectively UML:Class and OWL:Class. We can express this M2 mapping with the pair (UML:Class,OWL:Class). Properties and associations In UML, properties represent the structural features of a class. The UML construct ownedAttribute is the name of the relationship linking a class with the attributes owned from the class itself. It is possible to define the type of an attribute as primitive (e.g. String, Integer and so on) or as a non-primitive one (e.g. CodId). In Figure III.12 is depicted a UML Class diagram containing a Class named with two properties (attributes), name and PIN; the type of name is string (a primitive type), while the type of PIN is CodId that is a complex type.

Deliverable DTG2.3

53/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

In UML2 the relations among classes are realized through associations; according to the UML2 metamodel the associations don’t involve directly classes but the typed attributes belonging or not to classes. An association can be navigable in two directions, one direction or no direction at all (the latter case is not really meaningful).

Figure III.12. UML Class diagram example

In Figure III.13 the name of the association is hasAnimal. The classes involved in the association are Person and Animal and, as the arrow suggests, the association is navigable only in one direction. The associations is linking the two attributes P and A, typed, respectively, with Person and Animal. To summarize: • • • •

A is a property owned by the class Person The type of A is Animal A is the navigable end of the association P is the non-navigable end and therefore it is owned by the association hasAnimal (by means of the ownedEnd relation) • The type of P is Person

Figure III.13. UML Association Example

In OWL(DL) the relations among classes are realized by means of owl:ObjectProperties and owl:Datatype properties. Domain and Range of properties can be set by means of rdfs:domain and rdfs:range constructs. The UML properties (not involved in associations) can be translated into owl:ObjectProperties in case the type of the attributes is a complex one and into owl:DataTypePropertyes if the type is a primitive one. In particular, an UML:Property P owned by the class A by means of the relationship ownedAttribute can be translated into an OWL:Property whose rdfs:domain is A and rdfs:range is the type of the attribute.

Deliverable DTG2.3

54/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Considering the example, the UML:Property name typed with String owned by the class Person can be translated in: While the PIN attribute, whose type is CodId, can be translated in: •

A UML:Association having only one navigable end can be translated into an owl:ObjectProperty whose domain is the type of the navigable end. The association HasAnimal in the UML model in our example can be translated into:



A bidirectional UML association can be translated into a pair of owl:ObjectProperty in which one is declared to be inverse (using the construct owl:inverseOf) of the other. The bidirectional UML association FriendOf can be translated into:





III.4.3

Overview of the Process of Transformation

The input XMI file is transformed into RDF using the XML2RDF tool. Then a rule engine together with 10 transformation rules is used to transform the RDF version of the XMI file into OWL. The rule engine used has been developed at IASI-CNR in Python; the provisional name of such rule engine is Transpyre. Deliverable DTG2.3

55/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

In Transpyre transformation rules are written according to a given syntax (in the style of Jena personal reasoner rules); each rule is composed of three parts: premises ⇔ Other premises ⇒ consequences

Premises and consequences are defined by a set of RDF triples; every triple is an RDF statement. Premises and consequences can contain variables and functions. Variables are prefixed with the symbol “$”. Functions are expressed by the name of a function and a list of variables: the function is applied whenever there’s a binding for every variable in the list. Other premises are expressed by means of procedural attachments (developed using python programming language). The behavior of the rule engine is the following: given an input RDF graph (constituted by a set of triples) and a rule r, the engine checks if all the premises of the rule are verified (possibly creating bindings for the variables in the premises, constituted by pairs e.g. ($X,ex:Person) ). If all the premises are verified then the rule is applicable. In case of more than one rule is available and applicable the engine decides which rule to apply according to user specified policies: non-deterministic choice, sequential composition, rule iteration, rule closure (execution of the rule until it is no more applicable). Due to space limitation we provide the example of a single rule translating an UML:Class into an Owl:Class. In Figure III.14 is depicted an UML diagram and its XMI serialization and in Figure III.16 the rule for performing the translation of UML Classes into OWL Classes.

Figure III.14. UML Class Diagram and its serialization

Deliverable DTG2.3

56/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.15. RDF Input example

Figure III.16. Rule for UML:Class to OWL: class translation

When the rule is applied to the input file inFigure III.15, the variable $ClassName is bound to the string “Person” and so the consequences are that the statement “Person” type owl:Class is declared (that is exactly the translation from UML:Class to and OWL:Class).

Deliverable DTG2.3

57/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.5 MDI Method As mentioned in the first part, one component of the MDI Method is the Reference Model presented in Figure I.2. Figure III.17 gives an overview of the Reference Model for MDI in the case of making interoperable ERP software owned by a franchisor with a CRM owned by one of its franchisee. Franchisor Top CIM Level

Interoperability Model (TCIM)

ERP transformation

Bottom CIM Level

ERP

transformation

PIM Level

ERP

transformation

PSM Level

ERP transformation

Code Level

ERP

Franchisee

transformation

Interoperability Model (BCIM) transformation

Interoperability Model (PIM) transformation

Interoperability Model (PSM) transformation

Interoperability code

CRM transformation

CRM

transformation

CRM

transformation

CRM transformation

CRM

Figure III.17. Reference Model for MDI applied to the Case Study

At the highest level (CIM) and for each actor models are built to describe the business in the broad sense that means including process, organisations, products, etc. The functionalities supported by the software are parts of these descriptions. Then, the interoperability needs are identified at this level. These CIM models including the Interoperability Model are transformed into PIM models by focusing on the part of the CIM supported by IT. The platform features are taken into account to produce the PSM models from the PIM level. At last the code is generated by a final transformation.

III.5.1

Principles of the MDI Method

The MDI Method is based essentially on the MDA approach. MDA was proposed by the OMG (Object Management Group) in 2001 as an architecture for software applications development. This initiative intends to promote the use of models as the fundamental way for designing and implementing systems. One of the main objectives of MDA is to separate the functional specifications of a system from implementation details related to a specific platform; so that the enterprise systems and software application can evolve with fast technological changes. Thus, instead of solving the interoperability problem at code level as shown in Figure III.18, the objective of the MDI method is to start at a highest level of abstraction and to derive solutions from successive transformations.

Deliverable DTG2.3

58/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Enterprise E1

Code Level

ESA 1

Enterprise E2

Interoperability code

ESA 2

Figure III.18 Interoperability problem solved at code level

Like MDA, the MDI Method is focused on the use of models for system development. Therefore, it encourages the use of certain categoriess of models and relationships between them. A system can be observed and analysed from different points of view; MDA specifies three points of view: an independent viewpoint of the computation, an independent viewpoint of the platform and a dependent viewpoint of the platform. In this way, MDA defines three conceptual levels: • • •

Computation Independent Model (CIM): to represent system requirements in the environment in which it is going to operate, concerning business models and a holistic point of view about enterprise. Platform Independent Model (PIM): to model system functionality but without define how and in which platform will be implemented, centred in information and from a computational point of view. Platform Specific Model (PSM): the PIM is transformed in a platform dependent model according to selected platform, focused on technological point of view.

CIM specifies the requirements, and the PIM and PSM specify the system design and implementation. The PIM and PSM must not violate the CIM [46]. The most interesting idea of this approach is the possibility of model transformation by means of tools that automate the transformation process until code generation. The MDA utilises the UML – Unified Modelling Language as standard Language for Model development, the MDI Method also makes use of UML, which is a general-purpose modelling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. Deliverable DTG2.3

59/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

The SBVR – Semantics of Business Vocabulary and Business Rules Specification, defines the vocabulary and rules for documenting the semantics of business vocabulary, business facts, and business rules, then MDI Method apply it to obtain a common semantic between enterprises with the goal to achieve interoperability. MDI Method has also some principles of EUP which is an instance of the Rational Unified Process (RUP). RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. The RUP is structured in two dimensions: phases and disciplines (which represent the logical activities that take place throughout the project). The method promotes cycles of iteration in each phase, as many as it takes to address the objectives of that phase, besides the waterfall method. Therefore, each iteration results in an executable release. MDI Method is also developed in two dimensions, and takes the advantage of iteration. An iterative development [34] prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.

III.5.2

Activities and Steps of the MDI Method

In order to apply the MDI Method, the different steps to follow are described on the UML Activity Diagram presented in Figure III.19. This Activity Diagram is made up of two main partitions. The first partition called ’Top CIM’ describes the actions to perform at the highest level of abstraction that means at the Top CIM level. The second partition called ‘Level (n-1)’ describes the actions to perform for the lower levels of abstraction and it is presented as a generic method chunk that means that the same sequence of actions is performed at the Bottom CIM, PIM, PSM and Code levels.

Deliverable DTG2.3

60/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.19. UML Activity Diagram showing the steps of the MDI Method

Deliverable DTG2.3

61/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

The two main supports of the MDI Method that means the Interoperability Model and the Common Ontology are represented as object nodes: the Common Interoperability Ontology is presented as a single object node because it is used as a reference support all along the development of the MDI Method, and it is enriched when the lower levels of abstraction models are built. Besides, the Interoperability Model is represented by an object node at each level of abstraction according to the MDA approach in which a distinct model is built at each level by both, a transformation of the model at the upper level, and an enrichment of the model with additional information. For example, the Interoperability Model at the PSM level is obtained by the transformation of the Interoperability Model at the PIM level including information about the targeted platform. The main workflows of the proposed method are described in the following sections.

III.5.2.1

Top CIM Partition

The first main step consists in establishing the AS-IS model in order to obtain comparable models making it possible to produce the Interoperability Model at the Top CIM Level. The objective of this step is to arrive to the situation represented in Figure III.20 on witch the lower part represents the goal to reach, that means the interoperability at code level. Enterprise E1 Top CIM Level

Code Level

Enterprise E2

ESA 1

Interoperability Model (TCIM)

ESA 2

ESA 1

Interoperability code

ESA 2

Figure III.20 Interoperability Model developed at the Top CIM level

Several cases are studied according to the existence or absence of Enterprises Models (EM) in the both enterprises. If such models do not exist in both or are missing in one, all the models must be created using the same Enterprise Modelling Language (EML). If enterprise models exists in both enterprise, the actions to perform depends on the fact that the same EML is used or not. If the two EML are different, POP* and UEML approaches can be used as common support and then the specific enterprise models are imported/exported. In the other cases, a Deliverable DTG2.3

62/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

dedicated transformation must be developed in order to ’convert’ the models into a common basis. The generic method to build this transformation is presented on the Activity Diagram shown in Figure I.5. After this first main step, we get comparable enterprise models and the Interoperability Model at the Top CIM Level can be built. The second main step consists in defining the Common Interoperability Ontology. As for the previous step, several cases are studied depending on the existence or not of the ontological models in both enterprises. Depending on the case, the Common Interoperability Ontology will be built from scratch or by merging, aligning, transformation, etc. of the existing ontologies. At the end of this first part of the MDI Method the Interoperability Model at the Top CIM level and the Common Interoperability Ontology are built.

III.5.2.2

Level (n-1) Partition

This partition is a ‘generic’ partition that is to say that all the actions in this partition are performed iteratively for all lower levels of abstraction (Bottom CIM, PIM, PSM, and Code). The first action consists in transforming the Interoperability Model at the upper level (for example: Top CIM level) into an Interoperability Model at the current level (for example: Bottom CIM level) according to a ’classical’ MDA approach that means by adding all additional knowledge needed to produce this model. The obtained state is represented in Figure III.21. Enterprise E1 Top CIM Level

ESA 1

Enterprise E2 Interoperability Model (TCIM)

ESA 2

transformation

Interoperability Model (BCIM)

Code Level

ESA 1

Interoperability code

ESA 2

Figure III.21 Transformation of the Interoperability Model at the Bottom CIM level

Deliverable DTG2.3

63/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Then the existence of models for the both enterprises at this abstraction levels is checked. If no such models exist (are shown in Figure III.21), then they are produced from three sources: the models at the upper level, the Interoperability Model just obtained at the current level and all additional ‘external’ knowledge. Therefore, the horizontal interoperability between the models of the both enterprise models is automatically ensured through the Interoperability Model and the consistency with the upper level in ensured thanks to the MDA approach. The obtained state is shown in Figure III.22. Enterprise E1 Top CIM Level

Enterprise E2 Interoperability Model (TCIM)

ESA 1

transformation

transformation

ESA 2 transformation

Bottom CIM Level

ESA 1

Interoperability Model (BCIM)

ESA 2

Code Level

ESA 1

Interoperability code

ESA 2

Figure III.22 Transformation of enterprise models at the Bottom CIM level from the model at the Top CIM level and the Interoperability Model

If models pre-exist (as shown in Figure III.23) for the enterprise at the current level, then state obtained after the transformation of the Interoperability Model from Top CIM to Bottom CIM level is represented in Figure III.24. There fore it is necessary to develop horizontal transformations between the Interoperability Model and the existing models as shown in Figure III.25.

Deliverable DTG2.3

64/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Enterprise E1 Top CIM Level

Enterprise E2 Interoperability Model (TCIM)

ESA 1

transformation

transformation

Bottom CIM Level

ESA 1

Code Level

ESA 1

ESA 2

ESA 2

Interoperability code

ESA 2

Figure III.23 Pre-existing enterprise models at the Bottom CIM level

Enterprise E1 Top CIM Level

Enterprise E2 Interoperability Model (TCIM)

ESA 1

transformation

transformation

ESA 2 transformation

Bottom CIM Level

ESA 1

Interoperability Model (BCIM)

ESA 2

Code Level

ESA 1

Interoperability code

ESA 2

Figure III.24 Transformation of the Interoperability Model from Top CIM to Bottom CIM levels

Deliverable DTG2.3

65/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Enterprise E1 Top CIM Level

Enterprise E2 Interoperability Model (TCIM)

ESA 1

transformation

transformation

ESA 2 transformation

Bottom CIM Level

ESA 1

Interoperability Model (BCIM)

ESA 2

Code Level

ESA 1

Interoperability code

ESA 2

Figure III.25 Development of horizontal transformations between the Interoperability Model and the two pre-existing enterprise models

After this step, the updating of the Common Interoperability Ontology is performed if needed. The process described in this partition can be then re-applied for the lower levels of abstraction to go from the Bottom CIM level to the Code level and then to obtain a complete horizontal interoperability at each level as presented on the Reference Model shown in Figure III.17. The Method is made up of four phases, and each phase has particular activities as shown in Table III.10.

Deliverable DTG2.3

66/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Phase I

II

TCIM2BCIM

BCIM2PIM

Process Workflow

Techniques

Expected Outcomes

Examples of Supporting Tools

Interoperability Model Definition • To capture enterprise knowledge • To compare and determine the interoperability needs for business, processes, services and data

GRAI, IEM, EEM, ARIS Language, CIMOSA UEML, POP*

Points of Interoperability represented in the Interoperability Model at the TCIM level (model TO-BE)

GraiTools 1.0, MO2GO, Metis, ARIS Process Platform, Cim Tool, etc.

Common Interoperability Ontology Definition • To define Business Vocabulary • To perform ontology engineering

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Enterprise Interoperability Model at the BCIM level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Interoperability Model Definition • To define computer system requirements

UML for Enterprise Modelling Software Engineering

Points of Interoperability represented in the Interoperability Model at the PIM level

MagicDraw CE 11.5, Poseidon CE 4.2.1-0, Visual Paradigm for UML 5.2 Community Edition, StarUML 5.0, Eclipse/Omondo, Objecteering PE 6.0.0, IBM Rational Software Modeller, etc.

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages:

Enterprise Interoperability Model at the PIM level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+,

Deliverable DTG2.3

67/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

transformations

III

IV

PIM2PSM

PSM2Code

Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Kermeta, etc.

Interoperability Model Definition • To define the features of the target specific platform

UML (PIM4SOA)

Points of Interoperability represented in the Interoperability Model at the PSM level

MagicDraw CE 11.5, Poseidon CE 4.2.1-0, Visual Paradigm for UML 5.2 Community Edition, StarUML 5.0, Eclipse/Omondo, Objecteering PE 6.0.0, IBM Rational Software Modeller, etc.

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages: Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Enterprise Interoperability Model at the PSM level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Interoperability Model Definition

Java, Database (SQL), Process Engine (BPEL), Interfaces Functionalities (WSDL/ERP), Rule Engine (Ilog Rules)

Common Interoperability Ontology Definition • To enrichment process of the defined ontology

Brainstorming, meetings, SBVR, ontology engineering techniques

Common Interoperability Ontology

Protégé, A*, ATHOS, etc.

Model Transformation • To develop and/or get metamodels • To create mappings • To implement and execute transformations

• General purpose programming languages: Java, C#, etc. • Generic transformation tools: graph transformations, XSLT, etc. • CASE tools scripting languages:

Enterprise Interoperability Model at the Code level

• Dedicated model transformation tools: ADT, MTF, MTL, Semaphore, etc. • Metamodelling tools: Metacase, MetaEdit+, Kermeta, etc.

Deliverable DTG2.3

Java, Database (SQL), Process Engine (BPEL), Interfaces Functionalities (WSDL/ERP), Rule Engine (Ilog Rules)

68/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Objecteering, Rose, etc. • Dedicated model transformation languages: OMG QVT style , ATL, etc.

Table III.10. Phases and Activities of the MDI Method

Deliverable DTG2.3

69/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.5.3

Conclusion

In this section, the main principles of the MDI Method have been shown. A detailed description of the process workflows that made up the method, which can be applied in an iterative way, has been described. Moreover, a step by step description of its application is provided together with the description of the phases, process workflows, expected outcomes, and possible techniques and tools for using it.

III.6 Application to the Case Study In order to tackle the problem of horizontal interoperability, the Case Study ‘Demo TelCo’ of the DTG2.1 has been extended. The first case study was devoted to parameterisation of an ERP of the Telco Company. This second case study is related to the ‘integration’ of Enterprise Software Applications (ESA) of the main branch of the Telco Company and its subcontractors (Franchisees and Dealers). The organisation of the Telco Company is the following (see Figure III.26): •





The main branch of the Telco Company (called ‘franchisor’ in the following) owns several ESA (ERP, CRM, WMS, etc.) to manage its activities and centralise data about end-customers, products, warehouses, etc. In order to distribute its products and services the franchisor has set up a network of distributors playing the role of front-end for end-customers. Two kinds of distributors exist mainly: franchisees and dealers. The franchisees are distributors with an exclusivity contract with the franchisor: they can only propose products and services related to the Telco Company to end-customers. In order to manage their activities, the franchisor provides the franchisees with ESA (Retail system, CRM, etc. but with limited functionalities) compatible with the ones of itself. The problem is then to define a complete interoperability between the applications especially between the local versions of the CRM and Retail System and the franchisor’s ERP and CRM; and also to achieve this interoperability at business and ontological level. The dealers are distributors which can contract with other companies than Telco. They may have their specific ESA, and therefore, the problem is to define the interoperability needs and make the dealers’ applications interoperable with the ones of the franchisor within a heterogeneous context.

Deliverable DTG2.3

70/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Franchisor ERP

CRM

WMS

Other

INTRANET Retail CRM System Lim.

Retail CRM System Lim.

Franchisee (Store)

Franchisee (Store)

Specific Retail Specific System CRM Dealer (Store)

Customers

Figure III.26. Schema of the Case Study Extended

The proposed approach to solve these interoperability problems is first to identify different categories of business processes interconnection and integration from the franchisor and the distributors side. In the context of the Case Study Extended, two categories of business processes have been identified: •

Dependent processes: that means when the relationship is established between the franchisor and the franchisee. In this case, the whole process is distributed on the two sides. The challenge is to provide the whole process in the both applications (see Figure III.27).

Franchisor

Franchisee

A “dependant” Business Process Between the 2 entities

Provide the whole BP in both tools Figure III.27. Dependent business process

Deliverable DTG2.3

71/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software



Independent processes: that means when the relationship is established between the franchisor and the dealer. In this case, before the interaction between the franchisor and the dealer, the two parts have their own independent processes (see Figure III.28).

Franchisor

Dealer

Figure III.28. Independent business process, initial state

The challenge is then, first, to identify the interoperability needs, and second, to make the applications interoperable (see Figure III.29).

Deliverable DTG2.3

72/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Franchisor

Dealer New Activity

Interoperability Need

Interoperability Model Figure III.29. Independent business process, final state

III.6.1

Selected Scenario

This section gives an overview of he selected scenario. It describes first the after sales service process and then the related interoperability needs.

III.6.1.1

’After Sales Service Process’

The after sales service is according to the previous classification an Independent Business Process between Franchisor and Dealer, and it deals mostly with customer service requests and repairs. Regarding repairs, their handling is mostly performed from the CRM application due to the fact that the procedure is executed from front-end personnel (e.g. employees in a department store, etc.), who use the CRM application. Therefore in this scenario the following partners are involved: • •

Franchisee/Dealer (Store) BP: The store receives a request for repair from a customer and it decided to send the product to the Franchisor for service. Franchisor BP: The Franchisor receives the request for service, proceeds to the repair, issues the delivery note and sends the product back to the store.

III.6.1.2

Interoperability Needs for the ’After Sales Service Process’

Interoperability needs cover the following: •

Update CRM with customer transactions: This information is useful because provides input to the CRM users about the customer’s behaviour to the enterprise. For example, in order to define a Service Level Agreement, the company needs to know Deliverable DTG2.3

73/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

• •

how active the customer was in terms of sales, support, etc. so it can define its support strategy. This kind of information will also be helpful to the sales personnel in terms of definition of a sales campaign, promotion strategy, etc. It is implied that this type of information can be used at any time and at any phase of the value chain. Creation of ERP documentation from CRM: CRM needs to send the appropriate set of data to the back office application (ERP) in order to produce the necessary documentation (Packaging slips, invoices, etc.). Update CRM with customer transactions, as described above.

Interoperability needs are summarised as follows for ‘Integrated Service Requests and Repairs’ business process in the chain. For this integration, a detailed scenario is provided: • • • • •

• •

• •

The end-customer gives the store the problematic device. The stores give the customer a ‘receipt’ and prepare and forward a “service request” to the service department of the store. The service department of the store searches for the problem. IF the service department of the store identifies the problem THEN it informs the endcustomer about the cost of the service. ELSE The service department is unable to identify the problem and send the device to the franchisor service department. o The franchisor gives the store ’receipt’. o The service department of the franchisor informs the service department of the store about the cost. It informs the end-customer about the cost of the service. The end-customer accepts the cost. (If not he take back the device from the store). o The service department of the franchisor fixes the problem. o The franchisor charges the store (franchisee/dealer) and issues an invoice and sends the fixed device to the store. [The service department fixes the problem]. The store charges the service, issue an invoice and give the fixed device back to the end-customer.

III.6.2

Models Performed Following the MDI Method

Based on the previous presented scenario, called ’After Sales Service Process’, we bring in this section the Models performed in three levels of MDA – CIM, PIM and PSM - following the proposed MDI Method. Class Diagrams were developed first for each independent process (from Franchisor and from Dealer point of view) and then we introduce the Class Diagram Model after the highlighting of interoperability needs.

III.6.2.1

Bottom CIM Models using UML

III.6.2.1.1

Activity Diagram at the Bottom CIM Level

Figure III.30 depicts the two independent processes concerning the after sale service managed by the Franchisor and the Dealer before interoperability needs. In this case, no electronics exchanges are performed, that means that no data are directly exchanged between the Deliverable DTG2.3

74/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

software systems. The objective is then to improve this process by highlighting interoperability needs.

Figure III.30. Independent processes before interoperability needs detected

Figure III.31 depicts Independent Business Process between Franchisor and Dealer after Interoperability Needs Detected.

Deliverable DTG2.3

75/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.31. Independent processes after interoperability needs detected

III.6.2.1.2

Class Diagram at the Bottom CIM Level

A. ’After Sales Service Process’ from Dealer Point of View Figure III.32 depicts the class diagram that describes the data in the case where a customer goes to a dealer for product repairing. Information about customer is inserted if it does not exist; address is needed for invoice issuing, and the customer can be contacted by phone, SMS or mail. Some comment can be typed about the repairing, and information has to be given about customer contacts in order to follow the history of exchanges with him/her. A customer receipt is issued when he/she brings the phone to be repaired (this document includes the customer name, phone serial number, problem description, date of receipt issue). When the customer picks up his/her repaired phone, an invoice can be issued for the payment if the phone is no more under guarantee.

Deliverable DTG2.3

76/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.32. Class Diagram at the CIM level for ‘After Sales Service Process’ from Dealer point of view

B. ’After Sales Service Process’ from Franchisor Point of View Figure III.33 depicts the class diagram that represents the data needed in order to manage the case where the product is sent from a dealer to the franchisor to be repaired. Three cases may occur: 1. The product is repaired successfully and is returned to the dealer with an invoice; several products for the same dealer can be grouped in a global invoice (the VAT rate can differ from a product to another). 2. The product cannot be repaired; it is sent to a supplier. Several products can also be grouped, but the date of return is given for each product individually (it can be different from a product to another even if they have been sent in the same time). 3. In the previous case, if the supplier cannot repair the product, this last is destroyed (a new product has to be given to the customer).

Figure III.33. Class Diagram at the CIM level for ’After Sales Service Process’ from Franchisor point of view

Deliverable DTG2.3

77/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

C. ’After Sales Service Process’ Showing Interoperability between Franchisor and Dealer The purpose is to make possible direct data exchanges between Franchisor and Dealer information systems; for that, the two databases must be compatible. As one can notice in previous class diagrams, the two models are different. In this case study, these differences, that we can also call Interoperability Problems, can be summarised as following: 1. Two classes have the same name but contain some different data, for example the classes RepairRequest. 2. A class appears in franchisor viewpoint, but not in dealer viewpoint that does not need this class, for example Supplier and ExportInvoice. 3. The structure of information differs between the two class diagrams (for example Invoice for which an unique class exists in the dealer class diagram (an invoice per product) and two classes (Invoice and Export Invoice) appears in franchisor class diagram (an invoice can group several products). 4. Several data have different names but are synonym (Phone and Product, serialNumber and productReference). More generally, other differences should appear between two data structures (at entities and relation levels). In the present case study, the proposed approach consists in the ‘bridge class diagram’ design: the interoperability class diagram witch is considered as ontology. The method consists in franchisor and dealer interview in order to formalize the common points and the differences of semantic aspects and to agree on a common syntax. Figure III.34 depicts the proposal of the ‘bridge class diagram’ between Franchisor and Dealer.

Deliverable DTG2.3

78/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

Figure III.34. Class Diagram at the CIM level ’After Sales Service Process’ showing interoperability between Franchisor and Dealer

In the previous class diagram, the two classes RepairRequest are clearly separated and the attributes names are unified; the two classes, previously homonyms, cover different data. The classes Phone / Product were now called Item. These are several activities performed to solve some of the interoperability problems.

III.6.2.2

PIM Models using UML

III.6.2.2.1

Class Diagram at the PIM Level

In Figure III.35, Figure III.36 and Figure III.37 we show the Class Diagrams obtained from the transformation of the previous diagram at the Bottom CIM level to PIM level. To perform this transformation we have followed the same procedure explained in previous sections, but taking into account that the transformation is simpler in this case, since is UML to UML at different level of abstraction. Two mainly steps were carried out when the transformations were done:

Deliverable DTG2.3

79/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

1. When we pass from CIM level to PIM level we need to detail some attributes and operations of the classes. 2. We need to include new classes that do not appear in the conceptual level, but they are needed at PIM level. A. ’After Sales Service Process’ from Dealer Point of View

Figure III.35. Class Diagram at the PIM level for ’After Sales Service Process’ from Dealer point of view

Deliverable DTG2.3

80/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

B. ’After Sales Service Process’ from Franchisor Point of View

Figure III.36. Class Diagram at the PIM level for ’After Sales Service Process’ from Franchisor point of view

Deliverable DTG2.3

81/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

C. ’After Sales Service Process’ Showing Interoperability between Franchisor and Dealer

Figure III.37. Class Diagram at the PIM level for ’After Sales Service Process’ showing interoperability between Franchisor and Dealer

Deliverable DTG2.3

82/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.6.2.3

PSM Models using UML

To perform a model transformation from PIM level to a PSM level we had first to define the platform within the PDM. Figure III.38 depicts some possibilities that can be done when this transformation is going to be performed.

PIM

PDM

TRANSFORMATION PSM

PSM

PSM

PSM

ERP Singular

ERP Microsoft

ERP SAP

ERP Other

Navision Figure III.38. Possible transformations from PIM and PDM to PSM Models

In this Case Study, we have chosen the platform ERP Microsoft Navision, to be used as reference on our PSM Model. Microsoft Dynamics NAV is an enterprise resource planning (ERP) software product from Microsoft. The product is part of the Microsoft Dynamics family [47]. It has gone through several name changes since 1995 as the original Navision company or Microsoft has tried to decide on how it should be marketed. This means that the names ’Navision Financials’, ’Navision Attain’, ’Microsoft Business Solutions Navision Edition’, and the current (2006) ’Microsoft Dynamics NAV’ all refer to essentially the same product.It is intended to assist with finance, manufacturing, customer relationship management, supply chains, analytics and electronic commerce in Small and Medium-sized Enterprises. However, due to the fact that VARs (and customer if they pay for it) have full access to the business logic source code it can be ’extensively customised’. In Figure III.39, Figure III.40 and Figure III.41, we show the Class Diagrams obtained from the transformation of the previous diagram at the PIM level to PSM level. To perform this transformation we have followed the same procedure explained in Section III.6.2.1, and taking into account some attributes/operations used on Microsoft Navision ERP. In the transformation one attribute can become two or more, and new operations can appear, in agreement with the chosen platform.

Deliverable DTG2.3

83/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.6.2.3.1

Class Diagram at the PSM Level

A. ’After Sales Service Process’ from Dealer Point of View

Figure III.39. Class Diagram at the PSM level for ’After Sales Service Process’ from Dealer point of view

Deliverable DTG2.3

84/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

B. ’After Sales Service Process’ from Franchisor Point of View

Figure III.40. Class Diagram at the PSM level for ’After Sales Service Process’ from Franchisor point of view

Deliverable DTG2.3

85/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

C. ’After Sales Service Process’ Showing Interoperability between Franchisor and Dealer

Figure III.41. Class Diagram at the PSM level for ’After Sales Service Process’ showing interoperability between Franchisor and Dealer

Deliverable DTG2.3

86/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

III.6.3

Conclusion

In this section, the models on the selected scenario of the Case Study Extended performed at different levels of abstraction are shown. All the class diagrams can be used to define and enrich the Common Interoperability Ontology by using UML to OWL transformation. All these models have been manually performed but the experiments on model transformations have demonstrated that it can be automated or widely computed aided.

Deliverable DTG2.3

87/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

IV REFERENCES [1]

INTEROP (2005), 'Report on Model Establishment', Task Group 2. 'Model Driven Interoperability' of INTEROP NoE.

[2]

Grangel, R.; Bourey, J.P. & Berre, A. (2006), Solving Problems in the Parameterisation of ERPs using a Model-Driven Approach. In: Interoperability for Enterprise Software and Applications Conference (I-ESA’06).

[3]

INTEROP (2006), 'Report on Model Interoperability’, Task Group 2. 'Model Driven Interoperability' of INTEROP NoE.

[4]

Ralyté, J., Jeusfeld, M., Backlund, P., Kühn, H., Goossenaerts, J., Elvesæter, B., ArniBloch, N., Lillehagen, F., (2006) INTEROP Method Repository. Deliverable DTG6.2, INTEROP Network of Excellence IST - 508011.

[5]

Ralyté J., Backlund P., Kühn H., Jeusfeld M. (2006). Method Chunks for Interoperability. Proceedings of the 25th International Conference on Conceptual Modelling (ER'2006). Tucson, Arizona, USA, November 6-9 2006. LNCS 4215, Springer, pp. 339-353.

[6]

LINA (2007). ‘ATLAS: Atlas Transformation Language http://www.sciences.univ-nantes.fr/lina/atl/ (Accessed 2007-04).

[7]

Grangel Seguer R., Ben Salem R., Bigand M., Bourey J.P.,’Interopérabilité guidée par les modèles: transformations de modèles GRAI en modèles UML’, 7ème Congrès International de Génie Industriel, Québec, CANADA, Trois- Rivières, Juin 2007.

[8]

Grangel R., Ben Salem R., Bourey J.P., Daclin N., Ducq Y. ‘Transforming GRAI Extended Actigrams into UML Activity Diagrams: a First Step to Model Driven Interoperability’, I-ESA 07, 3rd International Conference on Interoperability for Enterprise Software and Applications, Enterprise Interoperability II, New Challenges and Approaches, ISBN 978-1-84628-857-9, Springer, Madeira (Portugal), pp447-458, Mars 2007.

[9]

Grangel R., Correa K., D'Antonio F., Bourey J.P., Berre A. J. ’Analysing CIM2PIM Approaches to Improve Model Driven Interoperability’, I-ESA 07, 3rd International Conference on Interoperability for Enterprise Software and Applications, Enterprise Interoperability II, New Challenges and Approaches, ISBN 978-1-84628-857-9, Springer, Madeira (Portugal), pp115-118, Mars 2007.

[10]

Cutting-Decelle A.F., Young R.Y., Michel J.J., Grangel Seguer R., Le Cardinal J., Bourey J.P., "ISO 15531 MANDATE: A Product-Process-Resource Based Approach for Managing Modularity in Production Management", Concurrent Engineering: Research and Application Journal, Accepted, to be published in 2007.

Deliverable DTG2.3

(ATL)’,

88/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

[11]

C. Hahn, C. Madrigal-Mora, K. Fischer, B. Elvesæter, A.-J. Berre, and I. Zinnikus, ’Meta-models, Models, and Model Transformations: Towards Interoperable Agents’, in Multiagent System Technologies, Lecture Notes in Computer Science, vol. 4196, Berlin/Heidelberg, Springer, 2006, pp. 123-134.

[12]

A. Limyr, T. Neple, A.-J. Berre, and B. Elvesæter, ’Semaphore – A Model-Based Semantic Mapping Framework’, in Business Process Management Workshops, Lecture Notes in Computer Science, vol. 4103, Berlin/Heidelberg, Springer, 2006, pp. 275-284.

[13]

K. Fischer, B. Elvesæter, A.-J. Berre, C. Hahn, C. Madrigal-Mora, and I. Zinnikus, ‘Model-Driven Design of Interoperable Agents’, in Proc. of the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006, Interoperability for Enterprise Software and Applications, ISTE, pp. 119-130.

[14]

K. Arnarsdóttir, A.-J. Berre, A. Hahn, M. Missikoff, F. Taglino, Semantic mapping: ontology-based vs. model-based approach Alternative or complementary approaches?, EMOI’2006, during CAISE’2006, June 2006, Luxembourg.

[15]

Bourey J.P., Grangel Seguer R. ‘From Model Transformation to Model Driven Interoperability’ Tutorial A3, I-ESA 07, 3rd International Conference on Interoperability for Enterprise Software and Applications, Madeira (Portugal), Mars 2007.

[16]

INTEROP (2005), ‘State of the art of methods to derive IT specifications from models and to develop IT specific components based on IT modelling’.

[17]

Berners-Lee T., Hendler J., Lassila O. (2001) The Semantic Web. Sci Am 284(5):34– 43

[18]

World Wide Web Consortium: http://www.w3.org/

[19]

Stefan Decker, Sergey Melnik, Frank Van Harmelen, Dieter Fensel, Michel Klein, Jeen Broekstra, Michael Erdmann, and Ian Horrocks. The semantic web: The roles of xml and rdf. IEEE Expert, 15(3), October 2000. http://citeseer.ist.psu.edu/decker00semantic.html

[20]

Resource Description http://www.w3.org/RDF/

[21]

I. Horrocks, P. F. Patel-Schneider, and F. van Harmelen. From SHIQ and RDF to OWL: The making of a web ontology language. Journal of Web Semantics, 1(1):7-26, 2003. http://citeseer.ist.psu.edu/horrocks03from.html

[22]

McGuinness, D. et al. (2004). OWL Web Ontology Recommendation, http://www.w3.org/TR/owl-features/

[23]

RDF Schema, W3C Specification 1.0. http://www.w3.org/TR/rdf-schema

Framework

(RDF),

Deliverable DTG2.3

W3C

Recommendation.

Language.

W3C

89/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

[24]

V. Haarslev and Ralf Moller. Description of the racer system and its applications. In Proceedings of the International Workshop in Description Logics 2001 (DL2001), Stanford, USA, August 2001. http://citeseer.ist.psu.edu/article/haarslev01description.html

[25]

I. Horrocks, U. Sattler, and S. Tobies. Practical reasoning for description logics with functional restrictions, inverse and transitive roles, and role hierarchies. In Proceedings of the 1999 Workshop Methods for Modalities (M4M-1), Amsterdam, 1999. http://citeseer.ist.psu.edu/horrocks99practical.html

[26]

I. Horrocks, U. Sattler, and S. Tobies. Practical reasoning for very expressive description logics. Logic Journal of the IGPL, 8(3):239–263, 2000

[27]

XSL Transformations http://www.w3.org/TR/xslt

[28]

Jena A Semantic Web Framework for Java. http://jena.sourceforge.net/

[29]

Andrea Corradini, Hartmut Ehrig, Reiko Heckel, Michael Lowe, Ugo Montanari, and Francesca Rossi. Algebraic approaches to graph transformation part I: Basic concepts and double pushout approach. In Grzegorz Rozenberg, editor, Handbook of Graph Rewriting. Vol. I: Foundations. World Scientific, 1996. http://citeseer.ist.psu.edu/corradini96algebraic.html

[30]

TG3 MoMo: Toolbox definition and Workshop report DTG3.3, http://interopnoe.org/.

[31]

Grangel, R.; Bourey, J.P.; Chalmeta, R. & Bigand, M. (2006), UML for Enterprise Modelling: a Model-Driven Approach. In: Interoperability for Enterprise Software and Applications Conference (I-ESA’06).

[32]

Kontio, M.: Architectural manifesto: MDA for the enterprise, http://www128.ibm.com/developerworks/library/wi-arch16/index.html (2005) (Accessed 200704).

[33]

Vernadat, F.B.: Enterprise Modeling and Integration: Principles and Applications. Chapman and Hall (1996).

[34]

Ambler, S. W., Nalbone, J., Vizdos,M.J.,: The Enterprise Unified Process: Extending the Rational Unified Process http://www.enterpriseunifiedprocess.com/ (Accessed 2007-04).

[35]

COMBINE, ’Component-based Interoperable Enterprise System Development’ IST1999-20893, http://www.opengroup.org/combine/ (Accessed 2007-04).

[36]

A.-W. Scheer: Aris – Business Process Modeling. Third Edition, Springer-Verlag, Heidelberg, Germany, ISBN 3-540-65835-1.

Version

1.0,

Deliverable DTG2.3

W3C

Recommendation.

90/91

INTEROP Interoperability Research for Networked Enterprises Applications and Software

[37]

Global, S. (2007). Technology Audit. http://www.ssaglobal.com/documents/SSA%20ERPLN%20Report_Butler%20Group_ Mar06.pdf . (Accessed 2007-04).

[38]

UEML: Deliverable D1.1. Report on the State of the Art in Enterprise Modelling. http://www.ueml.org (2002) (Accessed 2007-04).

[39]

OMG: MDA Guide Version 1.0.1. Object Management Group. Document number: omg/2003-06-01 edn. (2003).

[40]

OMG (2007). Semantics of Business Vocabulary and Business Rules Specification, first Interim Specification. http://www.omg.org/docs/dtc/06-08-05.pdf. (Accessed 2007-04).

[41]

UEML: Deliverable D1.1. Report on the State of the Art in Enterprise Modelling. http://www.ueml.org (2002) (Accessed 2007-04).

[42]

ATHENA: Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications) Project (IST-2003-2004). http://www.athena-ip.org (2005) (Accessed 2007-04).

[43]

OMG: Unified Modeling Language: Superstructure, version 2.1.1. Object Management Group. Version 2.1.1 formal/2007-02-03 edn. (2007) http://www.omg.org/technology/documents/modeling_spec_catalog.htm (Accessed 2007-04).

[44]

LINA: research laboratory. http://www.sciences.univnantes.fr/lina/en/lina/acces/unantes/index.html (2007) (Accessed 2007-04).

[45]

OMG: OCL 2.0 Specification. Object Management Group. Adopted specification formal/06-05-01 edn. (2006).

[46]

S. Hendryx. Integrating Computation Independent Business Modeling Languages into the MDA with UML 2, Hendryx & Associates, January 2003. http://cs.ua.edu/630/UML%20and%20MOF%20specifications/Integrating%20Bus.%2 0Model%20Lang.%20into%20MDA%20using%20UML2%20-%20Hendryx%20%20ad-03-01-32.doc (Accessed 2007-04).

[47]

Microsoft Dynamics Navision. http://www.microsoft.com/dynamics/nav/default.mspx (Accessed 2007-04).

Deliverable DTG2.3

91/91