SHAPE - STI Innsbruck · This report presentsDeliverable D2.2 “Integrated and tool-supported...

Copyright SHAPE Consortium 2007-2010 / 123

Service and Software Architectures, Infrastructures and EngineeringSmall or Medium-scale Focused Research Project

Semantically-enabled Heterogeneous Service Architecture and Plat-forms Engineering

Acronym

SHAPEProject No

216408

UPMS Agents

Semantic WebServices

ServiceVariability

WebServices

P2P

FlexibleBusiness Models

HeterogeneousPlatforms

Grid

UPMS Agents


ServiceVariability

WebServices

P2P



Grid

UPMS Agents


ServiceVariability

WebServices

P2P



Grid

UPMS Agents


ServiceVariability

WebServices

P2P



Grid

UPMS Agents


ServiceVariability

WebServices

P2P



Grid

UPMS Agents


ServiceVariability

WebServices

P2P



Grid

Deliverable D2.2

Integrated and tool-supported Methodology– Initial Version –

Work Package 2

Leading partner: SAP

Editor: Michael Stollberg

Authors (alphabetically): Leire Bastida, Gorka Benguria, Arne-Jørgen Berre, Xu Jiu Cheng, MarisaEscalante, Simon Han, Sebastian Kämper, Marcel Muth, Dumitru Roman, Andrey Sadovykh, Omair

Shafiq, Victor Shafran, Michael Stollberg

Dissemination level: Public

Date: 14 January 2009

Version: 1.0

Public


Versioning and Contribution History

Version Description Contributors

0.1 Structure & Initial Content Michael Stollberg (SAP)

0.2 Added Section 2, outlined Sects 3, 4, 5, 6 Michael Stollberg (SAP)

0.3 Elaborated Specification (Sec 3) Michael Stollberg (SAP)

0.4 Integrated partner inputs: Sec 4 - Prototype (ESI / SAP) Victor Shafran (SAP)Leire Bastida (ESI)Michael Stollberg (SAP)

0.5 Sec 6: integrated partner inputs SAP, DFKI, UIBK Sebastian Kämper (DFKI)Dumitru Roman (UIBK)Marcel Muth (SAP)Michael Stollberg (SAP)

0.6 Added Sec 5 (SoaML Methodology Example) Arne J. Berre (SINTEF)Michael Stollberg (SAP)

0.7 Completed SHAPE Reference Matrix Andrey Sadovykh (SOFTEAM)Gorka Benguria (ESI)Omair Shafig (ESI)Klaus Fischer (DFKI)Arne J. Berre (SINTEF)Michael Stollberg (SAP)

0.8 Completed Method Library Victor Shafran (SAP)Michael Stollberg (SAP)Leire Bastida (ESI)Simon Han (SINTEF)Xu Jiu Cheng (SINTEF)

0.9 Completed document for internal review) Victor Shafran (SAP)Michael Stollberg (SAP)

1.0 Final editing Michael Stollberg (SAP)

Public


Executive SummaryThis report presents Deliverable D2.2 “Integrated and tool-supported Methodology – Initial Version” ofthe SHAPE project. It is the second deliverable of Work Package 2 (WP2), including the results ofTasks T2.1 – T2.4, and T2.6 as defined in the Description of Work [SHAPE 2007].

The deliverable presents the initial version of the SHAPE Methodology, which provides guided proce-dures for the model-driven development of SOA systems along with extensions for adaptability andtowards heterogeneous technologies. Instead of developing a new methodology from scratch, wedesign approach for the SHAPE Methodology is to integrate several existing methodologies from re-lated technology fields into a generic framework that allows end-users (e.g. business analysts, systemarchitects, and developers) to create customized methodologies for their individual SOA system engi-neering projects by using the model-driven techniques that are developed in the SHAPE project.

For this, the deliverable presents the first version of the overall framework along with a prototype im-plementation of the tool support for end-users. In particular, it defines the overall technical architectureof the SHAPE Methodology, specifies the metamodel for describing methodology fragments and theircorrelation with the SHAPE techniques, and presents the initial content of the SHAPE methodologylibraries, which is obtained from a detailed analysis of 22 existing methodologies that have been iden-tified as promising candidates in the preceding requirements and state-of-the-art analysis. The proto-type implementation provides initial support for the creation of customized methodologies by end-users as well as the management of the methodology libraries. For the initial version, we focus on thesupport for developing SOA systems by using the model-driven techniques that are developed withinthe SHAPE project. The future versions will refine the SHAPE Methodology framework, extend it toinclude methodological support for modelling service variability, for employing semantic technologies,and as well as for supporting deployment on heterogeneous technology platforms.

The main content of this deliverable can be summarized as follows:

Refined overall approach for the SHAPE Methodology

Definition of the SHAPE Reference Matrix, providing a concise overview of the developedtechnologies and serving as the overall integration view of the project (initial version)

Definition of SHAPE Methodology framework and technical architecture

Detailed analysis of the 22 existing methodologies previously identified as suitable candidates(this document contains the aggregated results; details in an accompanying document)

Specification of the SHAPE Methodology Libraries (initial version)

Implementation of the SHAPE Methodology Tool (first version)

Illustrative examples for the methodological system development with SoaML

Outlook to refinements & extensions in the follow-up versions.

The allocation of this deliverable in the overall context of the SHAPE project is as follows: WP 2 fo-cuses on an integrated tool-supported methodology for designing flexible business systems on het-erogeneous SOA platforms. This deliverable builds upon the results of the preceding deliverable D2.1,which outlined the overall approach for the SHAPE Methodology and provided a comprehensive state-of-the-art analysis. For the specification of the SHAPE Methodology, the deliverable further considersthe results of the use case requirements from WP 1 (D1.1), the meta-models defined in WP 3 (D3.1,D3.2), the SHAPE tools developed in WP 4 (D4.1), and the model transformations specified in WP 5.

Public


Table of ContentsEXECUTIVE SUMMARY ............................................................................................................................. 3

TABLE OF CONTENTS................................................................................................................................ 4

LIST OF FIGURES........................................................................................................................................ 7

1 INTRODUCTION ................................................................................................................................. 9

1.1 OBJECTIVE ...................................................................................................................................... 9

1.2 POSITIONING IN PROJECT ............................................................................................................... 10

1.3 OUTLINE ....................................................................................................................................... 12

2 OVERVIEW AND APPROACH......................................................................................................... 13

2.1 AIM AND APPROACH ..................................................................................................................... 13

2.2 THE SHAPE REFERENCE MATRIX ................................................................................................. 14

2.2.1 Definition................................................................................................................................. 14

2.2.2 Related Work ........................................................................................................................... 16

2.3 SHAPE METHODOLOGY................................................................................................................ 17

2.3.1 Methodology Framework ......................................................................................................... 18

2.3.2 Development Roadmap............................................................................................................. 21

3 SHAPE METHODOLOGY SPECIFICATION.................................................................................. 23

3.1 ARCHITECTURE SPECIFICATION ..................................................................................................... 23

3.2 DISCIPLINE LIBRARY (INITIAL VERSION) ........................................................................................ 24

3.2.1 Discipline Description Model ................................................................................................... 24

3.2.2 System Engineering Disciplines................................................................................................ 24

3.3 METHOD LIBRARY (INITIAL VERSION) ........................................................................................... 26

3.3.1 Method Description Model....................................................................................................... 27

3.3.2 Method Collection – Overview ................................................................................................. 27

3.3.3 Method Descriptions ................................................................................................................ 31

4 SHAPE METHODOLOGY TOOL..................................................................................................... 43

4.1 TECHNICAL ARCHITECTURE........................................................................................................... 43

4.2 CONTENT SPECIFICATION .............................................................................................................. 44

4.2.1 UMA Model ............................................................................................................................. 44

4.2.2 Illustrative Example ................................................................................................................. 44

4.3 PROTOTYPE – INITIAL VERSION ..................................................................................................... 46

4.3.1 Methods................................................................................................................................... 46

4.3.2 Disciplines and Tasks............................................................................................................... 46

4.3.3 Additional Information ............................................................................................................. 48

5 ILLUSTRATIVE EXAMPLE – A SOAML METHODOLOGY ....................................................... 50

5.1 OVERVIEW .................................................................................................................................... 50

5.1.1 SoaML – Executive Overview ................................................................................................... 50

Public


5.1.2 SoaML Methodology ................................................................................................................ 52

5.1.3 Outline..................................................................................................................................... 53

5.2 BUSINESS MOTIVATION MODELLING WITH BMM........................................................................... 53

5.2.1 BMM – Business Motivation Metamodel................................................................................... 54

5.2.2 Example Buyer / Seller Scenario............................................................................................... 54

5.3 BUSINESS PROCESS MODELING WITH BPMN.................................................................................. 56

5.3.1 Top View Description (CIM) .................................................................................................... 57

5.3.2 Bottom View Description (PIM)................................................................................................ 57

5.4 SOAML SERVICE ARCHITECTURE .................................................................................................. 61

5.4.1 SoaML Service Architecture ..................................................................................................... 61

5.4.2 SoaML Participant Architecture............................................................................................... 62

5.4.3 Capability Modelling ............................................................................................................... 63

5.5 INFORMATION MODELLING............................................................................................................ 66

5.5.1 CIM Level – Ontologies............................................................................................................ 66

5.5.2 PIM Level – Information Models .............................................................................................. 66

5.6 SOAML SERVICE MODELLING ....................................................................................................... 69

5.6.1 Service Interfaces..................................................................................................................... 70

5.6.2 Service Contracts..................................................................................................................... 73

6 FUTURE WORK................................................................................................................................. 75

6.1 FRAMEWORK – REFINEMENTS AND EXTENSIONS ............................................................................ 75

6.1.1 Advanced Description Models .................................................................................................. 75

6.1.2 Enhanced Support for Custom Methodologies........................................................................... 76

6.1.3 Extension of SHAPE Methodology Libraries............................................................................. 76

6.2 METHODOLOGY SUPPORT FOR SHA............................................................................................... 77

6.2.1 Heterogeneous Architectures.................................................................................................... 77

6.2.2 Service Variability ................................................................................................................... 79

6.3 CONTRACT COMPLIANCE CHECKING .............................................................................................. 80

6.3.1 Overview and Aim.................................................................................................................... 80

6.3.2 The SWS Choreography Method............................................................................................... 81

6.3.3 Modelling, Contracting and Enactment of Services ................................................................... 81

6.4 FLEXIBLE BUSINESS MODELLING................................................................................................... 83

6.4.1 Aim and Overview.................................................................................................................... 83

6.4.2 Flexible Business Models ......................................................................................................... 85

6.4.3 Ontology-driven Flexible Business Models as an example......................................................... 87

6.4.4 The Core Elements of Flexible Business Models ....................................................................... 91

6.4.5 Summary.................................................................................................................................. 94

7 CONCLUSIONS AND OUTLOOK .................................................................................................... 95

REFERENCES ............................................................................................................................................. 96

Public


APPENDIX ................................................................................................................................................... 99

A SOURCE METHODOLOGIES ........................................................................................................ 100

B METHODOLOGY ANALYSIS ........................................................................................................ 102

C SHAPE METHODOLOGY TOOL – AVAILABILITY AND INSTALLATION............................ 104

C.1 SCOPE ......................................................................................................................................... 104

C.2 INSTALLATION ............................................................................................................................ 104

C.2.1 Install Eclipse EPF ................................................................................................................ 104

C.2.2 Install SHAPE Methodology prototype ................................................................................... 104

C.3 CONFIGURATION ......................................................................................................................... 104

D SHAPE REFERENCE MATRIX – INITIAL VERSION................................................................. 108

E METHOD LIBRARY – ALLOCATION IN SHAPE REFERENCE MATRIX............................... 110

E.1 CIM LEVEL METHODS................................................................................................................. 110

E.2 CIM2PIM LEVEL ........................................................................................................................ 116

E.3 PIM LEVEL ................................................................................................................................. 117

E.4 PIM2PSM LEVEL........................................................................................................................ 120

E.5 PSM LEVEL ................................................................................................................................ 120

Public


List of FiguresFigure 1: SHAPE Work Packages Structure..................................................................................................... 11

Figure 2: SHAPE Reference Matrix Structure.................................................................................................. 14

Figure 3: SHAPE Reference Matrix – Structure of a Box................................................................................. 16

Figure 4: Relation SHAPE Reference Matrix to Zachman Framework ............................................................. 17

Figure 5: SHAPE Methodology Framework .................................................................................................... 19

Figure 6: SHAPE Methodology Architecture Specification.............................................................................. 23

Figure 7: Overview of SHAPE Method Library (Initial Version) ..................................................................... 30

Figure 8: UMA Description of Capability Pattern “Business Modeling” (Method: SM-1)................................. 45

Figure 9: UMA Task Descriptor Example........................................................................................................ 45

Figure 10: A BMM Motivation Model............................................................................................................. 54

Figure 11: BMM – Buyer’s Ends..................................................................................................................... 55

Figure 12: BMM – Seller's Ends...................................................................................................................... 55

Figure 13: BMM – Means of the Buyer ........................................................................................................... 56

Figure 14: Top view of BPMN Process (CIM Level) ....................................................................................... 57

Figure 15: BPMN – Choose Products .............................................................................................................. 58

Figure 16: BPMN – Search Products ............................................................................................................... 58

Figure 17: BPMN – Set Shopping Cart............................................................................................................ 59

Figure 18: BPMN – Buy Products ................................................................................................................... 59

Figure 19: BPMN – Set and Apply Payment.................................................................................................... 60

Figure 20: BPMN – Execute Payment ............................................................................................................. 60

Figure 21: BPMN – Execute Shipment ............................................................................................................ 60

Figure 22: Example SoaML Community Services Architecture........................................................................ 62

Figure 23: Example Services architecture for a participant ............................................................................... 62

Figure 24: Service Capabilities needed for processing purchase orders............................................................. 63

Figure 25: ServiceInterface realized by a Capability ........................................................................................ 64

Figure 26: The Shipper Participant realizes the Shipping Capability................................................................. 64

Figure 27: Productions Participant with two parts specified by Capabilities...................................................... 65

Figure 28: The Orders ServiceInterface exposing the Sales and Marketing Capability ...................................... 65

Figure 29: WSML Ontology Buyer-Seller Example......................................................................................... 66

Figure 30: PIM Information Model for Buyer .................................................................................................. 67

Figure 31: PIM Information Model for Seller .................................................................................................. 68

Figure 32: Services and Service Participants.................................................................................................... 69

Figure 33: Generic SoaML ServiceInterface .................................................................................................... 71

Figure 34: Example Participant with a Service Port ......................................................................................... 72

Figure 35: A Participant with Services and Requests........................................................................................ 72

Figure 36: Example of SoaML ServiceContract............................................................................................... 73

Public


Figure 37: Example SoaML Choreography...................................................................................................... 73

Figure 38: A Hierarchy of Control-flow Graphs with iterative tasks ................................................................. 82

Figure 39: The Flexible Business Model Framework ....................................................................................... 84

Figure 40: Flexible Business Model Tool ........................................................................................................ 86

Figure 41: Map Concept.................................................................................................................................. 88

Figure 42: Conceptal entities........................................................................................................................... 88

Figure 43: Model concept ............................................................................................................................... 88

Figure 44: Document concept.......................................................................................................................... 89

Figure 45: Information model and element types ............................................................................................. 89

Figure 46: Content concepts ............................................................................................................................ 89

Figure 47: The Overall Model ......................................................................................................................... 90

Figure 48: Example Purchase .......................................................................................................................... 91

Figure 49: Structure of Flexible Business Models ............................................................................................ 92

Figure 50: Import Dialog............................................................................................................................... 105

Figure 51: Select SHAPE plug-in .................................................................................................................. 106

Figure 52: SHAPE plug-in appears in EPF library ......................................................................................... 107

Figure 53: SHAPE Reference Matrix (Initial Version) ................................................................................... 109

Public


1 IntroductionThis report is Deliverable D2.2 of the SHAPE project, the second deliverable of WP 2 as defined in theDescription of Work (DoW, see [SHAPE, 2007]).

The deliverable presents the initial version of the SHAPE Methodology for model-driven engineering ofSOA systems with extensions for service variability and for heterogeneous technology platforms. Themethodology defines procedures, guidelines, and best practices for modelling the different aspects ofsuch systems. This report defines the overall approach of the SHAPE Methodology and an initial set ofmethod chunks – i.e. smaller parts for modelling a specific aspect of the overall system. The SHAPEMethodology will be subsequently elaborated and extended in subsequent deliverables throughout thecourse of the project, in accordance to the iterative development approach as defined in the DoW.

In this deliverable, we focus on the modelling and development of SOA systems using SoaML – themetamodel for describing SOA systems that has been developed in the context of the SHAPE projectand which currently is in the final stage of standardization within OMG [SoaML, 2008]. The extensionsof the SHAPE Methodology for heterogeneous architectures (SHA) as well as for variability modellingwill be presented the subsequent deliverables of WP 2.

This deliverable consists of a report along with a prototype implementation. The report defines theapproach, structure, and content of the SHAPE Methodology; the prototype provides software supportfor managing the available methods as well as customization facilities for specific usage scenarios.

The remainder of this section provides:

An introduction to the topic and objectives of the deliverable

The allocation of this deliverable within the SHAPE project, and

An outline of the report.

1.1 ObjectiveIn the field of software engineering, a methodology defines guided procedures for using specific tech-nologies and modelling techniques in order to develop a system in a regular and systematic manner.This is essential in order to provide sophisticated support for system architects, engineers, and devel-opers during the system engineering process: the methodology guides them in properly using thegiven technologies and modelling techniques, and allows them to obtain the maximal benefits for theengineering process that are inherently supported by the techniques. For this, the methodology pro-vides guided procedures for the complete system engineering process along with detailed methods forthe modelling and development of specific aspects, covering all phases from initial design to systemdevelopment and maintenance. This is usually augmented with best practices that are obtained fromalready completed system engineering projects.

The SHAPE project develops novel techniques for the model-driven engineering of service-orientedsystems along with extensions for handling service variability and support for several technology plat-forms, referred to as semantically-enabled heterogeneous service architectures (SHA). The projectresult will be a set of meta-models along with a tool suite for modelling all relevant aspects of suchsystems. The overall approach distinguishes three levels of abstraction (CIM, PIM, and PSM), andconsiders eight aspects (Information, Service, Process, Rules, Organization, Motivation, Non-functional Aspects) for describing SOA and SHA systems. This is defined in the SHAPE ReferenceMatrix wherein the abstraction levels are distinguished on the vertical axis and the eight aspects onthe horizontal axis.

The purpose of the SHAPE Methodology is to provide guided procedures for supporting the systemengineering process by using the SHAPE technologies and modelling techniques. The approach fordeveloping the SHAPE Methodology is to reuse, integrate, and extend existing methodologies. Thereason for this is that modelling techniques developed in SHAPE cover a comprehensive set of as-pects which are relevant in order to properly model, develop, and maintain SOA / SHA systems. Thisranges from Enterprise Architecture modelling towards platform-specific technology implementation

Public


models. For most of the related fields, there are already existing methodologies for supporting thesystem engineering process. With respect to this, it appears to be reasonable to use, adapt, and inte-grate existing methodologies – or at least relevant parts of these – for the SHAPE Methodology, in-stead of “re-inventing the wheel”. Thus, the SHAPE Methodology is developed by the following steps:

(1) Examine existing methodologies

(2) Decompose them into method chunks (= smaller fragments)

(3) Allocate the method chunks to the SHAPE Reference Matrix

(4) Adapt / extend existing method chunks or develop new ones for the SHAPE technology.

Regarding the overall process for system engineering with the SHAPE technology, we aim at develop-ing a generic framework that allows users (i.e. system architects, engineers, and developers) to createthe specific methodology which supports the specific application scenario best. For this, we organizethe detected method chunks in a method library and provide prototype implementation where userscan search, select, and combine the relevant method chunks into a customized methodology. Thisappears to be desirable in order to provide generic support for the engineering process of SOA / SHAsystems, because the possible application scenarios differ very much with respect to the scope, func-tionality, legacy systems, and organizational surroundings.

This deliverable presents the initial version of the SHAPE Methodology. It defines the overall approachin more detail, defines the structure of the Method Library along with an initial set of method chunks,and presents the first version of the SHAPE Methodology prototype implementation. The methodologywill be further developed within the subsequent deliverables of WP 2.

1.2 Positioning in ProjectThe following explains the position and role of this deliverable within the SHAPE project.

The SHAPE project develops a comprehensive technology for the model-driven development andengineering of semantically-enabled heterogonous service architectures, short: SHA. The result will bea set of meta-models for modelling the relevant aspects of SHA systems, a tool suite for supportingthe modelling along with (semi-)automated translations between the models on the different abstrac-tion layers (CIM, PIM, and PSM), and a methodology for guiding software architects, engineers, anddevelopers through the system engineering process. These techniques will be evaluated in pilot pro-ject from industrial use cases, and also disseminated, mainly via standardization in OMG.

Figure 1 shows the overall work package structure of the project (taken from [SHAPE, 2007]). Therelation of the technical work packages (WP 2 – 5) are as follows: WP 3 develops the meta-models fordescribing all aspects related to model-driven engineering of SOA / SHA systems; WP 4 develops thetool suite for supporting users in the creation of the respective models, and WP 5 develops the tech-niques for automated transformation of the models between the different abstraction layers.

WP 2 develops the SHAPE Methodology, which provides guided procedures for using the SHAPEmodelling techniques along with a generic framework for specifying customized engineering method-ologies as explained above. Naturally, the methodology must consider the technologies developed inthe other technical work packages, and, in consequence, is defined as the last building block of theSHAPE technology. It further shall incorporate best practices from the experiences gathered from thepilot systems built in the industrial use cases (WP 1).

In order to provide a basis for the project work and also to facilitate the integration of changes and newdevelopments during the project, the project plan defines an iterative approach for the development ofthe SHAPE Methodology (cf. DoW, [SHAPE, 2007]). In particular, the methodology will be developedwithin 4 subsequent deliverables: D2.1 provides the state-of-the-art analysis and defines the overallarchitecture, D2.2 presents the initial version of the methodology specification, D2.3 will present arefinement that will cover the extensions developed in the project, and D2.4 will represent the finalmethodology with updates and experience reports from the pilot use cases.

Public


WP7

: Pro

ject

man

agem

ent

WP1: Industrial use cases

WP6

: Sta

ndar

disa

tion,

dis

sem

inat

ion

and

expl

oita

tion

Manufacturing planning andcontrol system(Saarstahl AG)

Dynamic, adaptable androbust systems for oil and

gas operations(StatoilHydro)

WP2: Model-driven methodology and architecture

WP3: Metamodelsand languages

WP4: Modellingtools and services

WP5: Modeltransformationsand deployment

Industrial userrequirements

Integrated tool-supported methodologyfor designing flexible business systemssemantic-enabled heterogeneous SOA

Integration of methodological components

Figure 1: SHAPE Work Packages Structure

This is Deliverable D2.2, i.e. the second deliverable of WP 2. It builds upon the results of D2.1, whichhas defined the basic approach for the SHAPE Methodology and has provided a comprehensive state-of-the-art analysis of existing methodologies from the various fields related to the SHAPE technology[SHAPE D2.1]. In this deliverable, we refine the overall approach for the SHAPE Methodology, andutilize the state-of-the-art analysis from D2.1 as the basis for identifying the relevant methodologiesand their fragments that will constitute the initial version of the SHAPE Method Library.

The initial version of the SHAPE Methodology concentrates on the usage of SoaML for modelling anddeveloping SOA systems. SoaML is a meta-model for describing SOA systems. Its specification hasbeen the major achievement of SHAPE in the 1st year of the project in WP 3 (see [SHAPE D3.1]), andit is currently in the final phase of standardization in OMG [SoaML, 2008]. In the 2nd year, the projectwill concentrate on the extensions of SoaML for service variability modelling as well as for severalheterogeneous architectures (conventional Web Services, Agents, Semantic Web Services, Grid, andP2P technologies). The SHAPE methodology will be updated and extended accordingly in the subse-quent deliverables for WP 2, i.e. D2.3 (in M24) and D2.4 (in M30). The later will also include experi-ences and best practices obtained from the pilot systems developed in WP 1.

Besides the definition of the SHAPE Methodology, WP 2 also covers the integration of the results ofthe technical work packages and the provision towards the industrial use cases. For this, the WP 2deliverables also maintain the SHAPE Reference Matrix. This defines the overall technology devel-oped in the SHAPE project in a 2-dimensional matrix (vertical axis = abstraction levels; horizontal axis= aspects), and allocates the results of the technical developments in the respective boxes. Each boxdefines (1) the meta-models to be used for describing the level-aspect artefact, (2) the SHAPE tool tosupport this, and (3) the methodology, respectively the method chunks suitable for guiding the devel-opment. In this deliverable, we define the structure of the SHAPE Reference Matrix and the initialboxes on the basis of the meta-models defined in WP 3 (D3.1, D3.2), the SHAPE tools developed inWP 4 (D4.1), and the model transformations defined in WP 5. The SHAPE Reference Matrix will berefined and extended successively to the developments in the technical work packages.

Public


1.3 OutlineThis report is structured as follows:

Section 2 gives a concise overview of the SHAPE Methodology approach and its relation tothe other development efforts in the project by defining the SHAPE Reference Matrix

Section 3 provides the detailed specification of the SHAPE Methodology (initial version), in-cluding the approach for customizing methodologies and the definition of the Method Library

Section 4 presents the prototype of the SHAPE Methodology tool which supports the creationof customized methodologies and the management of the SHAPE Method Library

Section 5 discusses an illustrative example for the system engineering support that shall beprovided by the SHAPE Methodology by means of an initial methodology for SoaML modelling

Section 6 provides an outlook to the refinements and extensions of the SHAPE Methodologythat will be covered in the follow-up versions

Section 7 concludes the report and gives an outlook to the subsequent deliverables of WP 2.

The Appendices contain the following accompanying information:

Appendix A: list of the source methodologies that have been analyzed in detail for defining theinitial version of the SHAPE Method Library

Appendix B: detailed analysis results of the candidate methodologies (the actual results of theanalysis are provided in an accompanying document).

Appendix C: information on availability and installation instructions for the SHAPE Methodol-ogy Tool, initial version (available for download in the eRoom)

Appendix D: the initial version of the complete SHAPE Reference Matrix, including the alloca-tion of metamodels (from WP 3), tools (from WP 4 and 5), and methodologies (WP 2)

Appendix E: detailed overview of the SHAPE Method Library (initial version) as the identifiedmethod chunks and their allocation within the SHAPE Reference Matrix

Public


2 Overview and ApproachThis section gives a concise overview of the overall approach for developing the SHAPE Methodologyas well as its allocation in the overall project work plan. We first recall the aim and the overall ap-proach as described in the previous WP 2 deliverables [SHAPE D2.1], then define the structure of theSHAPE Reference Matrix that serves as the central integration facility for all modelling techniques andtools developed in the project, and finally present the framework for the SHAPE Methodology that isspecified in detail in Section 3.

2.1 Aim and ApproachMethodologies provide guided procedures for supporting software architects, engineers, and develop-ers as well as other stakeholders in the proper and most beneficial usage of a given technologythroughout the whole system engineering process. Thus, they denote an essential part of new tech-nology development, facilitating their proper usage in real-world applications.

The SHAPE project develops a comprehensive set of techniques along the tool support for the model-driven development of SOA systems with extensions for service variability and for heterogeneoustechnology platforms (SHA). By nature, the SHAPE technology covers several aspects, and buildsupon the results and existing technologies from several related fields of research and engineering. Inparticular, the SHAPE technology relates to the following areas: model-driven engineering (esp. theMDA standards from OMG), Enterprise Architecture Modelling, SOA engineering techniques, andmodelling techniques from the various technical platforms that shall be supported in SHA (namely:Web services, Agent technology, Semantic SOA technologies, Grid, and P2P technologies).

In consequence, the SHAPE Methodology needs to provide guided procedures for all aspects coveredby the SHAPE technology, including proper support for all phases of the overall system engineeringprocess as well as detailed methods for the modelling and development of specific aspects. With re-spect to the maturity and wide adaptation of most of the technologies related to SHAPE, there alreadyexists a lot of material for methodological support that provides a valuable basis for our purposes.Thus, instead of developing a new methodology from scratch, we decided to develop the SHAPEMethodology by reusing, integrating, and extending existing methodologies and fragments thereof.

Another central design decision has arisen from analyzing the structure and requirements defined inthe industrial uses cases of the SHAPE project [SHAPE D1.1]. Each of the described scenarios has adifferent structure, requires different technologies, and thus also requires a specific methodology forthe system engineering process. In particular, we can distinguish the following types of scenarios: (1)different overall engineering process: top-down, bottom-up, and middle-in-out, and (2) use cases forwhich only some aspects of the overall SHAPE technology are required. Obviously, an all-embracingmethodology with a rigid structure does not appear to be suitable in order to provide adequate supportfor all these different scenarios. In consequence, we decided to design the SHAPE Methodology to bea collection of method chunks (= smaller parts of a comprehensive methodology that support themodelling or development of a certain aspect) along with a generic, tool-supported framework for cre-ating individual, customized methodologies for specific scenarios.

These two design principles of the SHAPE Methodology facilitate a substantial integration with thestate-of-the-art in model-driven software engineering, enable software architects and engineers tochoose the technologies and methodologies that appear to be desirable for a specific scenario, andensure the extensibility of the methodology framework for future technology developments. Conclud-ing, we can summarize the approach for the SHAPE Methodology as follows:

The aim is to provide a comprehensive methodology for supporting the engineering processfor SOA and SHA systems

The requirements are:

o Reuse, integrate, and extend existing methodologies from related areas

o Support for defining customized methodologies for individual application scenarios

Public


The approach is to:

o Provide and maintain a Method Library as a collection of method chunks for sup-porting the modelling or developed of a specific (= method chunk)

o Reuse, adaptation, and extension of existing methodologies by decomposition intomethod chunks and their allocation in the SHAPE Reference Matrix

o Provide a tool-supported framework for creating customized methodologies forindividual SOA / SHA system engineering projects.

The following explains the development of the SHAPE Methodology and its allocation within the over-all project result in more detail. At first, we define the structure of the SHAPE Reference Matrix. Thisprovides an integrated view on all the technology developments conducted in the project, and allowsus to identify the relevant aspects for which methodological support is required. Afterwards, we definethe structure, the software architecture, and the development roadmap for the SHAPE Methodology.

2.2 The SHAPE Reference MatrixThe following defines the SHAPE Reference Matrix, which provides a comprehensive overview of thetechnologies developed in the project and serves as the overall integration view. It is defined as a two-dimensional matrix that distinguishes the abstraction and the aspects relevant for modelling SOA /SHA systems, and allocates the SHAPE technologies into the respective level-aspect boxes. The ma-trix will be continuously extended in the course of the project. Besides, with respect to the SHAPEMethodology, it allows us to identify the aspects for which methodological support is required.

2.2.1 DefinitionThe purpose of the SHAPE Reference Matrix is to provide a comprehensive overview and integrationview of all the technologies developed in the course of the project. It is defined as a two-dimensionalmatrix that organizes the Abstraction Levels (vertical dimension) and the Modelling Aspects (hori-zontal dimension) that are relevant for developing SOA / SHA systems in a model-driven manner.

On the vertical dimension, we distinguish three abstraction levels (CIM, PIM, PSM) in accordance tothe areas of concern identified in MDA frameworks. In addition, we consider the translations betweenabstraction levels (CIM2PIM and PIM2PSM), which are necessary to derive lower-level models fromhigher level ones during the system engineering process. These are realized by (semi-) automatedmodel transformations. On the horizontal dimension, we distinguish the following 8 aspects: Informa-tion, Service, Process, Rules, Organization, Motivation, and non-functional aspects (NFA). Thesehave been determined as relevant for describing SOA / SHA systems in [SHAPE D2.1], inspired bythe aspects considered in existing SOA reference architecture models.

ASPECT

LEVELInformation Service Process Rules Events Organization Goals NFA

CIM [box]

CIM2PIM

PIM

PIM2PSM

PSM

Figure 2: SHAPE Reference Matrix Structure

Public


Figure 2 above shows the structure of the SHAPE Reference Matrix. The following defines the ab-straction levels and the modelling aspects in more detail.

Abstraction Levels (Vertical Dimension)In accordance to MDA frameworks (e.g. [Mellor et al., 2004])

(1) CIM (Computation Independent Models): high-level system description abstracting from thetechnical realization, business level perspective

(2) CIM2PIM: transformation layer between CIM and PIM models

(3) PIM (Platform Independent Models): system architecture model abstracting from platform-specific details of technical realization, system architect perspective

(4) PIM2PSM: transformation layer between PIM and PSM models

(5) PSM (Platform Specific Dimension): system architecture model for realization on a specifictechnology platform, system engineer perspectives.

Modelling Aspects (Horizontal Dimension)

Derived from state-of-the-art analysis in accordance to common structure of existing SOA ReferenceArchitectures (e.g. [OASIS 2006])

(1) Information: the data / information / business objects dealt with

(2) Service: a capability offered by a service provider that can be accessed by a consumer via astandardized interface

(3) Process: business process or other procedural activities that need to be conducted in order toachieve a (business) goal

(4) Rules: conditions for the usage of a service or process

(5) Events: occurrences or happenings that trigger an activity (e.g. invocation or termination of a ser-vice or a process)

(6) Organization: the structure of the organization where the system shall be used (company, insti-tute, department, inter-organizational

(7) Motivation: the (business) goals and

(8) Non-functional Aspects: non-functional aspects of services or processes (e.g. quality-of-service,security, SLAs, etc.).

The allocation of the SHAPE technologies into the overall model is defined by so-called boxes in theReference Matrix. Each box is defined by three slots: (1) the metamodel that is used to describe themodelling aspect at the respective abstraction level, (2) the SHAPE tool that supports the creation ofthe metamodel, and (3) the method chunks – i.e. the methodology fragments – that provide guidedprocedures for the engineering process for modelling the specific aspect at the specific abstractionlevel. These boxes gather the results of the SHAPE project: the first slot corresponds to the metamod-els developed in WP3, the second one to the tools developed in W4 and also the model transforma-tions defined in WP5, and the third slot represents the methodology fragments collected in the SHAPEMethod Library developed in WP2. Figure 3 illustrates the structure of a box in the SHAPE ReferenceMatrix. Note that there might be multiple entries for the slots in some of the boxes, as sometimesthere are several possibilities for suitable techniques for modelling a specific aspect at a certain level.

Public


Aspect

Metamodel (from WP3)

suitable metamodel for describing the aspect on the MOF-2 level

SHAPE Tool (from WP4 / WP5)

- tool for creating MOF-1 models from metamodel (MOF-2)

- model transformation (for CIM2PIM / PIM2PSM)

Level

Methodology (from WP2)

method fragment (= guided procedure) for building the MOF-1 models

Figure 3: SHAPE Reference Matrix – Structure of a Box

With the structure as defined above, the SHAPE Reference Matrix provides a comprehensive over-view on the scope of the SHAPE technology. The content of the boxes will be elaborated throughoutthe course of the project, so that the matrix further serves as the overall view for integrating the devel-oped technologies and aligning the efforts during the project.

This deliverable elaborates the initial version of the SHAPE Reference Matrix with special attention tothe methodology slot. The initial version of the complete reference matrix with the collected results ofall technical work packages (WP2 – WP5) is provided in Appendix A.

2.2.2 Related WorkThe SHAPE Reference Matrix is not defined “out of the blue”, but has been inspired by existing andwell-known frameworks for describing and developing wide-coverage IT solutions. The following dis-cusses the related works and positions the SHAPE Reference Matrix therein.

We already mentioned above that the abstraction models on the vertical dimension relate to the areasof concern identified in MDA (e.g. [Mellor et al., 2004]), and that the modelling aspects have beenderived from our analysis of existing works on SOA Reference Architectures (e.g. [OASIS 2006]). An-other field related to the SHAPE Reference Matrix are Enterprise Architectures (EA). These providecomprehensive frameworks for describing, modelling, and developing wide-coverage IT solutions un-der consideration of numerous aspects (e.g. functional, technical, organizational, financial), rangingfrom the business level down to the implementation level [Lankhorst et al., 2005].

One of the most prominent EA models is the Zachman Framework, which defines a domain-independent methodological framework for describing and developing IT systems for enterprises[Zachman, 1987]. It distinguishes 5 levels on the vertical dimension that represent viewpoints on thesystem by different stakeholders, and defines 6 perspectives on the horizontal dimension which de-note the aspects relevant for describing an IT system. This structure has served as the conceptualbasis for defining the SHAPE Reference Matrix: we keep the two-dimensional structure of the matrix,but align the definition of both the vertical the horizontal dimension towards the viewpoints and per-spectives that appear to be relevant for the model-driven development of SOA / SHA systems.

Figure 4 shows the mapping between the Zachman Framework and the SHAPE Reference Matrix. Onthe vertical dimension, the CIM level models contain the scope as well as the enterprise model, thePIM level relates to the system model, and the PSM level models describe the technology model aswell as the detailed representation as defined in the Zachman framework. For the vertical dimension,the following Zachman perspectives have directly corresponding modelling aspects in the SHAPEReference Matrix: (1) data – information, (2) people – organization, (3) time – events, and (4) motiva-tion – motivation. The functional perspective (how) from the Zachman framework is further differenti-

Public


ated in the SHAPE Reference Matrix, namely into four modelling aspects: Service, Process, Rules,and Non-Functional aspects. The reason is that the differentiation between services as reusable build-ing blocks that offer a certain capability and (business) processes that describe multi-step proceduresappears to be important in the context of service-oriented architectures. The rules as well as the non-functional aspects are highly relevant aspects for managing the usage of services and processes,which is why we consider them as top-level aspects the SHAPE Reference Matrix. For the networkperspective from the Zachman framework, a corresponding modelling aspect is not explicitly defined inour matrix. However, this information is inherently contained within the descriptions of services and, inparticular, the service providers and consumers.

Figure 4: Relation SHAPE Reference Matrix to Zachman Framework

We can define similar correspondences of the SHAPE Reference Matrix to other well-known EAframeworks, such as ARIS, CIMOSA, or GERAM. However, we refrain from more detailed discussionshere as the reference matrix is still under development. We plan to provide a more detailed discussionof the commonalities and differences with existing standard frameworks along with the final versions ofthe SHAPE technologies at the end of the project.

2.3 SHAPE MethodologyAfter having outlined the aim and the approach of the SHAPE Methodology as well as the definition ofthe SHAPE Reference Matrix as the overall integration view of the technologies that will be developedin the project, the following presents the framework and architecture for the SHAPE Methodology anddepicts the roadmap for its iterative development in WP2 throughout the project.

In this section, we introduce the overall framework for realizing the SHAPE Methodology with respectto the requirements identified above. While we here focus on the overall architecture and the interac-tion of the components, a detailed specification of the methodology framework is provided below inSection 3. The following first defines the overall architecture along with the relevant components, thendepicts the tooling support for creating customized methodologies that will be developed in SHAPE,and finally outlines the roadmap for developing the SHAPE Methodology throughout the project.

Public


2.3.1 Methodology FrameworkWe now define the overall framework and technical architecture of the SHAPE Methodology. As out-lined above, the aim is to provide a comprehensive methodology for the engineering process for SOAand SHA systems. The approach for realizing this is to reuse and integrate existing methodologiesfrom the various fields related to the SHAPE technology, and to provide a generic, tool-supportedframework for creating customized methodologies for specific application scenarios.

2.3.1.1 Architecture

The SHAPE Methodology shall provide a set of guided procedures for modelling and developing SOA/ SHA systems in a model-driven manner by using the techniques developed in the SHAPE project. InSection 2.1 above, we have defined two central design principles for this: (1) reuse, adaptation, andintegration of existing methodologies from the various related modelling techniques, and (2) provisionof a generic framework for the creation of customized methodologies for specific application scenarioswith tool support. This shall ensure a tight integration with existing techniques, allow us to provideappropriate methodological support for several use cases, and enable the extensibility of the SHAPEMethodology for future developments.

Figure 5 shows the framework for realizing the SHAPE Methodology and depicts the correspondenceto the other technologies developed in the project. The overall process is as follows: a User – whichcan be a system architect, a software engineer, or a developer – is about to design a specific SOA /SHA system by using the SHAPE technology. For this, he creates a Custom Methodology that de-fines a specific engineering process for developing the target system. Expectably, the individual targetsystems differ with respect to the desired scope, functionality, as well as the given premises regardingexisting legacy systems, the organizational structure, etc.

The SHAPE Methodology provides a generic framework for developing such customized methodolo-gies. It consists of the following components:

The Discipline Library that contains all relevant disciplines (i.e. single activities for systemengineering) in a loosely coupled manner with links to suitable methods

The Method Library which contains method chunks (i.e. fragments of existing methodologies)for supporting the engineering process for a particular modelling aspect on a specific abstrac-tion level as defined in the SHAPE Reference Matrix (cf. Section 2.2)

The SHAPE Methodology Description Model that defines a metamodel for describingmethod and disciplines in order to enable their management and usage for defining custommethodologies

The SHAPE Methodology Tool that supports users in the creation of custom methodologiesby selecting and arranging the necessary disciplines and methods on the basis of their meta-level descriptions.

The correspondence of the entities is as follows: a discipline denotes a single, higher level activity inthe overall engineering process of a target system, e.g. “requirements analysis”, “system design”, or“technical specification”. The Discipline Library contains all disciplines that might be required for de-veloping a SOA / SHA system. We do not define a specific system engineering process, but keep alldisciplines in a loosely organized fashion in the library. The user selects those disciplines that arenecessary to develop the specific target system, and combines them into the individual engineeringprocess. A method chunk (short: method) is a lower level element that defines a guided procedurefor creating a specific modelling artefact on the basis of the metamodels defined in WP3, e.g. a BPMNmodel that describes a business process on the CIM level or a SoaML model that describes serviceson the PIM Level. A method is associated with one or more disciplines. The Method Library containsall methods that will be identified or defined in the course of the project. For creating a custom meth-odology, the user chooses the necessary disciplines and selects the distinct methods to be used toguide the engineering process. This is supported by the SHAPE Methodology Tool that works uponthe description model for disciplines and methods. The methodology tool is part of the SHAPE ToolSuite that is developed in WP4.

Public


Figure 5: SHAPE Methodology Framework

2.3.1.2 Methodology Description Model

An essential part of the SHAPE Methodology framework is the description model for disciplines andmethods. This is a metamodel for describing the methodology fragments kept in the respective librar-ies. It facilitates the management of the libraries, and in particular enables the creation of custommethodologies within the SHAPE tool.

The description model for disciplines is rather simple, because they denote the higher level methodol-ogy fragments. The description model for methods is more complex. In particular, it contains a refer-ence to the boxes of the SHAPE Reference Matrix for which it provides a guided development proce-dure, and a reference to the disciplines for which it can be used. It is to remark that we consider disci-plines to be orthogonal to the abstraction levels and the modelling aspects defined in the SHAPE Ref-erence Matrix, i.e. they can be applied to several modelling aspects on different levels. In a specificcustom methodology, the disciplines are effectively defined by the methods which the user chooses toconduct the discipline.

The following defines the basic structure of the descriptions model for disciplines and for methods,respectively. These will be refined and extended future versions of the methodology framework. Wemight also consider the development of a rule-based management framework for the methodologyfragments, if this should appear to be desirable for enhancing the quality of the framework and the toolsupport for real-world application scenarios.

(1) Discipline Description Model

For both management and usage tasks of disciplines, it appears to be sufficient to provide a self-explanatory name along with a natural language description. We further define an optional slot forspecifying related disciplines that are usually carried out before or after the described one. Thus, theinitial description model for disciplines consists of the following elements:

Name: name of the discipline

Description: natural language description of discipline

Related [optional]: specifies disciplines that can be carried out before or after.

Public


(2) Method Description Model

With respect to the intended main usage, the description model for methods is more complex: it shallenable the automated provision of suitable method chunks for a discipline that has been chosen bythe user for the definition of a custom methodology within the SHAPE methodology tool. The centralelements for facilitating this are (1) a reference to the disciplines for which the method is suitable, and(2) a reference to the boxes of the SHAPE Reference Matrix in order to specify for which of the model-ling aspects on which abstraction levels the method provides a guided procedure. These are aug-mented with description elements for the procedure prescribed by the method, the supported notation,and the resulting modelling artefact, as well as with description elements for the management ofmethods within the library. Summarizing, the initial description model for method chunks consists ofthe following elements:

Identifier: the internal identification code of the method

Methodology: name of methodology where the method has been extracted from

Description: natural language description

Discipline: refers to the disciplines for which the method is suitable (can be multiple)

Reference Matrix Box: allocation of the method to a level-aspect box of the SHAPE Refer-ence Matrix (can be multiple)

Procedure: definition of the steps / process that the method chunk consists of

Visualization: a visualization of the procedure

Result: the model that results from conducting the method

Notation: the specification language supported by the method.

2.3.1.3 Methodology ToolThe last element of the SHAPE Methodology framework is the tool for creating custom methodologies.This shall support users – i.e. system architects, software engineers and developers, as well as otherstakeholders that are concerned with the development of a SOA / SHA system – in the definition of acustomized methodology for the complete engineering process of the system.

The specification of a custom methodology is conducted by the user, typically the architect of the tar-get SOA / SHA system that is to be developed. The tool supports this by providing semi-automatedsupport for choosing the necessary disciplines and methods from the respective libraries. The basicfunctionality for supporting the creation of custom methodologies is as follows:

1) Choose necessary disciplines for the custom methodology from the Discipline Library

2) Define a customized engineering process by arranging the chosen disciplines

3) Select the actual methods from the Method Library that shall be used for conducting the disci-plines in the customized engineering process.

For realizing this, the tools works on the description models for disciplines and methods as definedabove. A detailed specification of the technical realization for the first prototype of the SHAPE Meth-odology tool is provided below in Section 4. The tool will be integrated with the overall SHAPE toolsuite that is developed in WP 4 [SHAPE D4.1].

The basic functionality will be developed throughout the project under consideration of the require-ments from the pilot use cases developed in WP1. For the future, this can be extended with more ad-vanced facilities for managing the Method Library and the Discipline Library, e.g. by a rule-basedmanagement framework for the methodology fragments that allows a more precise selection of possi-ble candidate methods during the specification of a custom methodology.

Public


2.3.2 Development RoadmapWe conclude the overview of the framework with the roadmap for developing the SHAPE Methodologythroughout the course of the project. For this, the following first explains how the components are de-veloped, and then defines the milestones for the iterative elaboration of the methodology in WP2.

2.3.2.1 Development Methods

In order to ensure that the SHAPE Methodology is consistent with the state-of-the-art and properlyaddresses the requirements identified within the project, we take a structured approach for the devel-opment of its components.

Above, we already have defined the description models for both disciplines and methods, and also thefunctionality of the SHAPE Methodology Tool. Thus, in the following we concentrate on the develop-ment of the Discipline Library and the Method Library, which denote the constituting components ofthe SHAPE Methodology.

(1) Discipline Library Development Method

In our framework, a discipline denotes a single, higher level activity in the overall engineering processof a target system. In order to collect all disciplines that might be relevant for the engineering processof a SOA / SHA system and define them appropriately with respect to the state-of-the-art in model-driven software engineering, we take the following approach for the iterative development of theSHAPE Discipline Library:

(1) Identify relevant disciplines from

a. State-of-the-art analysis (literature, etc.)

b. Examining the SHAPE pilot use case from [SHAPE D1.1]

(2) Describe identified disciplines in accordance to the Discipline Description Model

(3) Refine and / or extend the Discipline Library on the basis of the experiences from the pilot usecase in WP1.

(2) Method Library Development Method

We consider a method to be a guided procedure for creating a modelling artefact for a specific model-ling aspect on a certain abstraction level in accordance to the SHAPE Reference Matrix as definedabove in Section 2.2. Instead of defining new methods for the supporting development of SOA / SHAsystems with the SHAPE technology, we reuse and integrate the method fragments from existingmethodologies. This is achieved by identifying relevant candidate methodologies, decomposing theminto method chunks, and allocating these with the SHAPE Reference Matrix. Later on, the existingmethodologies might be adapted to the specific aspects of SOA / SHA system engineering. If neces-sary, also new ones are developed. Summarizing, the iterative development of the SHAEP MethodLibrary will be done as follows:

(1) Examine existing methodologies (state-of-the-art analysis)

(2) Identify relevant candidate methodologies

(3) Decompose candidate methodologies into method chunks (= smaller fragments)

(4) Allocate the method chunks to the SHAPE Reference Matrix

(5) Describe the method chunks in accordance to the Method Description Model

(6) Adapt / extend existing method chunks or develop new ones for the SHAPE technology.

This development method will ensure the desired quality of the SHAPE Method Library as a compre-hensive collection of methods for supporting the engineering process of SOA / SHA systems with aclose integration of the state-of-the-art in methodologies in model-driven software engineering, and itremains extensible for future developments.

Public


2.3.2.2 Milestones

In accordance to the work plan of WP2 as defined in the Description of Work [SHAPE, 2007], we takean iterative approach for the development of the SHAPE Methodology. The following defines theplanned achievements in terms of milestones. For the ease of management, we align the developmentmilestones with the due dates of the WP2 deliverables.

Milestone 1: State-of-the-Art Analysis, Conceptual Model (M6, D2.1)

Define Aim & Approach

Comprehensive State-of-the-Art analysis of related technology frameworks and methodologies

Outline Conceptual Model

Identification of candidate methodologies

Milestone 2: Initial Version – Architecture, Contents, Prototype (M12, D2.2)

Define Approach & Architecture

Detailed analysis of Candidate Methodologies

Define Discipline Library and Method Library (initial version)

Methodology Tool Prototype (first version)

Milestone 3: Intermediate Version – Architecture, Contents, Prototype (M24, D2.3)

Refine Architecture

Reflect experiences from pilot use cases

Refine Discipline Library and Method Library

Integrate methodology support for extensions (heterogeneous architectures, variability model-ling, flexible business modelling, etc.)

Extend Methodology Tool Prototype (second version)

Milestone 4: Final Version – Architecture, Contents, Prototype (M30, D2.4)

Define final architecture

Finalize Discipline Library & Method Library

Integrate user feedback & experiences from pilot use cases

Identify possible future extensions

Methodology Tool (final version)

Public


3 SHAPE Methodology SpecificationThis section presents the detailed specification of the SHAPE Methodology. While we have outlinedthe overall framework above in Section 2.3.1, the following specifies the components as well as theinitial content of the methodology libraries in detail.

We commence with the detailed specification of the overall system architecture of the SHAPE Meth-odology. Then, we define the description models and the initial content of the Discipline Library and ofthe Method Library. Accompanying information on the initial version of the SHAPE Reference Matrixas well as on the analyzed methodologies is provided in the appendices of this report.

3.1 Architecture SpecificationFigure 6 shows the architecture of the SHAPE Methodology with particular attention to its technicalcomponents and their connections in order to realize the tool-support framework for the creation ofcustomized methodologies for individual application scenarios.

Figure 6: SHAPE Methodology Architecture Specification

Commencing from the bottom, the two libraries contain all methodology fragments that relevant forsupporting the system engineering process of SOA / SHA systems. The Discipline Library containsall disciplines – i.e. the higher level activities of the overall engineering process in our framework – thatmight be relevant for the design and development of any SOA / SHA system. These are described bythe Discipline Description Model. The Method Library contains all method chunks that are derivedfrom analyzing, decomposing, and extending existing methodologies. These are described by theMethod Description Model. In order to facilitate the semi-automated support for creating customizedmethodologies, a method description contains to references: (1) the disciplines for which the methodcan be used, and (2) the boxes of the SHAPE Reference Matrix for which the method provides aguided engineering procedure. We consider the Discipline Description Model and the Method Descrip-tion to constitute the overall SHAPE Methodology Description Model. This is used by the SHAPEMethodology Tool, which provides the user interface for creating customized methodologies for indi-vidual application scenarios. The following defines the description models as well as the initial contentof the libraries in detail. The technical specification of the methodology tool is provided in Section 4.

Public


3.2 Discipline Library (Initial Version)The following specifies the structure and initial content of the Discipline Library. We commence withthe definition of the Discipline Description Model, and then define the disciplines in detail.

We remark that this presents the initial version of the SHAPE Methodology. The future versions willprovide an extended set of disciplines, and maybe also a refined definition of the description modelwith respect to arising functional requirements for the SHAPE Methodology Tool.

3.2.1 Discipline Description ModelThe Discipline Description Model defines a set of description elements that are necessary to facilitatethe tool support for the creation of customized methodologies as well as for managing the DisciplineLibrary. In a custom methodology, a discipline is constituted by the actual methods which the userchooses for conducting the respective activity in the overall system engineering process. With respectto this, a light-weight description model appears to be sufficient for the intended usage.

Table 1 provides the definition of the Discipline Description Model for the SHAPE Methodology. Thisconsists of a unique identifier for internal management, natural language description for human con-sumption, and an optional slot wherein related disciplines can be defined. This can be used to providesuggestions to the user during the creation of a custom methodology. Each discipline in the library isannotated with this meta-information. We here also define the data type for the value of each descrip-tion element, which is relevant for the technical realization of the SHAPE Methodology Tool.

Table 1: SHAPE Discipline Description Model

Element Value Type Explanation

Identifier String (unique) Internal identifier (for management and referencing)

Name String Name / Title of the discipline (self-explanatory)

Description String Natural Language Description (for human readability)

Relation[optional]

Discipline-ID (multiple)

further attributes:- before- after

Specifies disciplines that can be carried out before or afterthe described one; this information can be used to provideproposals to the user during the custom methodologyspecification in order to ensure its appropriateness

3.2.2 System Engineering DisciplinesThe following defines the initial content of the Discipline Library. We first list the disciplines that havebeen identified to be relevant, and then provide their detailed specification in accordance to the de-scription model defined above.

3.2.2.1 List of Disciplines

We define the following as the initial set of disciplines that are relevant for the engineering process ofSOA / SHA systems. These have been identified by the analysis of the SHAPE pilot use cases de-scribed in [SHAPE D1.1], and from analyzing the common disciplines of the candidate methodologiesas identified in [SHAPE D2.1].

Requirements Analysis

Legacy System Analysis

System Design (CIM level)

Public


System Specification (PIM level)

Implementation Model (PSM level)

Implementation (with MDA-enabled code generation)

Deployment

Testing

Maintenance

Life Cycle Management

Governance Model

3.2.2.2 Discipline DescriptionsThe following provides the detailed definition of the disciplines in accordance to the description modelas defined above in Table 1. The disciplines listed in the “relation”-slot refer to most common engi-neering process for developing new SOA / SHA systems; however, the indicated process shall onlyprovide guiding support for users during the definition of a custom methodology, but is not mandatory.

Table 2: Discipline Descriptions

No. ID Name Description Relation

1 ReqAna RequirementsAnalysis

Identifying the requirements for the targetsystem, incl.: business requirements, func-tional requirements (scope), organizationalsurroundings, existing legacy systems

before: -

after:LegAnaCIMmodelPIMmodel

2 LegAna Legacy SystemAnalysis

Analyse existing legacy systems with re-spect to: capabilities, need for integrationin target system, technology models, datamodels, organizational surroundings

before:ReqAna

after:CIMmodelPIMmodel

3 CIMmodel System Design(CIM level)

Specify the business model of the targetsystem on the CIM level with respect to allrelevant aspects of the SHAPE ReferenceMatrix

before:ReqAnaPIMmodel

after:PIMmodel

4 PIMmodel System Specifica-tion (PIM level)

Specify the system model of the targetsystem on the PIM level with respect to allrelevant aspects of the SHAPE ReferenceMatrix

before:ReqAnaCIMmodel

after:CIMmodelPSMmodel

5 PSMmodel ImplementationModel (PSM level)

Specify technology model for implementingthe target system on the PSM level withrespect to all relevant aspects of theSHAPE Reference Matrix

before:PIMmodel

after:Impl

Public


6 Impl Implementation Implement the target system, utilizing codegeneration facilities of MDA approach

before:PSMmodel

after:Deploy

7 Deploy Deployment Deploy the implementation of the targetsystem to the runtime environment

before:PSMmodel

after:Test

8 Test Testing Perform tests of the developed systemregarding: functionality, performance, sta-bility, etc.

before:Deploy

after:Test

9 Maint Maintenance Maintain the technical implementation ofthe system to ensure operability and re-quired up-time

before:Deploy

after: -

10 LifeCyc Life Cycle Man-agement

Manage the life cycle of the whole systemand its components, incl.: updates of tech-nical infrastructure, replacement of out-dated components, update system withrespect to KPIs

before:Deploy

after: -

11 Gov GovernanceModel

Define a governance model for the systemlandscape of an organization in order tobetter align the IT-systems with the overallbusiness strategy

before:(all)

after:(all)

3.3 Method Library (Initial Version)This section defines the initial version of the Method Library, which denotes the heart of the SHAPEMethodology framework.

In our framework, a method (or: method chunk) is a part of an overall methodology that providesguided engineering support for modelling or developing a specific aspect on a certain level as definedin the SHAPE Reference Matrix. Instead of developing a new methodology from scratch, we analyseand decompose existing methodologies that have been identified as candidates during our require-ments and state-of-the-art analysis. The guiding references for the decomposition of the candidatemethodologies is the SHAPE Reference Matrix and the system engineering disciplines defined above.

For the initial version of the SHAPE Methodology, we focus on methodological support for developingSOA systems by using the metamodels specified in WP3. In particular, we aim at providing a set ofmethods that are suitable for supporting the system engineering process with SoaML – the centralmetamodel for SOA systems that has been developed in the SHAPE project and currently is in thefinal stage of standardization within OMG [SoaML, 2008]. The future versions of the Method Librarywill contain methods for supporting the engineering process for the several technology platforms aswell as the other extensions planned for the second year of the SHAPE project.

The following first defines the Method Description Model, then explains the structure and content ofthe initial version of the Method Library, and finally provides the detailed descriptions of the initial setof methods. Additional information on the analysis of the candidate methodologies and the integrationof the Method Library within the overall project results are provided in the appendices.

Public


3.3.1 Method Description ModelThe following defines the description model for the methods kept in the SHAPE Method Library. Asoutlined above, a method description contains two references that are necessary to facilitate the toolsupport for creating customized methodologies: (1) the disciplines for which the method can be used,and (2) the boxes of the SHAPE Reference Matrix for which the method provides a guided engineer-ing procedure. Note that each of these references might have multiple entries, because several of theidentified methods are suitable for more than one discipline as well as for multiple modelling aspects.The model further defines description elements for internal management (Identifier), for human con-sumption (Name, Description), and a set of elements that provide a detailed description of the method(procedure, visualization, notation, and result). The latter are intended to provide detailed informationand the actual guidance of users within the SHAPE Methodology Tool.

Table 3 provides the definition of the Method Description Model. We here also specify the data typefor the value of each description element, which is relevant for the technical realization of the SHAPEMethodology Tool. The method-IDs are defined in accordance to the following schema:

ID-structure: <SHAPE-Acronym> – <Chunk-No.> –- [optional: - <Sub-Chunk-No.>

The SHAPE-Acronyms of the integrated methodologies are defined in Table 30 in Appendix A

Table 3: SHAPE Method Description Model

Element Value Type Explanation

Identifier Method-ID(unique)

Internal identifier in accordance to the identification schema(SHAPE Acronyms: cf. Table 30 in Appendix A)

Name String Name / Title of the method

Description String Natural Language Description (for human readability)

Discipline Discipline-ID(multiple)

Specifies a references to a discipline for which the method issuitable; this can be several disciplines (see Discipline Library inTable 1 above)

SRMbox Box of the SHAPEReference Matrix(multiple)

Specifies references to boxes of the SHAPE Reference Matrixfor which the method provides a guided development procedure;multiple boxes for one method are possible

Procedure String Textual description of the process that the method consists of

Visualization Graphic Provides a visualization of the procedure

Notation Notation(multiple)

Lists the specification language(s) supported by the method

Result Metamodel(multiple)

Lists the model type that results from conducting the method

3.3.2 Method Collection – OverviewWe now turn towards the actual content of the SHAPE Method Library. For the initial version, this con-tains a collection of methods derived from the decomposition of existing methodologies that have beendetermined as relevant in [SHAPE D2.1], along with their meta-information in accordance to theMethod Description Model as defined above. This already provides a comprehensive set of methodsthat are usable to guide the engineering process of SOA / SHA systems. However, the current libraryrepresents a “raw” collection of available methods. For the future versions, we will inspect the methodswith respect to their suitability for SOA / SHA system engineering, provide more detailed descriptions,and extend or refine the methods where necessary.

Public


The following explains the approach and work that has been conducted for defining the initial versionof the SHAPE Method Library, and provides a high-level overview of the current content. Below, weprovide the detailed descriptions of the currently existing methods. More detailed information on theanalysis is provided in the appendices of this report, in particular:

A comprehensive overview of the analyzed methodologies (App. A)

The complete documentation of the conducted methodology analysis (App. B)

A complete overview of the complete SHAPE Reference Matrix, initial version (App. D)

A detailed allocation of the identified methods within the SHAPE Reference Matrix (App. E).

3.3.2.1 Analyzed MethodologiesAs the result of the state-of-the-art analysis conducted in [SHAPE D2.1], we have identified the 22existing methodologies that can serve as interesting candidates for defining the SHAPE Method Li-brary. With respect to the scope defined for the initial version – i.e. the concentration on methodologi-cal support for the engineering process of SOA system with SoaML – we identified candidate method-ologies from the following areas:

Enterprise Architecture Modelling (EA), which mainly cover the overall system descriptionon the CIM level

SOA Methodologies that are mainly concerned with the development of PIM-level models

Ontology Engineering Methodologies that guide the development of ontologies, which areused in SHAPE for defining a consistent and unambiguous terminology for the information as-pect on the CIM level.

Table 4 provides a concise overview of the analyzed candidate methodologies. We also define theSHAPE Acronyms for the methodologies, which is relevant for understanding the following elabora-tions. More details on the analyzed methodologies are provided in Appendix A, and within the detailedstate-of-the-art analysis in [SHAPE D2.1].

Table 4: Candidate Methodologies

No. Name SHAPE Acronym

EA Methodologies1 GERAM GERAM2 ARIS ARIS3 Enterprise Unified Process EUP

SOA Methodologies4 ISE ISE5 SOMA SOMA6 COMET-S COMET-S7 SAE SAE8 SMART SMART9 SOAD SOAD

10 SeCSE SM11 SeCSE Composition SCM12 Enterprise SOA ESOA13 ESI-Method ESIM14 OASIS Methodology OASIS

Public


15 Open Group SOA Methodology OGSOAOntology Engineering Methodologies

16 Cyc Methodology CYC17 Enterprise Ontology EONTO18 TOVE Methodology TOVE19 METHONTOLOGY METHONTO20 NeOn Methodology NEON21 On-To-Knowledge Methodology OTK22 DILIGENT Methodology DILIGENT

To obtain the initial version of the SHAPE Method Library, we performed an analysis of each candi-date methodology in accordance to the development method as defined in Section 2.3.2.1, i.e. we:

1. Decomposed each candidate methodology into method chunks (= smaller fragments)

2. Allocated the methods to the relevant boxes in SHAPE Reference Matrix

3. Described the methods in accordance to the Method Description Model

A detailed documentation of the conducted analysis work is provided in Appendix B, respectively inthe accompanying document of this deliverable.

3.3.2.2 Overview of Method Library

The conducted analysis resulted in the identification of 307 methods. These constitute the initial con-tent of the SHAPE Method Library. In order to provide a comprehensible overview of its structure,FIGURWE below provides a high-level overview that indicates the number of available methods aswell as the methodologies where these have been derived from for each box of the SHAPE ReferenceMatrix.

From this, we can make the following statements on methodological guidance for SOA system devel-opment that is supported by the current content of the SHAPE Method Library:

There are several method chunks for the development for most of the boxes of the SHAPEReference Matrix:

o All three abstract levels are supported (CIM, PIM, PSM)

o There are several methods for most of the modelling aspects relevant for SOA / SHAsystem engineering: Information, Services, Process, Rules, Organization, Goals, NFA

The core elements for SoaML modelling are support by the existing methods: these are cov-ered by the following aspects: Service, Information, Process, NFA, and Organization.

We also can observe the followings needs for extension, which will be addressed within the next ver-sions of the SHAPE Methodology:

Events is only modelling aspect for which adequate methodological support does not exist yet

Method fragments for supporting the transformation level CIM2PIM do not yet exist yet

The methods identified for the transformation level PIM2PSM can serve as the basis for thefuture development of methodology support for using the automated model transformationsthat are developed in WP5.

A more detailed overview of the method library is provided in Appendix E. Below, we provide a de-tailed description of all methods that are available in the initial version of the SHAPE Method Library(see Section 3.3.3).

Public


ASPECT

LEVELInformation Service Process Rules Events Organiza-

tion Goals NFA

CIM

Total: 40

Sources:ESIM, SCM,SM, ISE,ESOA, Cyc,DILIGENT,EOnto,MethOnto,NeOn, OTK,TOVE,GERAM,ARIS,EUP, COMET-S

Total: 25

Sources:ESIM, SM,SCM,SMART,SOMA, ISE,ESOA,GERAM,ARIS, EUPCOMET-S,OGSOA

Total: 23

Sources:ESIM,SAE,SCM, SM,SMART,SOAD,SOMA,ISE,ESOA,GERAM,ARIS, EUP,COMET-S, OG-SOA

Total: 14

Sources:ESIM,SM,SOMA,ISE,ESOA,Cyc,GERAM,EUP

Total: 4

Sources:GERAM,EUP

Total: 15

Sources:ESIM, SAE,SM,SMART,SOMA, ISE,ESOA,GERAM,ARIS, EUP

Total: 17

Sources:ESIM, SM,SMART,SOMA, ISE,ESOA,GERAM,ARIS, EUP,COMET-S

Total: 11

Sources:ESIM,SCM, SM,SOMA,ISE,ESOA,GERAM

CIM2PIMTotal: 1

Sources:

COMET-S

Total: 1

Sources:

COMET-S

Total: 1

Sources:

COMET-S

PIM

Total: 10

Sources:ESIM, SCM,SM, SMART,SOMA, ISE,ESOA,COMET-S,OASIS

Total: 19

Sources:ESIM, SAE,SCM,SMART,SOAD,SOMA, ISE,ESOA,COMET-S,OASIS,OGSOA

Total: 21

Sources:ESIM,SAE,SCM,SMART,SOAD,SOMA,ISE,ESOA,OASIS,OGSOA

Total: 7

Sources:SMART,ISE,ESOA

Total: 1

Sources:OASIS

Total: 6

Sources:SMART,ESOA

Total: 1

Sources:SMART

Total: 10

Sources:ESIM,SCM,SMART,SOMA,ISE,ESOA,OASIS

PIM2PSM

Total: 1

Sources:

COMET-S

Total: 3

Sources:ESOA,COMET-S

Total: 2

Sources:ESOA

Total: 2

Sources:ESIM,ESOA

Total: 1

Sources:ESIM,

Total: 1

Sources:ESIM,

Total: 1

Sources:ESIM,

PSM

Total: 11

Sources:ESIM, SCM,SM, SOAD,SOMA, ISE,ESOACOMET-S

Total: 21

Sources:ESIM, SAE,SCM, SM,SOAD,SOMA, ISE,ESOA,COMET-S

Total: 19

Sources:ESIM,SAE,SCM, SM,SOAD,SOMA,ISE,ESOA

Total: 7

Sources:SM,SOAD,SOMA,ISE,ESOA

Total: 1

Sources:SOAD

Total: 4

Sources:SAE, SM,SOAD

Total: 1

Sources:SOAD

Total: 5

Sources:SM,SOMA,ESOA

Figure 7: Overview of SHAPE Method Library (Initial Version)

Public


3.3.3 Method DescriptionsThe following provides the detailed descriptions of all methods that are available in the initial version ofthe SHAPE Method Library, in accordance to the description model as defined above in Table 3.

For the sake of comprehensibility, we organize the method descriptions in separate tables with respectto the source methodology where they have been extracted from. For the description, we here onlydefine the identifier, the name, the references to the SHAPE disciplines as well as to the boxes of theSHAPE Matrix, and the supported notation. These elements appear to be most relevant in order toobtain an understanding of the available methods. The more detailed descriptions of the methods –i.e. the information for the slots description, procedure, visualization, and result – is provided in Ap-pendix B, respectively in the accompanying document of this deliverable.

3.3.3.1 Generalised Enterprise Reference Architecture and Methodology (GERAM)Provider: IFIP-IFAC Task Force on Architectures for Enterprise Integration

Description: GERAM defines a tool-kit of concepts for designing and maintaining enterprises for theirentire life-history. It is meant to organise existing enterprise integration knowledge.

Table 5: Methods from the GERAM Methodology

ID Name Disciplines SRM Boxes NotationGERAM-1 Generic Enterprise Refer-

ence ArchitectureCIMmodel CIM-Service

CIM-ProcessCIM-Organ.CIM-Goals

EnterpriseModellingLanguage

(EML)GERAM -2 Enterprise Engineering

MethodologyCIMmodel

MaintLifeCyc

CIM-ServiceCIM-Process

EML

GERAM -3 Enterprise Modelling Lan-guages

CIMmodel CIM-Service EML

GERAM -4 Generic Enterprise Model-ling Concepts

CIMmodel CIM-InfoCIM-ServiceCIM-ProcessCIM-RulesCIM-EventsCIM-Organ.CIM-GoalsCIM-NFA

EML

GERAM -5 Partial Enterprise Models CIMmodel CIM-InfoCIM-ServiceCIM-ProcessCIM-RulesCIM-Organ.

EML

GERAM -6 Enterprise EngineeringTools

CIMmodel EML

GERAM -7 Enterprise Modules CIMmodel CIM-Service EMLGERAM -8 (Particular) Enterprise

ModelsCIMmodel CIM-Info

CIM-ServiceCIM-ProcessCIM-RulesCIM-Organ.CIM-GoalsCIM-NFA

EML

GERAM -9 (Particular) EnterpriseOperational Systems

CIMmodel CIM-Service EML

Public


3.3.3.2 Architecture of Integrated Information Systems (ARIS)

Provider: Institute for Economic Information at the University of Saarlandes

Description: ARIS provides a framework that spans the gap between business theory and informationand communication technology.

Table 6: Methods from the ARIS Methodology

ID Name Disciplines SRM Boxes NotationARIS-1 Organisation View CIMmodel CIM-Organ.

CIM-GoalsOrganization Chart

ARIS-2 Data View CIMmodel CIM-Info VAC / EPCARIS -3 Function View CIMmodel CIM-Events

CIM-GoalsBPML

ARIS -4 Control View CIMmodel CIM-Process KPI diagramARIS -5 Product\Service View CIMmodel CIM-Service Service Diagram

3.3.3.3 Enterprise Unified Process (EUP)Provider: Scott W. Ambler leader of agile development at IBM Corporation

Description: The Enterprise Unified Process (EUP) is an extension to the RUP (Rational UnifiedProcess).

Table 7: Methods from the EUP Methodology

ID Name Disciplines SRM Boxes NotationEUP-1 The Development Disci-

plineCIMmodel

ImplReqAna

CIM-Rules UML

EUP-2 The Operations and Sup-port Discipline

CIMmodelMaint

LifeCycDeploy

CIM-EventsCIM-Goals

UML

EUP-3 The Enterprise Disci-plines

CIMmodelLifeCyc

Gov

CIM-InfoCIM-ServiceCIM-ProcessCIM-RulesCIM-Organ.CIM-Goals

UML

EUP-4 The Production Phase LifeCycMaint

Deploy

CIM-ServiceCIM-EventsCIM-Goals

UML

EUP-5 The Retirement Phase CIMmodelLegAna

CIM-InfoCIM-ServiceCIM-Events

UML

3.3.3.4 Inter-enterprise Service Engineering (ISE)

Provider: Theseus Texo consortium

Description: Inter-enterprise Service Engineering (ISE) is a service oriented methodology developedby the Theseus / Texo project consortium. It is based on Zachman Framework and OMG’s ModelDriven Architecture concepts.

Public


Table 8: Methods from the ISE Methodology

ID Name Disciplines SRM Boxes NotationISE-1 Service Modeling CIMmodel

PIMmodelPSMmodel

CIM- ServicePIM- ServicePSM- Service

CIM-NFAPIM-NFA

Mind MapUML

WSDL

ISE-2 Workflow Modelling CIMmodelPIMmodelPSMmodel

CIM-ProcessPIM-ProcessPSM-Process

Mind MapUMLBPELBPMN

ISE-3 Data Modelling CIMmodelPIMmodelPSMmodel

CIM-InformationPIM-InformationPSM-Information

Mind MapUMLOWL

ISE-4 People and Roles CIMmodelPIMmodelPSMmodel

CIM-Organ.PIM-ProcessPSM-Process

Mind MapUML

DiamindlCAP

ISE-5 Rules CIMmodelPIMmodelPSMmodel

CIM-GoalsCIM-RulesPIM-RulesPSM-Rules

Mind MapOCL

DecisionTablesDrools

3.3.3.5 Service-Oriented Modelling and Architecture (SOMA)

Provider: IBM

Description: Service-Oriented Modelling and Architecture identifies three areas that should beaddresses when developing a SOA: services, flows and components realizing services. SOMA alsotargets the development of a methodology that separates the role of providers and consumers; andalso introduces the concept of service ecosystem or service value-net.

Table 9: Methods from the SOMA Methodology

ID Name Disciplines SRM Boxes NotationSOMA-1 Business Modelling and

TransformationCIMmodelLegAnaReqAna

CIM- ServiceCIM-ProcessCIM-Goals

NaturalLanguage,

XMLSOMA-2 Solution Management CIMmodel CIM-Rules

CIM-Organ.Natural

Language,XML

SOMA-3 Identification CIMmodelLegAna

CIM- ServiceCIM-ProcessCIM-GoalsCIM-NFA

UML

SOMA-4 Specification PIMmodel PIM-InformationPIM-ServicePIM-Process

PIM-NFA

UML, WSDL

SOMA-5 Realization PSMmodelLifeCyc

GovTest

PSM-ServicePSM-Process

UML,

SOMA-6 Implementation PSMmodelImpl

PSM-InformationPSM-Service

UML

Public


SOMA-7 Deployment, Monitoringand Management

Maint DeployLifeCyc

PSM-ServicePSM-RulesPSM-NFA

UML

3.3.3.6 Component and model-based development methodology for Services (COMET-S)

Provider: SINTEF

Description: The COMET-S methodology provides a set of processes, techniques and modellingguidelines for developing service-oriented systems. IT follows a use-case driven, model-focused ap-proach aimed at supporting the process of developing and maintaining products and product families.The methodology provides guidelines for specifying and implementing products, system, and compo-nents. The process is a structured set of development methods, procedures and modelling techniquesthat are used for the specification, development, testing and deployment of products, systems, orcomponents. COMET-S extends the previous COMET methodology with newly available meta-modelsand UML profiles from the ongoing OMG standardization activities, in particular with BMM, BPMN, andUPMS (UML Profile and Meta-model for Service).

Table 10: Methods from the COMET-S Methodology

ID Name Disciplines SRM Boxes NotationCOMET-S-1 BM-Bussness resource

ModellingCIMmodel CIM- Info BPEL

COMET-S-2 Busness Process andRole Modelling

CIMmodel CIM-ServiceCIM-Process

BPMN

COMET-S -3 Busness Process GoalModeling

CIMmodel CIM- Goals BMM

COMET-S-4 RM: BCE modelling CIM2PIM-Info UMLCOMET-S-5 RM: Use Case

ModelingCIM2PIM-Service UML

COMET-S-6 BM: Work ElementAnalysis

CIM2PIM-Process BMMBPMN

COMET-S-7 Architecture Modeling PIMmodel PIM-InfoPIM-Service

SoaML

COMET-S-8 MOFScript mapping PIM2PSM-InfoPIM2PSM-Service

MOF

COMET-S-9 PSM: Component im-plementation modeling

PSMmodel PSM-ServicePSM-Info

UML

3.3.3.7 SAE Reference Model for SOA (SAE)

Provider: CBDI Forum

Description: The SAE framework provides a more detailed and pragmatic conceptual view than thebase OASIS model for SOA; actually it is not a model but a process framework. This framework pro-vides the methodology elements that are intended to be tailored to a certain organisation’s need inorder to build the processes to drive the SOA adoption cycle.

Table 11: Methods from the SAE Methodology

ID Name Disciplines SRM Boxes NotationSAE-1 SOA Adoption and

ExcellenceGov CIM-Process

CIM-Organ.Natural

Language,UML

SAE-2 SOA Governance Gov CIM-ProcessCIM-Organ.

NaturalLanguage,

Public


UMLSAE-3 SOA Business

Requirements PlanningReqAna PIM-Process Natural

Language,UML

SAE-4 SOA BusinessImprovement

CIMmodel PIM-Process NaturalLanguage,

UMLSAE-5 Solution Assembly PIMmodel PSM-Service

PSM-ProcessNatural

Language,UML

SAE-6 Service OrientedArchitecture and Dsign

PSMmodel PSM-Process NaturalLanguage,

UMLSAE-7 Legacy Transition

PlanningLegAna PIM-Service

PSM-ServiceNatural

Language,UML

SAE-8 Service Provisioning Impl PSM-Service NaturalLanguage,

UMLSAE-9 Service Implementation Impl Natural

Language,UML

SAE-10 Service Platform Design& Installation

MaintDeploy Impl

PSM-Organ. NaturalLanguage,

UMLSAE-11 Service Operations and

ManagementLifeCycMaint

PSM-Service NaturalLanguage,

UML

3.3.3.8 Service Migration and Reuse Methodology (SMART)Provider: European Software Institute (ESI)

Description: SMART assistes enterprises to analyze their legacy systems in order to evaluate theirfeasibility to integrate SOA. SMART approach allows to adapt legacy systems to services withoutaffecting involved systems while exposing functionality to a large number of client applications usingstandard-based interfaces.

Table 12: Methods from the SMART Methodology

ID Name Disciplines SRM Boxes NotationSMART-1 Establish Migration

ContextCIMmodel

LifeCycMaint

LegAna

CIM-ServiceCIM-ProcessCIM-Organ.CIM-Goals

NaturalLanguage

SMART-2 Define CandidateServices

PIMmodelTest

PIM-InformationPIM-ServicePIM-ProcessPIM-Organ.

NaturalLanguage

SMART-3 Define ExistingCapability

PIMmodelLegAna

PIM-InformationPIM-ServicePIM-ProcessPIM-Organ.

NaturalLanguage

SMART-4 Describe Target SOAEnvironment

PIMmodelGov

LifeCycReqAna

PIM-ServicePIM-ProcessPIM-RulesPIM-Organ.

NaturalLanguage

Public


PIM-NFASMART-5 Analyze the Gap PIMmodel

LegAnaPIM-ServicePIM-ProcessPIM-RulesPIM-Organ.PIM-Goals

NaturalLanguage

SMART-6 Develop MigrationStrategy

PIMmodelLifeCyc

Gov

PIM-ServicePIM-ProcessPIM-RulesPIM-Organ.PIM-NFA

NaturalLanguage

3.3.3.9 Service Oriented Analysis Design Methodology (SOAD)

Provider: IBM

Description: Service-oriented analysis and design (SOAD), also known as service-oriented modeling,is an IBM defined process following the Service Oriented Architecture (SOA), which is an approach tosoftware modeling and development specially designed for service-oriented architecture (SOA). SOADadds innovations for service repositories, service orchestration, and the enterprise service bus. It alsohelps design, build, aggregate, and deploy applications as Web services based on SOAP, WSDL andUDDI technologies.

Table 13: Methods from the SOAD Methodology

ID Name Disciplines SRM Boxes NotationSOAD-1 Services identification CIMmodel

PIMmodelLifeCycLegAna

CIM- ProcessPIM-Process

XML, Businessprocess mod-elling notation

(BPMI)SOAD -2 Service clasification PIMmodel PIM-Process UML

SOAD -3 Subsytem analysis PIMmodelLegAna

PIM-ServicePIM-Process

UML

SOAD -4 ComponentSpecification

PSMmodelLifeCyc

PSM-InformationPSM-ServicePSM-ProcessPSM-RulesPSM-EventsPSM-Organ.PSM-Goals

UML

SOAD -5 Service Allocation PSMmodelLifeCycDeployMaint

PSM-Service UML, XML,BPEL

SOAD -6 Service realization ImplMaint

PSM-Service XML, BPEL

3.3.3.10 SeCSE Methodology (SM)

Provider: SeCSE Consortsium

Description: SeCSE Methodology is a methodology that describes the processes to carry out aSystem based on Services.

Public


Table 14: Methods from the SeCSE Methodology

ID Name Disciplines SRM Boxes NotationSM-1 Business Modelling CIMmodel CIM-Information


NaturalLanguage

SM-2 Requirements Definition ReqAna CIM-InformationCIM-ServiceCIM-ProcessCIM-RulesCIM-Organ.CIM-GoalsCIM-NFA

NaturalLanguage,

XML

SM -3 Service Discovery PSMmodel PSM-ServicePSM-Process

UDDI, WS-Discovery

SM -4 Binding PSMmodel PSM-ServicePSM-Process

XML, WS-BPEL

SM -5 Service Specification PIMmodelPSMmodel

PIM-InformationPSM-Information

PSM-ServicePSM-Process

XML, WSDL

SM-6 Legacy reengineering LegAna NaturalLanguage

SM-7 Service Monitoring LifeCycMaint

PSM-RulesPSM-NFA

SecMOL

SM-8 Service Negotiation Gov PSM-RulesPSM-Organ.PSM-NFA

XML,WS-

Agreement

3.3.3.11 SeCSE Composition Methodology (SCM)

Provider: SeCSE Consortsium

Description: SeCSE Composition is a methodology that describes the processes to develop bothstatic and dynamic composed services. This composition methodology defines a solution that allowsthe development of self-configuring and context-aware compositions, so this provides an innovative,easy-to-handle solution that spans from design to implementation level. Using this approach, variationpoints and variants have shown their usefulness for describing the specific features that a compositionmay offer depending on context information.

Table 15: Methods from the SeCSE Composition Methodology

ID Name Disciplines SRM Boxes NotationSCM-1 Enterprise Architecture

EngineeringGov

LifeCycCIM-Information

CIM-ServiceCIM-Process

CIM-NFA

NaturalLanguage,

XML

SCM -2 FunctionalSpecification/ServiceSpecificationArchitecture

CIMmodel,LegAna

CIM-InformationCIM-ServiceCIM-Process

CIM-NFA

Natural Lan-guage,

XML

SCM -3 Design-Time ServiceComposition & Variation

PIMmodel PIM-InformationPIM-Service

NaturalLanguage,

Public


Point Management PIM-ProcessPIM-NFA

XML

SCM -4 Composition & VariationPoint Realization

PSMmodel PSM-InformationPSM-ServicePSM-Process

PIM-NFA

XML,WS-BPEL,ECA Rules

SCM -5 Validation PSMmodelGov

PSM-ProcessPSM-Service

XML

3.3.3.12 Enterprise SOA (eSOA)Provider: SAP AG

Description: Enterprise SOA is SAP’s blueprint for an adaptable, flexible, and open IT architecture fordeveloping services-based, enterprise-scale business solutions which are running on a BusinessProcess Platform (BPP).

Table 16: Methods from the eSOA Methodology

ID Name Disciplines SRM Boxes NotationESOA-1 Business Requirements CIMmodel

ReqAnaLegAna

CIM- InformationCIM- ServiceCIM- ProcessCIM- Goals

Natural Lan-guage

ESOA-2 Service Modelling PIMmodel PIM-Service BPEL

ESOA-3 Service Definition PSMmodel PSM-Service UMLESOA-4 Service Implementation PSMmodel

ImplPIM2PSM-ServicePIM2PSM-EventsPIM2PSM-Rules

XML, WSDL

ESOA-5 Discovery

and Description

ImplPSMmodel

Main

PSM-InformationPIM-Information

PSM-Rules

XML, WSDL

ESOA-6 Service Consumption PIMmodelPSMmodel

Impl

PIM-ProcessCIM-ProcessPSM-Process

UML, WSDL

ESOA-7 Governance Gov PSM-RulesCIM-RulesPIM-Rules

CIM-Organ.PIM-Organ.CIM-NFAPIM-NFAPSM-NFA

non-technical

ESOA-8 Lifecycle Management LifeCyc PSM-RulesPSM-Organ.

CIM-NFAPIM-NFAPSM-NFA

non-technical

3.3.3.13 ESI Methodology (ESIM)

Provider: European Software Institute (ESI)

Description: a model-driven methodology for the development of an atomic service using web-services technologies

Public


Table 17: Methods from the ESI Methodology

ID Name Disciplines SRM Boxes NotationESIM-1 Requirements

IdentificationReqAna CIM-Info


UML

ESIM-2 Business ModelAnalysis

ReqAnaCIMmodel

CIM-InfoCIM-ServiceCIM-ProcessCIM-Organ.

UML

ESIM-3 Software SystemAnalysis

LegAna PIM-InfoPIM-ServicePIM-Process

PIM-NFA

UML

ESIM-4 Software ArchitectureSpecification

PIMmodel PIM-ServicePIM-Process

UML

ESIM-5 Detailed Design PSMmodel PSM-InfoPSM-ServicePSM-Process

UML

ESIM-6 Implementation Impl PSM-InfoPSM-ServicePSM-Process

UML

ESIM-7 Integration and Testing DeployTest

PIM2PSM-EventsPIM2PSM-GoalsPIM2PSM-NFA

UML

ESIM-8 Validation Test PIM2PSM-Organ. UMLESIM-9 System Deployment Deploy PSM-Service

PSM-ProcessPSM-Rules

UML

3.3.3.14 OASIS Methodology (OASIS)Provider: OASIS society / Capgemini UK

Description: The OASIS methodology is highlighting the road to recognizing and describe whichserivlces needed to realize the business goals, objectives and its necessary capabilitys. OASIS aimsat creating a “big picture” for service architecture which will act as an overall guide to an enterprise orproject and provide a simple view of how the organisation, or project, splits its capabilities intoservices. The approach that OASIS methodology are going through is to start at the top of the domain,whether this be at an enterprise level or for an individual area.

The methodology follows a four step process to develop an service architecture. The four processesare What, Who, Why and How. The methodology is mostly about the three first steps and onlyprovides a direction for the fourth.

Phase 1, “What” is about defining a scope of the services and what they should be.

Phase 2, “Who” externally is driving the services, and to whom do they interact.

Phase 3, “Why: is internal and external services interact with each other.

Phase 4, “how” is only given the direction for. How should they should be implemented.

Public


Table 18: Methods from the OASIS Methodology

ID Name Disciplines SRM Boxes NotationOASIS-1 Information Model PIMmodel PIM- Information UML

OASIS-2 Reference Model PIMmodel PIM-Service UML

OASIS-3 Behavioral Model PIMmodel PIM-Process UMLOASIS-4 Process Model PIMmodel PIM-Process UMLOASIS-5 Action Model PIMmodel PIM-Events UML

OASIS-6 Needs and Capability Model PIMmodel PIM-NFA UML

3.3.3.15 Open Group SOA Ontology (OGSOA)

Provider: Open Group

Description: an ontology for SOA developed by Open Group aiming to define the concepts,terminology and semantics of SOA, and contribute to model-driven SOA implementation.

Table 19: Methods from the OGSOA Methodology

ID Name Disciplines SRM Boxes NotationOGSOA-1 Basic Concept CIMmodel CIM- Service OWL

OGSOA-2 Business Activity CIMmodelPIMmodel

CIM-ServiceCIM-ProcessPIM-ServicePMI-Process

OWL

OGSOA-3 SOA Service PIMmodel PIM-Service OWLOGSOA-4 SOA Architecture PIMmodel PIM-Service OWL

3.3.3.16 Cyc Methodology (CYC)Provider: Cyc Project (http://www.cyc.com/)

Description: a knowledge engineering methodology developed in the context of the Cyc projectwhose aim was to create a large knowledge base (KB) of common sense knowledge.

Table 20: Methods from the Cyc Methodology

ID Name Disciplines SRM Boxes NotationCyc-1 Manual extraction of

commonsenseknowledge fromknowledge sources

CIMmodel CIM- InformationCIM- Rules

CYC-L

Cyc-2 Identification of morecommonsenseknowledge within theknowledge sources


CYC-L

Cyc-3 Search for more com-monsense knowledge inthe knowledge sources.


CYC-L

http://www.cyc.com/

Public


3.3.3.17 Enterprise Ontology (EOnto)

Provider: Individuals

Description: The Enterprise Ontology methodology is an early ontology engineering methodologyproposed in the context of the Enterprise project by Uschold and King.

Table 21: Methods from the EnterpriseOntology Methodology

ID Name Disciplines SRM Boxes NotationEOnto-1 Identify the purpose

of the ontologyCIMmodel CIM- Information Natural language

EOnto-2 Building the ontology CIMmodel CIM- Information Ontology lang. (any)

EOnto-3 Evaluate the ontology CIMmodel CIM- Information Non-technical

EOnto-4 Document ontology CIMmodel CIM- Information Natural Language

3.3.3.18 TOVE (TOVE)


Description: TOVE is a six step ontology methodology which is based on motivating scenarios anduses a technique called competency questions.

Table 22: Methods from the OTK Methodology

ID Name Disciplines SRM Boxes NotationTOVE-1 Identify a set of motivating

scenariosCIMmodel CIM-Information Natural Language

TOVE-2 Formulate informal compe-tency questions

CIMmodel CIM-Information Natural Language

TOVE-3 Formally specify the termi-nology of the ontologywithin a formal language

CIMmodel CIM-Information FOL / any ontologylanguage

TOVE-4 Formally define the compe-tency questions

CIMmodel CIM-Information FOL / any ontologylanguage

TOVE-5 Specify axioms in ontology CIMmodel CIM-Information FOL / any ontologylanguage

TOVE-6 Check completeness CIMmodel CIM-Information Non-technical

3.3.3.19 METHONTOLOGY (MethOnto)


Description: METHONTOLOGY was the first ontology engineering methodology to consider therigors of the software engineering community in ontology engineering and has its roots in the in thesoftware development process as defined by the IEEE.

Table 23: Methods from the Methontology Methodology

ID Name Disciplines SRM Boxes NotationMethOnto-1 Management CIMmodel CIM-Information Natural languageMethOnto-2 Development-oriented CIMmodel CIM-Information Tables

Ontology Lang. (any)MethOnto-3 Support CIMmodel CIM-Information Non-technical

Public


3.3.3.20 Networked Ontologies Methodology (NeOn)

Provider: NEON EU-IST-2005-027595

Description: NeOn methodology is a methodology for collaboratively building networks of ontologiesas well as a methodology for building semantic web applications.

Table 24: Methods from the NeOn Methodology

ID Name Disciplines SRM Boxes NotationNeOn-1 Management CIMmodel CIM-Information Natural language /

non-technicalNeOn-2 Development-

orientedCIMmodel CIM-Information Tables

Ontology Lang. (any)NeOn-3 Support CIMmodel CIM-Information Non-technical

3.3.3.21 On-To-Knowladge (OTK)

Provider: EU-IST Project IST-1999-10132 On-To-Knowledge

Description: OTK is a process oriented methodology for introducing and maintaining ontology basedknowledge management solutions into enterprises. It integrates and extends well-knownmethodologies from the field of knowledge engineering.

Table 25: Methods from the OTK Methodology

ID Name Disciplines SRM Boxes NotationOTK-1 Knowledge Meta Process CIMmodel CIM-Information Ontology Lang.

(any)OTK-2 Knowledge Process CIMmodel CIM-Information Ontology Lang.

(any)

3.3.3.22 DIstributed, Loosely-controlled and evolvInG Engineering of oNTologies (DILIGENT)


Description: DILIGENT is a ontology engineering methodology for distributed, loosely controlled andevolving engineering of ontologies.

Table 26: Methods from the DILIGENT Methodology

ID Name Disciplines SRM Boxes NotationDILIGENT-1 Central board builds an

initial core ontologyCIMmodel CIM- Information Ontology language

(any)DILIGENT-2 End users take the core

ontology and perform localadaptation on it

CIMmodel CIM- Information Natural language intabular form

DILIGENT-3 The central board analyzesthe changes made by theend users

CIMmodel CIM- Information Tabular

DILIGENT-4 Central board makes a revi-sion of the core ontology

CIMmodel CIM- Information Ontology language(any)

DILIGENT-5 New revision of the coreontology is adopted by theend users

CIMmodel CIM- Information Ontology language(any)

Public


4 SHAPE Methodology ToolThis section presents the SHAPE Methodology Tool. While we have already briefly described this toolabove in Section 2.3.1.3, the following specifies the technical architecture and the first prototype im-plementation along with the initial content of the SHAPE Method Components.

The SHAPE Methodology provides a set of guided procedures for modelling SOA / SHA systems.These guided procedures can be implemented using disciplines and methods within the SHAPEMethodology as defined above (cf. Section 3). The SHAPE Methodology Tool is a collection of guidedprocedures, disciplines and methods along with support for creating custom methodologies for theengineering process of individual SOA / SHA applications. The SHAPE Methodology tool will be inte-grated with the overall SHAPE tool suite that is developed in WP 4 [SHAPE D4.1].

The following first provides the detailed specification of the overall architecture of the SHAPE Method-ology Tool. Then, we briefly present the description model used by the tool, and define the mappingbetween concepts defined in the SHAPE Methodology and those used by the tool. We conclude withthe scope and content of the initial version of the prototype.

The prototype of the SHAPE Methodology Tool (prototype, initial version) is available for download inthe eRoom. Further information on this along with installation instructions is provided in Appendix C.

4.1 Technical ArchitectureThe purpose of the SHAPE Methodology tool is to support the specification of custom methodologiesby selecting and aggregating the required disciplines and methods. For this, the tool will contain allmethods defined in Method Library (cf. Section 3.3) as well as all the disciplines defined in DisciplineLibrary (cf. Section 3.2). The semi-automated support for developing custom methodologies is facili-tated by the SHAPE Methodology Description Model, which assigns suitable methods to disciplinesand allocates them with the SHAPE Reference Matrix. The first prototype of the SHAPE MethodologyTool only contains a subset of the current Method Library (see Section 4.3), which appears to be suffi-cient to demonstrate the intended functionality and operational behaviour of the tool. The future ver-sions of the tool will contain the complete Method Library.

The SHAPE Methodology Tool is implemented using Eclipse Process Framework EPF (cf. [EPF]).This framework is an open source project managed by Eclipse Foundation. The aim of the EPF projectis to provide am extensible framework for software process engendering together with rich exemplaryprocess content for a range of existing software development and management methodologies.

The EPF composer is a tool that enables creation of custom software development processes. Theprocess is defined using Unified Method Architecture (UMA) meta-model. This meta-model is an evo-lution of the OMG standard “Software and Systems Process Engineering Meta-model (SPEM)” fromversion 1.1 towards OMG SPEM 2.0 standard [SPEM]. The EPF project plan to evolve its schema tofull SPEM 2.0 support in future releases.

The EPF composer is complimented by a rich set of existing software development methods referredas practices. Those practices can be composed or shared in order to create a customized softwaredevelopment process. Moreover, it is possible to extend or customize existing practices for the specificrequirements of the custom development methodology.

Content providers can define their own software development methods and provide them as a methodplug-ins. Then, the methods defined in the plug-in can be used by various EPF composer users likesystem architects and developers to define their own software engineering processes. The SHAPEproject develops its own content plug-in called SHAPE Method Components. This plug-in will containall the methods and practices for successful definition of customized methodologies for semanticallyenabled heterogeneous services. The SHAPE plug-in can be imported seamlessly to the EPF com-poser and its content can be used by the end user.

Public


4.2 Content SpecificationThe following describes the content model for describing SHAPE Methodology elements within EPF.In particular, we define the relationship between the methods defined by the SHAPE Methodology (cf.Section 3) and the entities defined by the EPF UMA meta-model. Please note that the following merelydescribes the concepts that are currently used by the SHAPE Methodology Tool, which however donot represent a complete UMA meta-model description.

4.2.1 UMA ModelThe goal of users of the SHAPE Methodology Tool is to define a complete service lifecycle usingmethods and disciplines provided by the SHAPE Method Components. In terms of UMA meta-model,the service lifecycle is defined by the delivery process. The delivery process describes the deliver-ables, the methodologies to create each one of those deliverables, and the roles assignment for thewhole service lifecycle.

The delivery process is composed of capability patterns. A capability pattern is a reusable methodol-ogy chunk that contains a number of activities in some common area. The capability pattern defines aworkflow of steps, where each step is referred as a task. The method chunks defined by the SHAPEmethodology are mapped to the capability patterns. The set of methods chunks implemented in theprototype is defined below in Section 4.3.

A task is a unit of work. Each task is assigned to a specific role and has mandatory and optional in-puts and outputs. The SHAPE method chunks are modelled using task concept.

4.2.2 Illustrative ExampleThe following explains the representation of the SHAPE methods as UMA models with the methodol-ogy tool. We consider an example for the SeCSE Methodology, which is one of the methodologies thathave been analyzed and decomposed with the initial SHAPE Method Library (cf. Section 3.3).

The SeCSE Methodology (SM) developed by SeCSE consortium consists of 8 method chunks. Figure 8shows the capability pattern “Business Modeling”, which denotes the SM-1 method in the SHAPE MethodLibrary (cf. Section 3.3.3). This is composed from 3 tasks that should be performed in a sequence:

(1) Define business at organizational level,

(2) Define business at process level, and

(3) Define business at job level.

When drilling down to the “Define business at process level” task, the tool provides a detailed overview ofthe task properties. Figure 9 shows a screenshot of the UMA Task Descriptor, which provides the follow-ing information: the task “Define business at process level” is performed by the Business Analyst Role.The task inputs are “Organizational Objectives” and “Organizational Processes and Policies” wherethe task outputs are “Business Model” and “Business Needs”.

When the system analyst creates a custom methodology and includes this capability pattern in theprocess, he obtains a full task workflow of the process and a list of the work products that should bedelivered in each step of the process.

Public


Figure 8: UMA Description of Capability Pattern “Business Modeling” (Method: SM-1).

Figure 9: UMA Task Descriptor Example

Public


4.3 Prototype – Initial VersionThis section describes the initial version of the SHAPE Methodology Tool.

The purpose of this prototype is to demonstrate the planned tool support for the creation of custom-ized methodologies. With respect to this, we here consider a subset of the SHAPE method library asdefined in Section 3.3. In particular, we consider method chunks from the following existing method-ologies: SeSCE, SeSCE Methodology, and the ESI Methodology. These appear to be sufficient for theillustration purpose of illustration.

In the following, we specify the content that is provided by the SHAPE plug-in to the EPF composer.This in extends existing UMA entities – i.e. Business Analyst Role, and also defines new entities thatare unique for SOA methodologies. We also define the conceptual mappings from the UMA model tothe SHAPE Methodology as defined above in Section 3. In the subsequent versions, the terminologyof these models will be aligned.

4.3.1 MethodsTable 27 lists the methods that are defined in the current version of the prototype. These are calledcapability patterns in UMA, and correspond directly to method chunks in the SHAPE Method Library.The table also shows the associated SHAPE methods.

Table 27: Methods (UMA Capability Patterns)

No. Capability Pattern Name SHAPE Method Chunk Id

1 Business Modelling SM-1

2 Composition Realization Architecture SCM-4

3 Design Time Services Composition SCM-3

4 Detailed Design ESIM-5

5 Enterprise Architecture Engineering SCM-1

6 Service Negotiation SM-8

7 Service Specification SM-5

8 Service Specification Architecture SCM-2

4.3.2 Disciplines and TasksThe UMA model considers tasks as units of work. They are assigned to a specific role and have aconcrete input and output. Tasks correspond to the disciplines defined in the SHAPE Methodology,but describe the individual steps of the system engineering process on a more fine-grained level.

Table 28 shows the tasks that are defined within the initial version of the SHAPE plug-in, along withthe related SHAPE disciplines as defined above in Section 3.2.

Table 28: Disciplines and Tasks

No. Task Name SHAPE Discipline

1 Architectural Options Feasibility Analysis CIMmodel

2 Complete Abstract Services Descriptions CIMmodel

Public


3 Define business at job level CIMmodel

4 Define business at organizational level CIMmodel

5 Define business at process level CIMmodel

6 Design Strategic Architectural Options for Composition CIMmodel

7 Identify Abstract Services Description CIMmodel

8 Decide Upon Service Provisioning Strategy Gov

9 Generate Final Executable Activity Flow Impl

10 Discover Services LegAna

11 Evaluate available service levels LegAna

12 Update Services Composition Specifications Maint

13 Maintain Enterprise Architecture Models Maint.

14 Define Abstract Service Composition PIMmodel

15 Describe Variation Point Requirements PIMmodel

16 Describe Variation Policies PIMmodel

17 Describe the interfaces realisation PIMmodel

18 Detailed design components PIMmodel

19 Establish Final QoS PIMmodel

20 Indicate Possible Service Realisation Candidates PIMmodel

21 Map Functionalities with Discovered Services PIMmodel

22 Map Services Specifications with Abstract Descriptions PIMmodel

23 Negotiate on price and quality PIMmodel

24 Select Candidate Services PIMmodel

25 Select the Best Architecture PIMmodel

26 Set Alternatives of Use for Variation Point PIMmodel

27 Set Alternatives of Use PIMmodel

28 Select Final Architecture Option for Composition PSMmodel

29 Select Specification Language PSMmodel

30 Select facets to instantiate PSMmodel

31 Analyze the Variable Parts of the Business Process ReqAna

32 Describe Non-Functional Requirements ReqAna

33 Identify Architectural Relevant Composition Requirements ReqAna

34 Identify Service Level requirements ReqAna

35 Identify the service properties to specify ReqAna

Public


4.3.3 Additional InformationThe following lists further information that is defined within the UMA metamodel, but does not exist inthe initial version of the SHAPE Methodology framework. We will consider the integration of theseconcepts for the future versions of the SHAPE methodology.

4.3.3.1 Roles

The UMA model also considers roles, which define a set of skills and responsibilities. Every task inUMA has a role or number of roles associated with the task execution and its completion. The initialversion of the SHAPE Methodology does not define roles as a first-class modelling entity, becausethey are mostly hidden within the used methodologies. However, we might consider the integration ofroles with the future versions of the SHAPE Methodology framework. The following lists the roles thatare defined in SHAPE plug-in and used in the task from Section 4.3.2:

1. Analyst

2. Architect

3. Business Analyst

4. Business Process Modeller

5. Designer

6. Developer

7. Service Consumer

8. Service Developer

9. Service Provider

10. Tester

11. User

4.3.3.2 Work ProductsIn UMA, a work product defines the inputs and outputs of tasks, i.e. the models that result from con-ducting a specific activity. These correspond to the models which are used to describe the differentmodelling aspects as defined in the SHAPE Reference Matrix.

Table 29 shows the work products implemented in the initial version of the SHAPE Methodology Tool,along with the mapping to the relevant boxes of the SHAPE Reference Matrix. We therewith obtain thebasis for integrating the Methodology Tool into the overall SHAPE Tool Suite [SHAPE D4.1].

Table 29: Work Products in SHAPE Reference Matrix

No. Work Product Kind SHAPE Reference Matrix Box

1 Architectural Policies CIM-all

2 Architectural Options and Patterns CIM-all

3 Business Model CIM-all

4 Enterprise Realisation Architecture CIM-all

5 Enterprise Service Architecture CIM-all

6 Software System Analysis CIM-Goal

7 Business Needs CIM-Goals

8 Market Analysis CIM-Goals

Public


9 Organizational Objectives CIM-Goals

10 Organizational Processes and Policies CIM-Organization

11 Design Time Discovered Service Specifications CIM-Service

12 Service Description CIM-Service

13 SLA Proposal CIM-Service

14 SLA Request CIM-Service

15 Detailed Design PIM-all

16 Software System Architecture PIM-Goal

17 Discovered Service Specifications PIM-Service

18 List of Candidate Services PIM-Service

19 Service Composition Specification PIM-Service

20 Service Specification PIM-Service

21 Service Specification Model PIM-Service

22 SLA Contract PIM-Service

23 System Requirements PSM-Goal

24 Executable Script PSM-ServicePSM-Process

25 Service Deployment Architecture PSM-Service

26 Variability Executable Script PSM-ServicePSM-Process

27 Variability Service Deployment Architecture PSM-ServicePSM-Process

Public


5 Illustrative Example – A SoaML MethodologyThis section provides an illustrative example of a methodology for developing a SOA system usingSoaML, the central metamodel for model-driven development of SOA systems that has been devel-oped in the course of the SHAPE project [SoaML, 2008, SHAPE D3.1].

We define an initial methodology for developing a SOA system with SoaML from scratch, i.e. startingon the CIM level and then subsequently refining the models towards platform-specific implementationmodels on the PSM level. For this, we present examples for modelling the core aspects of a SoaML-based system model as defined in the SHAPE Reference Matrix (cf. Section 2.2): Motivation andBusiness Goals, Business Process, Services, and the Information aspect. As the example scenario,we consider the buyer – seller use case, which is easy to understand without requiring too much do-main specific background knowledge.

The following first gives a brief overview of SoaML, and defines the initial methodology for systemdevelopment with this. Then, we provide detailed examples for modelling the aspects mentionedabove for the buyer – seller scenario. The modelling techniques used in this example are: BMM,BPMN, Ontologies and ODM-based information models, and the core concepts of SoaML, which are:Service, Participant, Capability, Service Architecture, Service Interfaces, and Service Contracts.

5.1 OverviewThe following briefly recalls the purpose and structure of SoaML, then defines the initial methodologyfor developing SoaML-based systems, and finally provides an outlook on the remainder of this section.

5.1.1 SoaML – Executive OverviewService Oriented Architecture (SOA) is a way of organizing and understanding organizations, commu-nities and systems to maximize agility, scale and interoperability. The SOA approach is simple: peo-ple, organizations and systems provide services to each other. These services allow us to get some-thing done without doing it ourselves or even without knowing how to do it – enabling us to be moreefficient and agile. Services also enable us to offer our capabilities to others in exchange for somevalue – thus establishing a community, process or marketplace. The SOA paradigm works equally wellfor integrating existing capabilities as well as creating and integrating new capabilities.

We understand a service as an offer of value to another through a well-defined interface and availableto a community (which may be the general public). A service results in work provided to one by an-other. In consequence, SOA then an architectural paradigm for defining how people, organizationsand systems provide and use services to achieve results.

SoaML as described in this specification provides a standard way to architect and model SOA solu-tions using UML. The profile uses the built-in extension mechanisms of UML to define SOA conceptsin terms of existing UML concepts. SoaML can be used with current “off the shelf” UML tools butsome tools may offer enhanced, SOA specific.

5.1.1.1 An architectural and business focused approach to SOA

SOA has been associated with a variety of approaches and technologies. The view expressed in thisspecification is that SOA is foremost an approach to systems architecture, where architecture is a wayto understand and specify how things can best work together to meet a set of goals and objectives.Systems, in this context, include organizations, communities, processes as well as information tech-nology systems. The architectures described with SOA may be business architectures, mission archi-tectures, community architectures or information technology systems architectures – all can be equallyservice oriented. The SOA approach to architecture helps with separating the concerns of what needsto get done from how it gets done, where it gets done or who or what does it. Some other views ofSOA and “Web Services” are very technology focused and deal with the “bits and bytes” of distributedcomputing. These technology concerns are important and embraced, but are not the only focus ofSOA as expressed by SoaML.

Public


SoaML embraces and exploits technology as a means to an end but is not limited to technology archi-tecture. In fact, the highest leverage of employing SOA comes from understanding a community,process or enterprise as a set of interrelated services and then supporting that service oriented enter-prise with service-enabled systems. SoaML enables business oriented and systems oriented servicesarchitectures to mutually and collaboratively support the enterprise mission.

SoaML depends on Model Driven Architecture (MDA1) to help map business and systems architec-tures, the design of the enterprise, to the technologies that support SOA, like web services andCORBA. Using MDA helps our architectures to outlive the technology of the day and support the evo-lution of our enterprises over the long term. MDA helps with separating the concerns of the businessor systems architecture from the implementation and technology.

5.1.1.2 Top down and bottom-up SOA

SoaML can be used for basic “context independent services”. Such as common Web-Service exam-ples like “Get stock quote” or “get time”. Basic services focus on the specification of a single servicewithout regard for its context or dependencies. Since a basic service is context independent it can besimpler and more appropriate for “bottom up” definition of services.

SoaML can also be used “in the large” where we are enabling an organization or community to workmore effectively using an inter-related set of services. Such services are executed in the context ofthis enterprise, process or community and so depend on the services architecture of that community.A SoaML Service Architecture shows how multiple participants work together, providing and usingservices to enable business goals or processes.

In either case, technology services may be identified, specified, implemented and realized in someexecution environment. There are a variety of approaches for identifying services that are supportedby SoaML. These different approaches are intended to support the variability seen in the marketplace.Services may be identified by:

Designing services architectures that specify a community of interacting participants, and theservice contracts that reflect the agreements for how they intend to interact in order toachieve some common purpose

Organizing individual functions into service capabilities arranged in a hierarchy showing an-ticipated usage dependencies.

Using a business process to identify functional capabilities needed to accomplish some pur-pose as well as the roles played by participants. Processes and services are different viewsof the same system – one focusing on how and why parties interact to provide each otherwith products and services and the other focusing on what activities parties perform to pro-vide and use those services.

Regardless of how services are identified, their specification includes service interfaces. A serviceinterface defines any interaction or communication protocol for how to properly use and implement aservice. A service interfaces may define the complete interface for a service from its own perspective,irrespective of any consumer request it might be connected to. Alternatively, the agreement between aconsumer request and provider service may be captured in a common service contract defined in oneplace, and constraining both the consumer’s request service interface and the provider’s service inter-face.

Services are provided by participants who are responsible for implementing and using the services.Services implementations may be specified by methods that are owned behaviours of the participantsexpressed using interactions, activities, state machines, or opaque behaviours. Participants may alsodelegate service implementations to parts in their internal structure which represent an assembly ofother service participants connected together to provide a complete solutions, perhaps specified by,and realizing a services architecture.

1 “Model Driven Architecture”, “MDA”. “CORBA”, “Unified Modeling Language”, “UML” and “OMG” are registeredtrademarks of the Object Management Group, Inc.

Public


Services may be realized by participant implementations that can run in some manual or automatedexecution environment. SoaML relies on OMG MDA techniques to separate the logical implementationof a service from its possible physical realizations on various platforms. This separation of concernsboth keeps the services models simpler and more resilient to changes in underlying platform and exe-cution environments. Using MDA in this way, SoaML architectures can support several technologyimplementations and tool support can help automate these technology mappings.

5.1.2 SoaML MethodologyWe now define a methodology for the development of SOA systems or applications by using SoaML.As discussed in the previous sections, the overall aim is that the SHAPE Methodology allows systemarchitects to dynamically create the system engineering process. However, as the methodology is stillunder development, in the following we stick to a static methodology and focus on the successivedevelopment of the relevant SoaML models.

For illustration, we here consider the development of a new system from scratch. For this, we assumethe following overall engineering process as a top-down approach: we commence the modelling at theCIM level, defining the participants and their objectives, the central business processes, and a high-level few of the architecture. Then, we define the PIM level models by refining the business level mod-els with the details and extensions relevant for a platform-independent system architecture model.Finally, the PIM models are further refined into more detailed implementation models on the PSMlevel, from which the implementation code can be generated; the transformation level PIM2PSM isrealized by automated model transformation. The following defines the overall engineering processalong with the respective modelling tasks and the used metamodels in more detail.

1. Business Level Modelling (CIM)1.1. Business Motivation Modelling with BMM

1.2. Business Process Modelling with BPMN

1.3. Information Modelling with Ontologies / ODM

1.4. Organization Modelling by participant identification

1.5. (Business) Services Architecture Modelling with SoaML Collaboration diagrams

2. CIM2PIM Transformation

2.1. BMM -> BPMN and (Business) Service Architectures

2.2. (Business) Service Architectures -> (System) Service Architectures

2.3. CIM model -> Services using the POSI perspectives

3. System Level modelling (PIM)

3.1. Capability Modelling with SoaML capabilities

3.2. Information Class Modelling with ODM

3.3. (System) Services Architecture Modelling with SoaML

3.4. System Level Component Modelling with UML activity and sequence diagrams

3.5. System Level Component Modelling with services using port/connectors

4. PIM2PSM Mappings by automated model transformations

Public


5.1.3 OutlineIn the following sections, we illustrate the creation of the models mentioned in the above methodologyfor the buyer – seller scenario. We focus on the successive development of the complete SoaMLspecification, with special attention on the resulting models.

In order to maintain a comprehensive walk-through, we group the subsequent discussion by the mod-elling aspects. Thus, the remainder of this section is structured as follows:

Section 5.2 discusses the modelling of participants and their business goals; this relates totasks 1.1 and 1.4 of the above methodology

Section 5.3 illustrates the modelling of the business process for the buyer – seller example;this participants and their business goals; this relates to task 1.2 of the SoaML methodology

Section 5.4 exemplifies the modelling of SoaML service architectures (relating to task 1.5),and the specification of SoaML Capabilities (relating to task 3.2)

Section 5.5 shows the modelling of the information aspects for the buyer-seller example onboth the CIM level (1.3) and the PIM level (task 3.2)

Finally, Section 5.6 illustrates the modelling of SoaML Services and their related elements,covering tasks 3.3 – 3.5 of the above methodology.

5.2 Business Motivation Modelling with BMMWe commence with modelling the participants of our example scenario (buyer and seller), and theirbusiness objectives that shall be achieved by the SOA system that is developed.

Services are intended to facilitate the agile development of business relevant solutions. To do so, ser-vices provide functional capabilities that when implemented and used to provide some real-world ef-fect that has value to potential producers and consumers. Business requirements can be capturedusing the OMG Business Motivation Model (BMM). BMM can be used to capture the influencers thatmotivate the business to change, the desired ends it wishes to achieve, and their supporting means.The ends may be defined by a business vision amplified by a set of goals and objectives representingsome desired result. The means are the courses of action that when carried out support achievementof the ends producing the desired result as measured and verified by some assessment of the poten-tial impact on the business. Courses of action may represent or be carried out by interactions betweenconsumers with needs and providers with capabilities.

Any UML BehavioredClassifier including (for example a ServicesContract) may realize the BMM Moti-vation concept of motivation realization. This allows services models to be connected to the businessmotivation and strategy linking the services to the things that make them business relevant.

However, the business concerns that drive ends and means often do not address the concerns nec-essary to realize courses of action through specific automated solutions in some execution environ-ment. For example, business requirements may be fulfilled by an IT solution based on an SOA. Sucha solution will need to address many IT concerns such as distribution, performance, security, dataintegrity, concurrency management, availability, etc. It may be desirable to keep the business and ITconcerns separate in order to facilitate agile business solutions while at the same time providing ameans of linking solutions to the business requirements they fulfil, and verifying they do so with ac-ceptable qualities of service. Capabilities, ServiceContracts and ServicesArchitectures provide ameans of bridging between business concerns and SOA solutions by tying the business requirementsrealized by the contracts to the services and service participants that fulfil the contracts.

There are other ways of capturing requirements including use cases. A ServiceContract, which is alsoa classifier, can realize UML Use Cases. In this case, the actors in the use case may also be used totype roles in the service contract, or the actors may realize the same Interfaces used to type the roles.

Public


5.2.1 BMM – Business Motivation MetamodelThe Business Motivation Model provides a scheme or structure for developing, communicating, andmanaging business plans in an organized manner. Specifically, the Business Motivation Model doesall of the following:

It identifies factors that motivate the establishing of business plans

It identifies and defines the elements of business plans

It indicates how all these factors and elements inter-relate

Among these elements are ones that provide governance for and guidance to the business. These areBusiness Policies and Business Rules.

5.2.2 Example Buyer / Seller ScenarioThe following illustrates how to define the model the business goals with BMM. These describe thebusiness goals of a particular a business entity (e.g. a person, department, or a company). In conse-quence, these denote the motivation for participating in SOA system that can ensure the achievementof these individual goals. Figure 10 shows an example of a BMM motivation model.

Figure 10: A BMM Motivation Model

Public


For our example, we can identify the following goals, objectives, and visions for the buyer:

Goal: get the wanted product with sound price and good quality

Objective: find the proper merchant

Objective: define a budget for the product

Objective: contact properly with the merchant

Vision: find the perfect component that needed.

Figure 11 shows the visual representation of this in BMM.

Figure 11: BMM – Buyer’s Ends

Analogously, we can define the motivation for the seller as follows (see Figure 12):

Goal: provide the customer with the best product and service

Objective: development (Expand the market, develop marketing strategies suited to thebusiness, diversification of development: horizontal and vertical)

Objective: market (in 3 - 4 years become market leader in related manufacturing domain).

Objective: production (reach 1000,000 production per year by the end of this year)

Vision: provide customers with the best product and service

Figure 12: BMM – Seller's Ends

Public


The next part of BMM models are the means, i.e. the resources, strategies, and tactics that are avail-able to a business entity for achieving the ends. For the buyer, we can define the following means:

Objective: contact properly with the merchant

Tactic: hold a formal meeting for the trade

Objective: find the proper merchant

Strategy: invite public bidding

Strategy: medium ads

Objective: define a budget for the product

Strategy: find a way to evaluate the price

Tactic: market investigation

Figure 13 shows the BMM model that represents the buyer’s means. Analogously, we can define theseller’s means. However, we refrain from further details as the resulting model is similar.

Figure 13: BMM – Means of the Buyer

5.3 Business Process Modeling with BPMNWe now turn towards the modeling of business processes. Business process management (BPM) is amethod of efficiently aligning an organization with the wants and needs of clients. It is a holistic man-agement approach that promotes business effectiveness and efficiency while striving for innovation,flexibility and integration with technology. As organizations strive for attainment of their objectives,BPM attempts to continuously improve processes - the process to define, measure and improve yourprocesses – a ‘process optimization' process. BPMN is a widely known OMG standard for the model-ing of business processes.

The following first shows the BPMN top-level description that corresponds to business process model-ing on the CIM level in the SHAPE context, and then explains the BPMN bottom view description thatrelates PIM level business process modeling. We here consider an extended setting of the runningexample that also considers a bank and a shipper next the buyer and seller. Here, the customer pur-chases products through an online shop. The business process includes online payment and offlineproducts shipment. This extended scenario appears to be suitable for demonstrating the differentmodeling constructs of BPMN. We used the Eclipse BPMN plug-in for creating both the top view andthe detail description of the business process.

Public


5.3.1 Top View Description (CIM)In the extended buyer-seller example, the process describes that a customer purchases products froman online shop. Figure 14 shows the BPMN top view. This is more general, just describing communi-cation between different participants; this corresponds to the CIM level modeling of process. In thisdiagram, it contains totally four pools, which mapping four participants in Service model:

Customer: User who will come to online shop to buy productsShop: An online shop, which faces customer and being the mediator to collaborate with bankand logistic company.Bank: Processing the payment function during the processLogistic company: Processing the transportation function during the process

Figure 14: Top view of BPMN Process (CIM Level)

In this top view, the main entity is the task. The executing sequence follows the message flow and thework flow. The Customer is the default starter. The main flow is:

1. Communication between Customer and Shop: processing products’ selection and shopping cart

2. Communication between Shop and Bank: processing set of payment functions

3. Communication between Shop and Customer: processing set of products transportation

5.3.2 Bottom View Description (PIM)The following describes the parts of the business process in detail. This corresponds to the modelingof business process as foreseen on the PIM level in the SHAPE Reference Matrix.

When Customer logs in to the online shop platform, he will first choose products. This process willcommunicate with shop three times in order to choose all products desired by the customer. The loopset demonstrates that the user can choose products several times. Figure 15 shows this part in detail.

Public


Figure 15: BPMN – Choose Products

Figure 16 simulates how to search and return a product list. The different levels of the tasks in thevisualization denote the different lanes in the shop pool. Highest level is the GUI level in PSM view.The middle level stands for the controller and the calculation level. The Bottom level relates to thedatabase level.

Figure 16: BPMN – Search Products

Figure 17 shows how the online shop regulates the content of the shopping cart after every iteration ofthe product selection sub-process. It also is distinguishes different levels. The higher level is also theGUI, which the user could see from web pages. The initiate selection would be inter-control in theshop.

Public


Figure 17: BPMN – Set Shopping Cart

Figure 18 shows the process part where the customer decides to buy products in shopping cart. Atfirst, the user sends a message event to indicate to the shop that he wants to buy the products. After acouple of operations, the system tells user the return information (confirmation). Then, the user coulddecide he will really buy it or not.

Figure 18: BPMN – Buy Products

Next, Figure 19 shows the internal processing on side of the online shop after a purchase order isreceived. At first, they will initiate total payment, if user’s account is not enough for payment, thereshould be a compensate task that the product in shopping cart should release. Then, other customerscould choose these products. After the normal progress, the shop got the information, and starts tocommunicate with bank. Here, the process conducts “set payment” and “apply payment” together.

Public


Figure 19: BPMN – Set and Apply Payment

Afterwards, the bank receives the information transfer from shop, bank will contact with customer, letuser decide if they would pay for these products. Then, bank will execute the money transfer flow.Figure 20 shows the respective part of the business process.

Figure 20: BPMN – Execute Payment

Finally, after the payment is executed, the shop will initiate the shipment of the products, which is exe-cuted by the logistic company. The logistic company executes the transportation, and returns the con-firmation back to the shop. Figure 21 shows the BPMN model for this.

Figure 21: BPMN – Execute Shipment

Public


5.4 SoaML Service ArchitectureThe following explains the development of the SoaML Service Architecture, which provides the overalloverview of the system architecture that is defined on the CIM level. Afterwards, we illustrate the defi-nition of SoaML Capabilities that are used for defining existing or desired functionalities which are latermapped to specific services.

5.4.1 SoaML Service ArchitectureOne of the key benefits of SOA is the ability to enable a community or organization to work togethermore cohesively using services without getting overly coupled. This requires an understanding of howpeople, organizations and systems work together, or collaborate, for some purpose. We enable thiscollaboration by creating a services architecture model. The services architecture puts a set of ser-vices in context and shows how participants work together for a community or organization.

A Service-Oriented Architecture (or SOA) is a network of participant roles providing and consumingservices in order to fulfil a purpose. The services architecture defines the requirements for the types ofparticipants and service realizations that fulfil those roles. Since we want to model how these people,organizations and systems collaborate without worrying, for now, about what they are, we talk aboutthe roles these participants play in services architectures.

A role defines the basic function (or set of functions) that an entity may perform in a particular context;in contrast, a Participant specifies the type of a party that fills the role in the context of a specific Ser-vices Architecture. Within a ServicesArchitecture, participant roles provide and employ any number ofservices. The purpose of the services architecture is to specify the SOA of some organization, com-munity or process to provide mutual value. The participants specified in a ServicesArchitecture provideand consume services to achieve that value. The services architecture may also have a businessprocess to define the tasks and orchestration of providing that value. The services architecture is ahigh-level view of how services work together for a purpose. The same services and participants maybe used in many such architectures providing reuse.

The purpose of services architecture collaboration is to illustrate how kinds of entities work together forsome purpose. Collaborations are based on the concepts of roles to define how entities are involved inthat collaboration (how and why they collaborate) without depending on what kind of entity is involved(e.g. a person, organization or system). As such, we can say that an entity “plays a role” in a collabo-ration. The services architecture serves to define the requirements of each of the participants. Theparticipant roles are filled by participants with service points required of the entities that fill these rolesand are then bound by the services architectures in which they participate.

A services architecture has components at two levels of granularity: The community services architec-ture is a “top level” view of how independent participants work together for some purpose. The ser-vices architecture of a community does not assume or require any one controlling entity or process.The services architecture of a community is modelled as collaboration stereotyped as <<ServicesAr-chitecture>>. A participant may also have services architecture – one that shows how parts of thatparticipant (e.g., departments within an organization) work together to provide the services of the own-ing participant. The services architecture of a participant is shown as a UML structured class or com-ponent with the <<ParticipantArchitecture>> stereotype and frequently has an associated businessprocess. We shall discuss this below in more detail.

Figure 22 shows a community ServicesArchitecture for our running example. Here, we describe theoverall structure of a system with 3 participants: a dealer, a manufacturer, and a shipper. The modeldefines the relations and the necessary interactions between the participants: the dealer denotes theentity that buys an item from the manufacturer, who represents the seller. This is done via the Pur-chasing Service. The shipper performs the shipment service from the manufacturer to the dealer, andprovides a service for enquiring the shipment status.

Public


Figure 22: Example SoaML Community Services Architecture

5.4.2 SoaML Participant ArchitectureAs outlined above, a <<ParticipantArchitecture>> specifies the architecture for a particular Participant.Within a participant, where there is a concept of “management” exists, a participant architecture illus-trates how sub-participants and external collaborators work together and would often be accompaniedby a business process. A Services Architecture (both community and participant) may be composedfrom other services architectures and service contracts. As shown in Figure 23, Participants are classi-fiers defined both by the roles they play in services architectures (the participant role) and the “con-tract” requirements of entities playing those roles. Each participant type may “play a role” in any num-ber of services architecture, as well as fulfil the requirements of each. Requirements are satisfied bythe participant having service points that have a type compatible with the services they must provideand consume.

Figure 23: Example Services architecture for a participant

Public


Figure 23 above illustrates the participant services architecture for a “Manufacturer”. It indicates thatthis architecture consists of a number of other participants interacting through service contracts. TheManufacture participant services architecture would include a business process that specifies howthese participants interact in order to provide a purchasing service. Note that other manufacturers mayhave different internal participant architectures but will have the same responsibilities and interfaces inthe services architecture. Separating the concerns of the “inside” Vs. the “outside” is central to SOAand good architecture in general.

5.4.3 Capability ModellingService architectures along with service contracts (see below) provide a formal way of identifying theroles played by parties or Participants, their responsibilities, and how they are intended to interact inorder to meet some objective using services. This is very useful in a “needs” or assembly context.However, sometimes the participants may not be known at design time, e.g. the when re-architectingexisting applications for services or building services from scratch. In these situations, it is also usefulto express a services architecture in terms of the logical capabilities of the services in a “Participantagnostic” way. Even though service consumers should not be concerned with how a service is im-plemented, it is important to be able to specify the behaviour of a service or capability that will realizeor implement a ServiceInterface. This is done within SoaML using Capabilities.

Capabilities represent an abstraction of the ability to affect change. They identify or specify a cohesiveset of functions or resources that a service provided by one or more participants might offer. Capabili-ties can be used by themselves or in conjunction with Participants to represent general functionality orabilities that a Participant must have. Figure 24 shows a network of Capabilities that might be re-quired to process an order for goods from a manufacturer. Such networks of capabilities are used toidentify needed services, and to organize them into catalogues in order to communicate the needs andcapabilities of a service area, whether that is business or technology focused, prior to allocating thoseservices to particular Participants. For example, service capabilities could be organized into UMLPackages to describe capabilities in some business competency or functional area. Capabilities canhave usage dependencies with other Capabilities to show how these capabilities are related. Capabili-ties can also be organized into architectural layers to support separation of concern within the result-ing service architecture.

«Capabil i ty»Order Processing

+ processPurchaseOrder(Party, Order) : ack

«Capabil i ty»Inv oicing

+ completePriceCalculation() : void+ initiatePriceCalculation() : void

«Capabili ty»Inv entory Management

+ retrieveItems() : Item[]+ storeItem(Item) : ack

«Capabil i ty»Scheduling

+ requestProductionScheduling() : void+ sendShippingSchedule() : void

«Capabil i ty»Shipping

+ requestShipping() : void

«use»«use»

«use» «use»

Figure 24: Service Capabilities needed for processing purchase orders

Public


In addition to specifying abilities of Participants, one or more Capabilities can be used to specify thebehaviour and structure necessary to support a ServiceInterface. Figure 25 shows the Shipping Ca-pability realizing the Shipping ServiceInterface. Thus, Capability allows for the specification of a ser-vice without regard for how that service might be implemented and subsequently offered to consumersby a Participant. This allows architects to analyze how services are related and how they might becombined to form some larger capability prior to allocation to a particular Participant.

«ServiceInterface»ShippingServ ice

+ requestShipping()

«Capabil ity»Shipping

+ requestShipping()

«interface»Shipping

+ requestShipping()

«interface»ScheduleProcessing

+ requestProductionScheduling()

«use»

Figure 25: ServiceInterface realized by a CapabilityCapabilities can, in turn, be realized by a Participant. When that Capability itself realizes a ServiceIn-terface, that ServiceInterface will normally be the type of a ServicePoint on the Participant (Figure 26).

«Participant»Shipper

shippingOffice :ShippingService

«ServiceInterface»ShippingServ ice

+ requestShipping()

«Capability»Shipping

+ requestShipping()

The ServiceInterfacetypes the ServicePoint

<<ServicePoint>>

«interface»Shipping

+ requestShipping()

«interface»ScheduleProcessing

+ requestProductionSchedul ing()

ScheduleProcessingShipping

«use»

Figure 26: The Shipper Participant realizes the Shipping Capability

Public


Capabilities may also be used to specify the parts of Participants. Figure 27 shows the ProductionsParticipant with two parts typed by Capabilities. The productionOffice ServicePoint delegates requeststo the scheduler part that is typed by the Scheduling Capability. This would normally indicate that theScheduling Capability realizes the SchedulingService ServiceInterface.

«Participant»Productions

productionOffice :SchedulingService

«Capabil i ty»scheduler :Scheduling

«Capabil i ty»manufacturer :Manufacturing

<<ServicePoint>>«delegate»

Figure 27: Productions Participant with two parts specified by Capabilities

ServiceInterfaces may also expose Capabilities. This is done within SoaML with the Expose Depend-ency. While this can be used as essentially just the inverse of a Realization between a Capability anda ServiceInterface it realizes, it can also be used to represent a more general notion of “providing ac-cess” to a general capability of a Participant. Figure 15 provides an example of such a situation.

«Participant»Manufacturer

Sales :Orders

«Capabili ty»Sales & Marketing

«ServiceInterface»Orders

Type

«Expose»

Figure 28: The Orders ServiceInterface exposing the Sales and Marketing Capability

Each Capability may have owned behaviours that are methods of its provided Operations. Thesemethods would be used to specify how the Capabilities might be implemented, and to identify otherneeded Capabilities. Alternatively, ServiceInterfaces may simply expose Capabilities of a Participant.

Public


5.5 Information ModellingThe following illustrates the modelling of the information aspect, i.e. the data that used processedwithin the services and exchanged among the participants. As in the above sections, we commencewith the definition of information models on the CIM level, and then exemplify the PIM level modelling.

5.5.1 CIM Level – OntologiesOn the CIM level, the relevant information shall be defined in terms of ontologies. As an example forthis, Figure 29 shows the ontology definition of the concepts Buyer and Order along with an axiomwhich states that defines an integrity constraint. The ontology is specified in WSML [Bruijn et al.,2008].

concept Buyer

ID ofType _integer

firstName ofType _string

lastName ofType _string

address ofType _string

city ofType _string

country ofType _string

telephonenr ofType _string

hasOrder ofType (0 *) Order

concept Order

orderID ofType _integer

issuesDate ofType _date

comment ofType _string

expireDate ofType _date

hasBuyer ofType (1 1) Buyer

hasOrderline ofType (1 *) Orderline

axiom orderID_LineItem

definedBy

!- ?order[hasOrderline hasValue ?ol] memberOf Order and

?ol[hasLineItem hasValue ?x] and?x memberOf LineItem and

?order[orderID hasValue ?value] and

naf(?x[orderID hasValue ?value]).

Figure 29: WSML Ontology Buyer-Seller Example

5.5.2 PIM Level – Information ModelsThe following shows the definition of the information models in the PIM level, here defined in terms ofUML Class diagrams.

Public


5.5.2.1 Buyer Information Model (UML Class Diagram)

Figure 30 shows the PIM level information model for the buyer. This contains 7 entities: Buyer, Order,Orderline, Lineitem, Item, InvoiceLine and Invoice.

Figure 30: PIM Information Model for Buyer

Public


5.5.2.2 Seller Information Model (UML Class Diagram)

Below, Figure 31 shows the analogue information model for the seller side. This consists of the follow-ing entities: Customer, PricedDocument, PurchaseOrderline, PurchaseOrder, Item, InvoiceLine andInvoice.

Figure 31: PIM Information Model for Seller

Public


5.6 SoaML Service ModellingAs the final aspect of our example, the following exemplifies the detailed modelling of services on thePIM level. This covers the following central concepts of SoaML.

In SoaML, a service is defined as an offer of value to another party, enabled by one or more capabili-ties. Here, the access to the service is provided using a prescribed contract and is exercised consis-tent with constraints and policies as specified by the service contract. A service is provided by a par-ticipant acting as the provider of the service—for use by others. The eventual consumers of the ser-vice may not be known to the service provider and may demonstrate uses of the service beyond thescope originally conceived by the provider.

As mentioned earlier, provider and consumer entities may be people, organizations, technology com-ponents or systems – we call these Participants. Participants offer services through Ports via the«ServicePoint» stereotype and request services on Ports with the «RequestPoint». These ports repre-sent points where the service is offered or consumed.

The service point has a type that describes how to use that service, that type may be either a UMLinterface (for very simple services) or a ServiceInterface. In either case the type of the service pointspecifies, directly or indirectly, everything that is needed to interact with that service – it is the contractbetween the providers and users of that service.

Figure 32 depicts a “Productions” participant providing a “scheduling” service. The type of the serviceport is the UML interface “Scheduling” that has two operations, “requestProductionScheduling” and“sendShippingSchedule”. The interface defines how a consumer of a Scheduling service must interactwhereas the service point specifies that participant “Productions” has the capability to offer that ser-vice – which could, for example, populate a UDDI repository. Note that a participant may also offerother services on other service points. Participant “Productions” has two owned behaviours that arethe methods of the operations provided through the scheduling service.

Figure 32: Services and Service Participants

Public


5.6.1 Service InterfacesLike a UML interface, a ServiceInterface can be the type of a service point. The service interface hasthe additional feature that it can specify a bi-directional service – where both the provider and con-sumer have responsibilities to send and receive messages and events. The service interface is de-fined from the perspective of the service provider using three primary sections: the provided and re-quired Interfaces, the ServiceInterface class and the protocol Behaviour.

The provided and required Interfaces are standard UML interfaces that are realized or usedby the ServiceInterface. The interfaces that are realized specify the provided capabilities, themessages that will be received by the provider (and correspondingly sent by the consumer).The interfaces that are used by the ServiceInterface define the required capabilities, the mes-sages or events that will be received by the consumer (and correspondingly sent by the pro-vider). Typically, only one interface will be provided or required, but not always.

The enclosed parts of the ServiceInterface represent the roles that will be played by theconnected participants involved with the service. The role that is typed by the realized inter-face will be played by the service provider; the role that is typed by the used interface will beplayed by the consumer.

The Behaviour specifies the valid interactions between the provider and consumer – the com-munication protocol of the interaction, without specifying how either party implements theirrole. Any UML behaviour specification can be used, but interaction and activity diagrams arethe most common.

The contract of interaction required and provided by a ServicePoint or RequestPoint (see below) aredefined by their type which is a ServiceInterface, or in simple cases, a UML2 Interface.

A ServiceInterface specifies the following information:

The name of the service indicating what it does or is about

The provided service interactions through realized interfaces

The needs of consumers in order to use the service through the used interfaces

A detailed specification of each exchange of information, obligations or assets using an opera-tion or reception; including its name, preconditions, post conditions, inputs and outputs andany exceptions that might be raised

Any protocol or rules for using the service or how consumers are expected to respond andwhen through an owned behaviour

Rules for how the service must be implemented by providers

Constraints that can determine if the service has successfully achieved its intended purpose

If exposed by the provider, what capabilities are used to provide the service.

This is the information potential consumers would need in order to determine if a service meets theirneeds and how to use the service if it does. It also specifies the responsibilities of service providersneed in order to implement the service.

Figure 33 shows a generic or archetype ServiceInterface. Interface1 is the provided interface definingthe capabilities, while Interface2 is the required interface defining what consumers are expected to doin response to service requests. The ServiceInterface has two parts, part1 and part2 which representthe endpoints of connections between consumer requests and provider services. Part1 has type Inter-face1 indicating it represents the provider or service side of the connection. Part2 has type Interface2indicating it represents the consumer or Request side of the connection.

The protocol for using the service is given in the Activity that is an owned behaviour of the serviceinterface. This activity shows the order in which the actions of the provided and required Interfacesmust be called. The consumer’s use of this service interface and a provider’s implementation must beconsistent with this protocol.

Public


Figure 33: Generic SoaML ServiceInterface

5.6.1.1 Participants and Service PointsParticipants represent software components, organizations, systems or individuals that provide anduse services. Participants define types of organizations,organizational roles or components by the roles theyplay in services architectures and the services theyprovide and use. For example, the figure to the right,illustrates a Manufacturer participant that offers apurchasing service. Participants provide capabilitiesthrough Service points typed by ServiceInterfaces or in simple cases, UML Interfaces that define theirprovided or offered capabilities.

A service uses the UML concept of a “port” and indicates the interaction point where a classifier inter-acts with other classifiers. A port typed by a ServiceInterface is referred to as a service point. Figure34 illustrates this.

Public


Figure 34: Example Participant with a Service PortA service point is the point of interaction on a Participant where a service is actually provided or con-sumed. On a service provider this can be thought of as the “offer” of the service (based on the serviceinterface). In other words, the service point is the point of interaction for engaging participants in aservice via its service interfaces.

5.6.1.2 The Service RequestJust as we want to define the services provided by a participant using a service point, we want to de-fine what services a participant needs or consumes. A Participant expresses their needs by making arequest for services from some other Participant. A request is defined using a port stereotyped as a«RequestPoint» as shown in Figure 35.

Figure 35: A Participant with Services and RequestsThe type of a Request point is also a ServiceInterface, or UML Interface, as it is with a Service port.The Request point is the conjugate of a Service point in that it defines the use of a service rather thanits provision. As we will see below, this will allow us to connect service providers and consumers in aParticipant.

The OrderProcessor participant example, above, shows that it provides the “purchasing” service usingthe “Purchasing” ServiceInterface and Requests a “shipping” service using the “ShippingService” Ser-viceInterface. Note that this request is the conjugate of the service that is offered by a Shipper, asshown in Figure 34 above.

By using service and request points, SoaML can define how both the service capabilities and needs ofparticipants are accessed at the business or technical level.

Public


5.6.2 Service ContractsA key part of a service is the ServiceContract. This defines the terms, conditions, interfaces and cho-reography that interacting participants must agree to (directly or indirectly) for the service to be en-acted. In other words, it provides the full specification of a service which includes all the information,choreography and any other “terms and conditions” for using a service.

A ServiceContract is binding on both the providers and consumers of that service. The basis of theservice contract is also a UML collaboration that is focused on the interactions involved in providing aservice. A participant plays a role in the larger scope of a ServicesArchitecture and also plays a roleas the provider or user of services specified by ServiceContracts. Each role, or party involved in aServiceContract is defined by a ServiceInterface which is the type of the role.

Figure 36: Example of SoaML ServiceContract

An important part of the ServiceContract is the choreography. The choreography is a specification ofwhat is transmitted and when it is transmitted between parties to enact a service exchange. The cho-reography specifies exchanges between the parties – the data, assets and obligations that go be-tween the parties.

The choreography defines what happens between the provider and consumer participants withoutdefining their internal processes – their internal processes do have to be compatible with their Ser-viceContracts. A ServiceContract choreography is a UML Behaviour such as may be shown on aninteraction diagram or activity diagram that is owned by the ServiceContract (Figure 37). The chore-ography defines what must go between the contract roles as defined by their service interfaces—when, and how each party is playing their role in that service without regard for who is participating.The service contract separates the concerns of how all parties agree to provide or use the servicefrom how any party implements their role in that service – or from their internal business process.

Figure 37: Example SoaML Choreography

Public


The requirements for entities playing the roles in a ServiceContract are defined by ServiceInterfacesused as the type of the role. The ServiceInterface specifies the provided and required interfaces thatdefine all of the operations or signal receptions needed for the role it types – these will be every obli-gation, asset or piece of data that the entity can send or receive as part of that service contract. Pro-viding and using corresponding UML interfaces in this way “connects the dots” between the servicecontract and the requirements for any participant playing a role in that service as provider or con-sumer. Note that some “SOA Smart” UML tools might add functionality to help “connect the dots”between service contracts, service architectures and the supporting UML classes.

It should also be noted here that it is the expectation of SoaML that services may have communica-tions going both ways – from provider to consumer and consumer to provider and that these commu-nications may be long-lived and asynchronous. The simpler concept of a request-response functioncall or invocation of an “Object Oriented” Operation is a degenerate case of a service, and can beexpressed easily by just using a UML operation and a CallOperationAction. In addition, enterpriselevel services may be composed from simpler services. These compound services may then be dele-gated in whole or in part to the internal business process, technology components and participants.

Participants can engage in a variety of contracts. What connects participants to particular service con-tract is the use of a role in the context of a ServicesArchitecture. Each time a ServiceContract is usedin a ServicesArchitecture; there must also be a compliant Service port on a participant – a Service-Point or RequestPoint. This is where the participant actually offers or uses the service.

One of the important capabilities of SOA is that it can work “in the large” where independent entitiesare interacting across the Internet to internal departments and processes. This suggests that there isa way to decompose a ServicesArchitecture and visualize how services can be implemented by usingstill other services. A participant can be further described by its internal architecture, the participantarchitecture. Such architectures can also use internal or external services, participants, business proc-esses and other forms of implementation. Our concern here is to show how the internal structure of aservice participant is described using other services. This is done by defining a participant Service-sArchitecture for participants in a more granular (larger scale) services architecture as is shown inFigure 22 and Figure 23 (see above).

The specification of a SOA is presented as a UML model and those models are generally consideredto be static, however any of SoaML constructs could just as well be constructed dynamically in re-sponse to changing conditions. The semantics of SoaML are independent of the design-time, deploy-time, or run-time decision. For example, a new or specialized ServiceContract could be negotiated onthe fly and immediately used between the specific Participants. The ability of technology infrastruc-tures to support such dynamic behaviour is just emerging, but SoaML can support it as it evolves.

Public


6 Future WorkIn this report, we have defined in the initial version of the SHAPE Methodology along with the firstversion of the tool support for creation customized methodologies. In accordance to the iterative de-velopment as defined in the Description of Work [SHAPE, 2007], the methodology will be continuouslydeveloped throughout the course of the project. This section outlines the refinements and extensionsthat are planned for the next versions of the SHAPE Methodology.

This covers the following aspects that we shall discuss in more detail below:

Refinements and extensions of the SHAPE Methodology Framework in order to better supportthe creation of customized methodologies as well as the management of the libraries

Methodological support for SOA system engineering on various technology platforms (SHA)and for service variability modelling

Methodology support for automated, semantically enabled compliance checking of service andbusiness process contracts, and

Methodology support for the creation, management, and usage of flexible business modelsthat shall enable business to timely react on changes.

6.1 Framework – Refinements and ExtensionsThe initial version of the SHAPE Methodology as defined in this report encompasses the definition ofthe overall framework (cf. Section 2), the specification of the description models for disciplines andmethods, the initial content of the Discipline Library and the Method Library (cf. Section 3), and thefirst version of the prototype of the tool support for developing custom methodologies (cf. Section 4).

With this, we have defined the basic architecture of a generic framework that integrates several state-of-the-art methodologies related to SOA system engineering and enables users to define customizedmethodologies for individual system development projects. However, it appears to be desirable toextend the basic framework with more advanced techniques in order to provide sophisticated supportfor users for the creation and management of custom methodologies as well as for the actual conduc-tion of a SOA system engineering project. In particular, we consider the following areas for improve-ments that we plan to address within the subsequent versions of the SHAPE Methodology: (1) refineddescription models for the methodology fragments in order to facilitate (2) enhanced support for thecreation, management, validation, and execution of custom methodologies by users, and (3) exten-sions of the SHAPE Methodology libraries with additional disciplines and methods. The following out-lines the planned enhancements in more detail.

6.1.1 Advanced Description ModelsThe SHAPE Methodology Description Model is a central element of our framework: it defines themeta-models for describing disciplines and methods, and the SHAPE Methodology Tool works uponthese descriptions in order to construct the engineering process for a custom methodology and sug-gest suitable methods from the SHAPE Method Library for its realization (cf. Section 2.3.1).

The current discipline description model (cf. Section 3.2.1) as well as the one for methods (cf. Section3.3.1) is basic. Together, they define the minimal set of meta-information that is necessary for thecreation of custom methodologies within the SHAPE Methodology Tool. In order to better support this,we consider the following extensions of the description models:

Enrich the description models, e.g.:

o Disciplines: more comprehensive descriptions to better support the management ofdisciplines and their usage for the definition of custom methodologies

Public


o Methods: specify the requested and resulting modelling artefacts, therewith integratingthe SHAPE methodology with the other technologies developed in the project

Include additional concepts, e.g.:

o tasks as more fine-grained parts of disciplines

o roles that describe persons, resp. skills and responsibilities in the engineering process

Apply formal specification languages for describing the usage conditions and dependenciesamong the disciplines and methods, e.g.:

o Preconditions and effects of disciplines and methods

o Rules and policies for suitable combination of methods with respect to the supportedmeta-models, notation, etc.

6.1.2 Enhanced Support for Custom MethodologiesThe SHAPE Methodology Tool represents the end-user interface for the creation of custom method-ologies as well as for managing the SHAPE methodology libraries. On the basis of more advanceddescription models for methodology disciplines and methods, we can enhance the functional scopeand quality of the SHAPE Methodology Tool for supporting the creation, validation, management, andmonitoring the execution of actual SOA / SHA system engineering processes. For this, we will investi-gate the follow opportunities:

Enhanced creation support for custom methodologies by

o Enhanced support for the search, selection, and composition of available disciplines,tasks, roles their dependencies on the basis of more fine-grained descriptions

o More adequate detection of adequate methods on the basis of usage policies

Validation mechanism for custom methodologies created by a user, including the indication ofpotential inaccuracies and suggestions for corrections

Monitoring facility for the actual execution of the system engineering project that follows a cus-tom methodology, providing an auxiliary project management facility.

In addition to the functional improvements of the SHAPE Methodology Tool, we will provide guidelinesfor its usage and assist in the elaboration of reference examples that will be developed in the courseof the SHAPE pilot use cases in WP1.

6.1.3 Extension of SHAPE Methodology LibrariesThe final aspect is the extension of the two SHAPE Methodology libraries, i.e. the Discipline Library aswell as the Method Library. For this, we will continue the iterative development approach as describedin Section 2.3.2. In particular, we plan to:

(1) Extend the SHAPE Discipline Library by

Refine the definition of existing disciplines

Add tasks and roles as additional elements

Apply the advanced description model

(2) Extend the SHAPE Method Library by

Refine the description of the existing methods

Continue the analysis of existing methodologies

Adapt methods towards SOA / SHA engineering and / or develop new ones.

Public


6.2 Methodology Support for SHAWithin the initial version of the SHAPE Methodology, we have focused on the methodological supportfor developing SOA systems with special attention to the usage of SoaML. This is the metamodel fordescribing services and their usage in SOA applications following the MDA approach, and denotesone of the central results of the project in the first year. In the second year, the project will focus on theextensions for heterogeneous technology platforms as well as the integration of service variabilitymodelling and the usage of semantic technologies, which shall result in an integrated framework forthe model-driven development of semantically-enabled heterogeneous service architectures (SHA).

In the course of this, the SHAPE Methodology will be extended as well, so that it will encompassguided procedures for the system engineering process of SHA systems with the modelling techniquesdeveloped within the project. The additional methodology components will be integrated into theframework that has been defined in this report, expectably with some extensions to the SHAPE Refer-ence Matrix and the overall system architecture.

The following outlines the approach for the methodology development for supporting the system engi-neering process with heterogeneous technology platforms and for service variability modelling. Thebasis for this has already been identified in the course of the state-of-the-art analysis in [SHAPE D2.1].The intended usage of semantic technologies is (1) for defining coherent terminologies in SOA / SHAsystems in terms of ontologies, and (2) for automated compliance checking of contracts between ser-vice providers and consumers. We will discuss the latter in more detail below in Section 6.3.

6.2.1 Heterogeneous ArchitecturesThe SHAPE project is developing an integrated framework for model-driven development of service-oriented systems with support for various technology platforms. This goes beyond the scope of mostexisting SOA approaches that merely build upon conventional Web Services, aiming at the integrationof other modern technologies in order to facilitate the exploitation of their respective benefits. Namely,the technologies that shall be supported by the SHAPE framework are: Conventional Web Servicetechnologies, Agent technologies, Semantic Web Services, P2P technologies, and Grid technologies.

The next versions of the SHAPE Methodology will include methods for supporting the system engi-neering process for the identified technology platforms. The additional methodology fragments will beallocated on the PIM and particularly on the PSM level in the SHAPE Reference Matrix. By definition,the CIM level defines computation-independent models wherein the technical realization of the systemand its components are not considered. On the PIM level, the modelling techniques for conventionalSOA systems will be extended with the concepts for specifying specific features that are facilitated bythe additional technologies, e.g. the use of software agents in order to realize required functionalitiesby a community of proactive and interacting components or the usage of semantic annotations to fa-cilitate advanced automated information processing. The translation of the PIM models into platform-specific technology models on the PSM level will be performed automatically by the model transforma-tions that are developed in WP5.

The following outlines the planned development of the methodology support for the various technologyplatforms. The extensions will be elaborated in accordance to the development methods for theSHAPE methodology as defined in Section 2.3.2.1, i.e. by analyzing existing methodologies, decom-posing them into smaller fragments, and then allocating these within the SHAPE Reference Matrix.The basis for this has already been elaborated within the state-of-the-art analysis [SHAPE D2.1], aswell as in the examination of relevant metamodels for the various technologies in [SHAPE D3.1].

6.2.1.1 Web ServicesThis relates to conventional SOA technologies that build upon Web Service technology. The methodo-logical support for this requires guided procedures for describing the services, the business process,the data, as well as the scope, goals, and the ecosystem of the target system. This is, for the mostpart, already covered in the initial version of the SHAPE Methodology presented in this report. For thefuture versions, the existing methods and disciplines will be refined and extended as described above.

Public


6.2.1.2 Agent Technology

Agent technologies are concerned with the systems that are realized as a community of autonomouslyand proactively acting components (= agents) that interact among each other in order to achieve theirindividual goals. The purpose of integrating this into the SHAPE technology is to enable the developedof agent-based applications that run on top of service-oriented infrastructures, e.g. advanced planningsystems that work upon distributed information sources offered in form of services as defined withinthe Saarstahl use case, cf. [SHAPE D1.1].

Similar to the SOA-part of the SHAPE Methodology, we can reuse and integrate the large amount ofalready existing methodologies for agent technologies for developing the necessary methodologicalsupport. This has been analyzed in detail in [SHAPE D2.1], where we identified 5 potential candidatemethodologies; Gaia, PASSI, ADELFE, Tropos, and Prometheus. In accordance to our developmentmethod, we will decompose these methodologies into reusable method chunks and allocate them intothe SHAPE Matrix. We will also extend the description models for methods and disciplines in order tocover the specific characteristics of the methods agent-oriented development.

6.2.1.3 Semantic Web Services

Semantic Web Service technologies (short: SWS) aim at automating the service usage cycle withinSOA applications by providing automated mechanisms for the discovery, selection, and compositionfor suitable Web services for a given client request. These mechanisms work on rich annotations ofservices that are based on ontologies, which further can ensure the semantic interoperability amongthe parties interacting in a SOA / SHA applications.

As this is a rather young research field, comprehensive and widely accepted methodologies for thedevelopment of SWS systems do not yet exist. However, there are ongoing research efforts on this,and we will integrate the results into the SHAPE Methodology. A particular approach for guiding thedevelopment of SWS-based techniques automated contract compliance checking is discussed in de-tail below in Section 6.3.

6.2.1.4 P2P Technology

P2P technologies are concerned with distributed computing where the peers interact directly without acentral control unit. The motivation for integrating such techniques into SHAPE is to enable the usageof P2P technologies, particularly scalable networking technologies that allow the management of largenumbers of services with SOA / SHA applications.

So far, methodologies for P2P system development have not been analyzed in detail in the course ofthe project. However, there are a number of recent research efforts wherein methodological supportfor the development and maintenance of P2P systems is developed (e.g. JYTA or GNUTELLA). Weplan to investigate these efforts in order to determine the SHAPE Methodology components for sup-porting P2P-based modelling of SOA / SHA systems.

6.2.1.5 Grid TechnologyGrid technology is concerned with the sharing, selection, and aggregation of data and services fromvarious distributed resources in a scalable manner. This shall be included in the SHAPE framework inorder to enable the usage of Grid infrastructures within service-oriented systems.

Research on Grid technology is also a rather young discipline, so that well established methodologiesdo not exists yet. However, there are some research efforts that can serve as a basis for developingthe necessary components of the SHAPE Methodology in order to supporting the modelling of SHAsystems that use Grid infrastructures. For this, we in particular plan to investigate the GeSMO frame-work, a unifying framework for Web Services, P2P Services, and Grid services that has been devel-oped in the SODIUM project [Berre et al., 2006].

Public


6.2.2 Service VariabilityService variability enables the enhancement and adaptation of services to the customer’s specialneeds, which is an important property in modern service development. By utilising variability tech-niques, highly reusable services can be created, thus simplifying development, cutting costs and de-creasing time to market.

The SHAPE Methodology will be extended to handle service variability. The requirements for the vari-ability support are:

Model-based representation of service-oriented features (commonalties, variability and de-pendencies)

Integration in the model-driven development chain to derive variants at different abstractionlevels

Configuration at different binding times (design-, deploy-, run-time)

Different scopes of variable services depending of the user role.

In [SHAPE D2.1] some methodologies from the area of Domain Engineering are introduced, whichprovide methods for analyzing and modelling commonalities and variable features of a system. Re-lated to MDA these methods have their focus on the CIM-level but variability tends to crosscut differ-ent levels of the service development life-cycle, so that additional methods must be defined.

The most promising candidate of the introduced methodologies is Feature-oriented Domain andAnalysis (FODA) [Kang et al., 1990] which defines an iterative process to analyze the features of agiven domain. The methodology also defines Feature Models, which is a well-known approach to de-pict features in a tree-like structure. However as already mentioned FODA covers variability modellingonly on CIM-level.

There will be two main tasks of the SHAPE project regarding variability modelling:

1. Modelling of variability on PIM-level

2. Transforming of the models between the different levels.

The variability model related to the first task will be developed in WP3 and the transformation in WP5.These will be integrated in a Variability Editor which will be implemented within WP4.

6.2.2.1 SHAPE Variability Model

We will develop a metamodel for variability modelling on the PIM-level. An initial version has alreadybeen defined in [SHAPE D3.2]. The requirements for this metamodel are:

The metamodel must be a extension of the ShaML Metamodel or the ShaML UML2 Profile

To configure the functionality the selection and de-selection of service operations and attrib-utes of related objects must be supported.

Parameterization of service operation parameters and attributes of related objects.

The metamodel must support the extension of objects with attributes and the extension of theservice interface with operations.

The variability should be modelled in an orthogonal way.

Orthogonal modelling says that the variability is defined in an explicit and separate way. Thus, thevariability information is not integrated in the target model, which leads to a reduced complexity andmore flexibility, because one target model can be associated with different variability models.

6.2.2.2 Model Transformations for Variable Services

The model transformation for variable services is content of WP5. At one hand there must be devel-oped transformations for the development-process on provider-side and on the other hand transforma-tions for the configuration-process of the service on consumer-side.

Public


The development process should support at least a semi-automatic transformation from a FeatureModel on CIM-level to the ShaML-Variability Extension on PIM-level. The transformations from PIM tothe different PSM-models must be fully automated.

The configuration of a variable service must be end user friendly, which also requires a fully auto-mated transformation process. At first the user has to select and parameterize the needed features,which will be taken as additional input to the generic variable service in order to create the service forthe consumer’s special needs.

6.3 Contract Compliance CheckingAs one of the advanced features, the SHAPE Methodology will encompass a facility for automaticallychecking the compliance of contracts between services, respectively between business processes.The aim is to determine whether the interaction and information exchange between a service and itsconsumer can be carried out successfully, respectively if a business process can be executed properlywith respect to the information exchange among the services that it is composed of.

This facility shall be enabled by applying Semantic Web Service techniques. The following gives abrief overview of the approach, which will be further elaborated within the next versions of the SHAPEMethodology.

6.3.1 Overview and AimSemantic Web Services aim to reduce the amount of human effort involved in the creation of applica-tions based on the Service Oriented Architecture (SOA) paradigm through the introduction of Seman-tics. Providing semantic descriptions of Web services and user requirements (as Goals) enables amachine to reason about the functionality and interface of the different services available with respectto the desired functionality and interface of the user. Thus it is possible to dynamically match userdesires with available services and automatically enable the resolution of heterogeneity mismatchesbetween these services at the protocol, process and data levels.

In order to build Semantic Web Services a service engineer must create ontologies that represent theterminology of the domain of the services, using this terminology the engineer must then create a de-scriptions of the functionality that each of the services offer and the means by which an end user caninteract with each service. The engineer may also provide a number of Goal templates, which repre-sent potential needs that a given end user may have. These templates can then be used by end usersas a starting point for creating their semantic descriptions of their requirements. The engineer mayalso wish to define some mediators between the terminology in the ontologies that he has created andany standard ontologies. These mediators ensure that when users Goals are created using differentterminology, they will still match against his Web services. These mediators can also be reused toenable data mediation at invocation time, such that end users can provide instance data in terms oftheir terminology and these instances can be transformed to the correct instances expected by theservice. Crucially the engineer must also provide a grounding mechanism by which the ontologicaldescriptions of data can be grounded back to XML, such that they can be sent to the service in anSOAP message. Finally, all descriptions of Ontologies, Web services, Goals, Mediators and ground-ings must be registered with a Semantic Execution Environment (SEE) such that they are available tobe used dynamically at runtime to enable a Semantically Enabled Service-oriented Architecture(SESA) [Fensel, et al. 2008].

Even though a lot is understood about the activities that the engineer must perform, as can be seenabove, no methodology exists that can be followed by engineers in a given project, such that they canimprove that chance of success of the development efforts within that project. Within the scope of theSHAPE project we will use the WSMO conceptual model [Fensel, et al. 2007] and WSML language[Bruijn, et al. 2008] for describing semantic Web services and use the WSMX Semantic ExecutionEnvironment for enabling a SESA. To ensure that these technologies can be used effectively withUML and UMPS, a methodology for Semantic Web Services will be created, in the course of theSHAPE project, which documents all of the activities that must be performed in the development cycle

Public


of Semantic Web Services. This methodology will cover the complete development cycle from re-quirements, though design, implementation, testing and deployment to ensure full coverage of all theactivities that must be performed. The methodology will take input where possible from existing Webservice methodologies as outlined in this deliverable and also from the knowledge management meth-odologies and ontology engineer methodologies, which have many similarities to the conceptual mod-elling tasks that must be conducted in the course of creating Semantic Web Services. One of the cru-cial inputs to the SHAPE methodology for Semantic Web Services is the work conducted in the Euro-pean funded SWING project, which applied ontology engineering practices to the construction of Se-mantic Web Services for geospatial applications. This will serve as a starting point and will be general-ized and extended to create a General Semantic Web Service methodology.

6.3.2 The SWS Choreography Method

6.3.2.1 Problem statement

The focus of this section is modelling of behavioural aspects of services, and service contracting andenactment. In a service-oriented environment, interaction is expected among large numbers of clientsand service providers, and contracts through human interaction are out of question. To enable auto-matic establishment of contracts, a formal contract description language is required and a reasoningmechanism is needed to be able to verify that the contract terms are fulfilled. A contract speciation hasto describe the functionality of the service, values to be exchanged, procedures and guarantees.

6.3.2.2 ApproachOur approach is based on Concurrent Transaction Logic (CTR) [Bonner and Kifer 1996] and continuesthe line of research that looks at CTR as a unifying formalism for modelling, discovering, choreograph-ing, contracting, and enactment of Web services [Davulcu, et al. 2004, Senkul, et al. 2002]. This previ-ous work, however, was conned to straight-line services, which cannot do repeated interactions seri-ous limitation in view of the fact that the emerging languages for specifying the behaviour of Web ser-vices, such as the Web Services Choreography Description Language (WS-CDL) [W3C 2004] or WebServices Business Process Execution Language (WS-BPEL) [OASIS 2007], identify iterative proc-esses as core elements of their models. The present paper closes this gap by extending the previouswork to cover choreography of iterative processes. CTR can thus be used to model and reason aboutgeneral service choreographies, including the ones definable by very expressive languages such asWS-CDL and WS-BPEL. We obtain these results by significantly extending the language for servicecontracts and through a corresponding extension to the proof theory of CTR.

6.3.3 Modelling, Contracting and Enactment of ServicesIn [Roman and Kifer 2007] we identified three core service behaviour aspects of service contracting:(1) Web service choreography – a specification of how to invoke and interact with the service in orderto get results; (2) Service policies – a set of additional constraints imposed on the choreography andon the input; and (3) Client contract requirements – the contractual requirements of the user, which gobeyond the basic functions (such as selling books or handling purchase orders) of the service.

The choreography of a service is described with control and data flow graphs, and service policy andclients' contract requirements are described with constraints. We defined the problem of service con-tracting as: given a service choreography, a set of service policies, and a set of client contract re-quirements, decide whether an execution of the service choreography exists, that satisfies both theservice policies and the client contract requirements. Furthermore, the problem of service enactmentwas defined as finding out whether enactment of a service is possible according to a contract and, ifso, finding an actual sequence of interactions that fulfils the contract.

Public


Figure 38: A Hierarchy of Control-flow Graphs with iterative tasks

6.3.3.1 Service Choreographies

Figure 38 shows a service choreography depicted as a control flow graph of a fairly complex virtualmanufacturing service. Control flow graphs are usually used to specify local execution dependenciesamong the interactions of the service by visualizing the overall control flow. The nodes in such a graphrepresent interaction tasks, which can be thought of as functions that take inputs and produce outputs.In Figure 38, tasks are represented as labelled rectangles. The label of a rectangle is the name of thetask represented by that rectangle, and a graph inside the rectangle is the definition or decompositionof that task. Such a task is called composite. A control flow graph can thus be viewed as a hierarchy oftasks. There is always one composite task at the root of the hierarchy. In our example, handle order isthe root; its subtasks include handle items and handle shippers. These subtasks are composite andtheir rectangles are shown separately (to avoid clutter). The task place order is an example of a primi-tive task: they do not have associated graphs, and are denoted by rectangles with gray background.

6.3.3.2 Service Policies and Client Contract Requirements

Apart from the local dependencies represented directly in control flow graphs, global constraints oftenarise as part of policy specification. Another case where global constraints arise is when a client hasspecific requirements on the interaction with the service. These usually have little to do with the ser-vice functionality (e.g., handling orders), but rather with the particular guarantees that the client wantsbefore entering into a contract with the service. We call such constrains client contract requirements.In (1) we give an example of global constraints that represent service policy and client contract re-quirements for our running example. Note that all the constraints in this example are on iterative tasks.

6.3.3.3 Service Contracting and EnactmentWith this modelling mechanism in place, we define service contracting and enactment as follows:

Service contracting: for a given a service choreography (i.e., a hierarchical control flowgraph containing iterations) and a set of service policies and client contract requirements (i.e.constraints), decide if there is an execution of the service choreography that complies bothwith the service policies and the client contract requirements.

Service enactment: if service contracting is possible, find out an actual order of interactionsthat fulfils the contract, and execute it.

Public


6.4 Flexible Business ModellingAnother advanced feature of the SHAPE framework will be the integration of latest research results onflexible business modelling. The aim is to provide means that enable business to quickly react onchanges in the environment (market, customer requirements, etc.), which allows them to maintain theircompetitiveness in global markets and gain a competitive advantages. The following outlines the ap-proach for flexible business modelling that will be further elaborated throughout the project.

6.4.1 Aim and Overview

6.4.1.1 Core Competence: Ability to make business

In the past, companies often tried to achieve an increase in efficiency through internal improvementsand organic growth. However, companies of all sizes face an ongoing globalization, fast changingtechnical environments and increasingly sophisticated customers. Thus, they have to cope with severecompetition and high requirements in terms of flexibility. Consequently, the concentration on the corecompetencies and the systematic supplementation of missing abilities and/or products through coop-eration becomes more and more important for the success and survival in today’s business environ-ment. Within such an economy of globalization, the factor time is becoming more and more business-critical. Enterprises are forced to quickly react on market changes and new business opportunities.Referring to this, innovation and flexibility are getting the new critical success factors for businesses.Apart from “classical” core competence orientation, a second stream of management is being estab-lished: The ability to always be prepared to initiate or to join new businesses. Even as these plug-and-do businesses are becoming more important, this topic is only slightly assessed, both in theoreticalfoundations and in organizational research.

Therefore, the objective of this section is to investigate on the nature of Enterprise Interoperability andto assess the way it directs the implementation of enterprise systems. The following first introduce thebasic concepts of Flexible Business Models discussed from a business oriented point of view. Then,we present the first Flexible Business Model Framework on base of SoaUML. Finally, we will drawconclusions and will provide an outlook on future research directions and challenges.

Modelling is now an integrated part of software engineering approaches. Business process models arewidely used to describe how work is done within an organization, while various product models de-scribe what is done. Various approaches based on model-driven engineering (MDE) concepts, suchas the OMG MDA (Model Driven Architecture) and related efforts around domain-specific languageshave gained much popularity. Business models are described in the computation-independent models(CIMs). For the product models, the model-driven approach separates platform-independent models(PIMs) from the platform-specific ones (PSMs) in order to abstract the implementation technologies.

The MDE approach, however, has some weakness in the current state:

While MDE provides the possibility of mapping a model to different platforms, it is still focuseson the needs of a single business and does not meet the challenge of interoperability betweenbusinesses or domains.

There are no standards for developing PIM models for different sectors, and thus the ap-proaches are ad-hoc, making composition difficult.

It is difficult to take the step from business requirements that describe the functionality for out-siders, to PIMs that describe the functionality as provided by the solution.

The increasing popularity of SOA technologies relies on its ability for solving interoperability problemsin multiple domains. SOA models are closer to business models and thus reflect business goals in away that allows easier composition and enactment. However, there exist several SOA implementa-tions tied to different technologies. All these implementations lie at a low level of abstraction containingmany technical details. The outcome of this situation is that business requirements are often inter-twined with the final specification, constraining the evolution of business requirements and SOA im-plementations. Besides, each technology implies the use of different approaches to solve the sameproblem.

Public


Several research initiatives have taken place around some of these problem domain components.Some of these efforts have been focused on the enhancement of service provisioning platforms, whileothers have worked on the provision of the methodologies and technologies to deal with requirementsevolution towards specific platforms.

Due to the increasing heterogeneity and dynamics of the infrastructure, more and more roles in enter-prises are challenged to work together and to adapt continuously to rapid technological changes. Newcommercial settings, modernization, the need for improved quality of service, the search for competi-tive advantages and innovations as well as rapid technological advances create a new dynamic andcomplex modelling environment, which requires flexibility and mobility from enterprises informationtechnology architecture governance. For these reasons different roles have to cooperate in order tomodernize and innovate the information systems, to provide employees and industries with new ser-vice offers, to encounter the contemporary prevalent high cost pressure, to reduce the current admin-istrative overheads as well as to stay globally competitive.

6.4.1.2 Goals and challenges of flexible business modelling

The overall goal followed with the conceptualisation of flexible business models is to ensure the inter-operability and flexibility of service-oriented information systems. This is done by specifying, develop-ing and testing a tool-supported methodology for designing and implementing flexible business modelswhich are based on parameterised services on a Semantically-enabled Heterogeneous service Archi-tecture (SHA) through model-driven engineering (MDE) approaches and standardisation.

There are three main challenges in the field of interoperability to ensure flexibility. On the basis of theflexible business modelling framework the complexity in this research area will be further discussedand explained (see Figure 39).

Aud

ienc

es Exte

rnal

Inte

rnal

Hyb

rid

Busines

s fiel

ds

Figure 39: The Flexible Business Model Framework

The inter-human barrier can be distinguished into two types of barriers. First the focus lies on the en-hancement of the interoperability between the different types of audiences. This is the vertical dimen-sion. Then the communication between humans of one type of audiences can be improved. This is thehorizontal view. And last the cross-organizational communication as mixture of both views should bethe goal to achieve.

Between the different types of audiences the problem consists in the specialization of each kind ofaudience concerning the operational activities. Due to missing links of knowledge between the audi-

Public


ences the communication costs raise which can only be handled by more coordination between pro-grams and projects and more explanation within the participating members. The first need is the inter-operability between different audiences, such as

Strategy Consultants,

Business Analysts,

Process Designer,

System Architects,

Software Engineers.

The solution might be to enable the communication by using a common language which provides in-teroperability or by mapping different languages.

This is not trivial, because of the different subjects each type of audience treats. Generally objects,models and tools have to be distinguished. For example a strategy consultant working in the purchas-ing department talks in his language about business objects, like “supplier”. When he wants to deploya new Enterprise Architecture and has to align the won ideas with Process Designer and System Ar-chitects he has to switch his language model and has to understand the more technical level whichare focused by other audiences. He becomes confronted with process models and data models, whichare very formal and hardly to understand to foreign persons. The Process Designer focuses the pur-chase process or the supplier rating process, the System Architect is used to design data models toensure the structuring of the relevant data for this process. As a requirement there has to be estab-lished a linkage between business objects and information models and there elements in general.

As mentioned before, there are two basic types of inter-human barriers. The second one exists be-tween different humans of the same type of audience. They can be related to one subject or to sev-eral. The following example shows the complexity between persons of one audience concerning thesubject: model. System Architect A uses the UML class diagram to represent the data architectures ofa business object, system architect B uses the Entity Relationship Model. When they want to comparetheir data architectures they have to map their classes and entities. For large data models this be-comes very difficult. Additionally then when they use different tools which aren’t compatible concerningthe import/export interfaces. This is the basis for a second requirement.

The driver to rise to this challenge is the save of money in design processes of information systems bysaving communication costs by misunderstanding. Being able to navigate these two dimensions is toenable cross-organizational interoperability concerning audiences, and subjects. Interoperability is oneof the most important factors in the design process of information systems. This should be the startingpoint for our design of flexible business models.

6.4.2 Flexible Business ModelsThe main effect in developing flexible business models is the shift in design from the PIM-level to theCIM-level. A scenario for the underlying case of today’s future research the UPMSHA standard en-ables MDE on the PIM- level and ensures the flexibility in standards in addressing heterogeneousarchitectures. UPMSHA provides the necessary interfaces to the CIM-level languages BPMN, BMMand ODM.

The three standards on CIM-level have to be used in combination. The ODM metamodel defines thestructure of information which can be used during the design process and further in the implementa-tion and the use of the underlying infrastructure. The resulting ontology is based on OWL and is stor-age of information and definitions for all entities used by the modellers. The Ontology provides coher-ency between the entities audience, object, model and tool and all their derived subtypes. The BMM isused to define all business relevant information to achieve the goals of an enterprise. This comprisesthe vision of an enterprise and the different mission of specific departments of it. The main interestconsists in defining the ends of an enterprise and their explanation in means. The ends define whatshould be achieved, and the means define the ends for time, scope and scale. Further the BMM con-siders more complex definitions like business rules, influencer concepts and alternatives. The opera-

Public


tive transformation in BMM is the definition of processes, called courses of action. They are named butnot described respectively modelled. The BPMN standard overtakes the courses of action into fullyimplemented processes. Derived from BPMN the necessary BPEL code can be created and used forthe definition of Services.

6.4.2.1 Design ConceptsAs initial version of a framework to enable flexible business models we begin with the ontology whichshould contain the relevant information used in the design process. The ontology should contain allrelevant data about the different audiences and their objects, the information models and their ele-ments respectively the tools which are used to describe them. All the semantic information about thespecific entities and their relations are described within an ontology. The ontology is domain inde-pendent so that it can be used for an application which is capable of reading ontologies for each kindof business, model, tool and audience. The tool is further called flexible business model tool andbases on the Eclipse GMF Editor using ECORE as (see Figure 40).

Con

side

rsG

enerate

Figure 40: Flexible Business Model Tool

6.4.2.2 EnvironmentTo achieve a maximum of flexibility the enterprise must be able to define the different environmentalstates which influence the business. Every part of the environment can be seen as system of the realworld. Dietz describes the structuring of the different system types in an ontological notion for enter-prises as follows. An enterprise is a collection of socially linked human beings. The brains of theseindividuals are parts of them but do not qualify as members of a social system because they do notenter independently into social relations. Likewise, brains are a biological system, but the molecules inthe neural cells do not qualify as components of a biological system; they are physical systems.Therefore we need a common understanding which kind of system we describe within models. This isa very low point of view which discusses the distinguishing between types of different systems onbase of their discipline. The importance can be clarified when we refer to the sales order process as abehavioural model of a business oriented social system. To react on unforeseen changes of the envi-ronment, it has to be clear if it treats about an industrial sales order process or a retail market salesorder process. Only the enrichment of information models with the semantic of the systems they rep-

Public


resent in the real world can assure the correct transformation of metamodels to provide interoperabilitybetween different information models.

6.4.2.3 Audiences and language modelsThe structuring begins with the audiences, because they are assumed as the user for the flexiblebusiness model tool. The types strategy consultants and business analysts mainly use business ob-jects when they define models for business purposes. The business analyst should additionally beable to understand process elements to act as an interface between the business requirements andtheir implementation in processes. The process designer as a specialist in collecting business re-quirements and their implementation in process chains understands all concepts of process modelelements and their specialized sub models like for example organigrams, data models, function de-composition diagrams output diagrams and others. Therefore the process designer is the intercon-necting building stone in building enterprise architectures. He is supported by the specialized systemarchitects who have a more technical and less business oriented view as the process designer. Theyalign the business requirements which are formally described by the processes into the architecturesof the underlying information systems. The implementation is done by the software engineers who areused to all different types of models.

Language mostly is represented in unstructured documents. For example a Blueprint is written as atextual document and contains additionally information in tables and graphics or parts of them.

Process models are designed in different environments like eclipse, alfabet and ARIS. SpecialisedModel elements are used in special environments like Rational Rose and Eclipse as well.

The differentiation of objects can be done easily by considering their purpose. Business objects aremainly used as part of the language to talk about business. They are the unique entities which repre-sent and describe the phenomena and concepts in the real world. They are used in the language, inmathematics or for example by defining rules. They are needed to create contracts or agreements toensure reliable business behaviours and states for interacting people, projects, companies and indus-tries.

Reliability can only be proofed by using some kind of formalism. This formalism is only achievable byusing models. Therefore process models as integrating component of information models are used toprovide reliable formalism on the one hand and understanding by human-readable content on theother hand.

6.4.3 Ontology-driven Flexible Business Models as an exampleMany approaches try to cover the span between heterogeneous architectures on the IT-side and eco-nomical interests defined by business requirements on the other. We want to present our initial versionto solve this complex multidisciplinary transformation process. Our main concept to enable, establishand perform the necessary metamodel transformations is the use of ontologies as basic structure forfurther knowledge bases. To provide an insight into the ontology-based flexible business modelling westart with the presentation of the triples defining the class structure for the ontology we determine astop-ontology. The triples consist as used of Subject, predicate and object.

6.4.3.1 Map and Category ConceptsThe map concept provides a basis for integrating the main important entities business object andprocess on the one hand and categorizing and distinguishing them on the other hand. A map can beseen as a container for one domain. The business object map subsumes all in a specific domain usedbusiness objects. The process map contains analogical all processes needed for operating business.The diacritic element is the category, which can be used to arrange business objects and processes. Itis divided into the general category concept and a specialized category concept for specific entitieslike business objects, rules and processes (See Figure 41).

Public


Figure 41: Map Concept

6.4.3.2 Entity ConceptThe differentiation between business objects and processes has characteristic reasons. Businessobjects are seen as structural, because they define the requirements for dependent data. In contrastto business elements processes define the behaviour of a system. They make use of business objectsto support the behavioural aspects with the necessary data. Both, business objects and processes areinfluenced by rules. Rules can be used for implementing contradicting definitions or for maintainingconsistency of the relations and specific commercial or technical purposes which exist between busi-ness objects and processes (see Figure 42).

Figure 42: Conceptual entities

6.4.3.3 Model conceptModels as hypothetical descriptions of complex entities or processes are based on mental models.Mental models are the underlying nested phenomena which humans implicitly use to structure theirworld and to understand their environment for reasons of interaction.

In our point of view they have to be mapped in an initial version into the main concepts rule model,business model and process model, each belonging to its entity concept explained before. Because oftheir nature as a part of a mental model which here is generally described as model they are designedas a “is a”-relation (see Figure 43).

Figure 43: Model concept

Public


In reality the first explication of mental models happens by using documents for business purposes.The very first phase of explanation of the thoughts about the world happens in unstructured docu-ments like for example textual, table or graphical documents or a mixture of them. Designing informa-tion systems is a very dangerous field concerning the quality of service. Therefore structured docu-ments are irrecoverable for reasons of liability and expectation of a new information system (seeFigure 44).

Figure 44: Document concept

Structured documents are typified by information model types. They make use of the informationmodel element types which belong to their model or to several of them (see Figure 45).

Figure 45: Information model and element typesAs seen before we only discussed conceptual representations to structure the top-level ontology on anabstract level. The really important content which should be accessed can be found at the bottomlevel. For unstructured documents content is represented by text, graphic, table, audio or video docu-ments. Also a mixture of them can occur which is in most cases the established form. For example ablueprint consists of text, graphics and tables. Structured documents can be represented by informa-tion models which make use of information model elements. They can be distinguished into data mod-els, process models and all other existing information models respectively their elements (Figure 46).

Figure 46: Content concepts

6.4.3.4 The combination of all concepts

We introduced the different concepts for reasons of clearness and simplicity. To nest the concept lay-ers into a working ontology we need the relations between them. The specific maps are used as con-tainers for the conceptual entities which are designed as their specific models. Every specific model isa general model as seen in the third layer. Therefore every model can be described by unstructured orstructured documents. They are typified by document types or by information model and informationmodel element types (see Figure 47).

Public


Figure 47: The Overall ModelThe objects are distinguished into business objects, information model elements and informationmodels. The integration of the different concepts is showed now by means of the purchase function ofan enterprise (see Figure 48). In this example, the classes represent the ellipses the name of the classis normal, the type of the class is represented in italic font. For the example the basic map is the initialstarting point. This map contains all entities which are used in all activities of an enterprise. The map issubdivided into the purchase map, which is a business object map and the purchase process mapwhich contains all processes around the purchase functions. We leave out rules to make the examplenot too complex.

One relevant business object in the purchase function is the supplier. On the other hand we can imag-ine the process vendor rating in the purchase function as one process which uses the business objectsupplier. When talking about the supplier and the vendor rating process, a generic model about thesupplier itself which here is divided into the specific models for business objects and processes ap-pears. When we want to formalise this (mental) model about the supplier into machine-readable mod-els for implementation purposes, we need typed information models. In this case, the supplier modelas business object is typified as UML data model. All the relevant elements, which are needed to haveenough information about a supplier, should be implemented here. In case of the vendor rating proc-ess BPMN is used as the process notation to model all relevant activities and events of this process.All the typed, model-specific model elements are part of the information models.

Public


Figure 48: Example Purchase

In this way the example shows a conceptual semantic conduction of general concepts like the mapconcept over business relevant concepts like the business object and process concepts until informa-tion model specific properties like information model elements. The ontology should be used as thecenter of all further concepts we will introduce in the next time. In detail the information model can beenriched by a set of different information models which can be used to perform mapping conceptsbetween them. The business objects can be used to nest different independent processes. The maineffort can be seen in the parallel working space on the conceptual level and the implementation level.

6.4.4 The Core Elements of Flexible Business ModelsThe discourse of flexibility is discussed in various disciplines, but what does flexibility stand for inmeans of enterprise architectures? Enterprise Architectures reflect the enterprise from different pointsof view. But they rarely describe the business itself, which sets the requirements for an enterprise.Therefore we want to present the modelling of business models which have an impact on the designof enterprise architectures. The decomposition of the term business model returns that business mod-els can be seen as a conceptual instrument, which contains a large set of elements and their relationsand which allows expressing the business logic of a specific firm. It is used to describe the addedvalue offered to one or several segments of customers by a company. They are also usable for show-ing the enterprise architecture and its network of partners. The advantage of flexibility can be shownby the following comparison. Variability describes the property of an enterprise to respond to environ-mental changes which have been foreseen. Flexibility in contrast means the ability to be responsive to

Public


environmental changes which haven‘t been foreseen. Following this conception, we define a flexiblebusiness model as:

“A business oriented metamodel, which enables an enterprise the ability to react on unforeseenchanges of its environment. And they form the base for the underlying Components of the SOA-based

Enterprise Systems“

A very important point is the involvement of two things in this definition. First the including of the envi-ronment of an enterprise and second the mentioning of SOA-based Systems, which have to be seenas result of a model driven engineering (MDE) process based on flexible business models.

Figure 49 provides an overview of the core elements of Flexible Business Models. Below, we discussdifferent possibilities for specifying the elements with respect to the state-of-the-art in MDA.

Figure 49: Structure of Flexible Business Models

Newer approaches show that there are some first standards which can be used for doing a ModelDriven Engineering (MDE) approach from the Computation Independent Model (CIM) level. Thisshows the SOA Pro approach, just in development in name of the OMG. The approach provides thecombination of business processes and information following specific business drivers modelled withina business motivation model. As standards the Business Process Modelling Notation (BPMN) for proc-esses and the Ontology Definition Metamodel (ODM) for information are used. The Business Motiva-tion Model (BMM) serves as notation for designing the business drivers.

As Modelling Languages at the CIM level, they can be used to define (meta-) information which can bedone by using ontologies to describe and differentiate things occurring in the real world. Furthermore,the motivation and business environment can be described by using the Business Motivation Model

Public


(BMM). At the end, the way how it should be done is described using the Business Process ModelNotation (BPMN).

The most accepted definition of an ontology is from Gruber and Studer which was unitized fromProbst. In this understanding, an ontology “is a formal, explicit specification of a common shared con-ceptualisation”. The important properties of an ontology are its formalism, the explication of implicitknowledge with the aim to share it and to unify it. These ideas underlie the concept of the SemanticWeb which was mentioned by Tim Berners-Lee as a future internet. The unique description of realworld-phenomena with the Resource Description Framework (RDF) on the model level is extended bythe Web Ontology Language on the meta-model level is used to subsume those model-entities intogeneralised concepts and to model differences between classes by using more complex structureslike rules, sets and taxonomical aspects. In fact, XML-based ontologies follow the concepts of theFuture Internet, namely Coherency, Openness, Scalability, Dynamicity and Pro-activeness, PartialPredictability (flexibility) and Trust.

The business environment can be described by using the BMM (Business Motivation Model), an es-tablished industrial standard from OMG. BMM standardizes common business terms and businessrelationships. It provides an open medium for communicating business plans. Furthermore, it bridgesthe relations between the WHAT and the WHY to the HOW by providing specification mechanisms forbusiness processes, business rules and the organizational structure. The BMM metamodel is basedon four basic concepts and includes ontological aspects and organizational aspects. First, the influ-encing aspects can be included into the BMM. Influencer can be other competitors, supplier or cus-tomer but also internal influencers like employees. On the base of the assessed impact of the influen-cer the ends and means are described to plan the next steps within the business. Via ends, businessgoals can be described as a vision, explicate goal or more detailed objectives. Furthermore, it is pos-sible to express how those goals relate to the mission, the business strategy and underlying tactics.Additionally, it is possible to enrich the model by rules and policies. These concepts are grouped asmeans. The last entity is the course of action, which follows as result of the prescribed situation andthe goals.

Describing operational sequencing and synchronization is mainly done by using Process DiagramNotations such as Event-driven Process Chain (EPC) or Business Process Modelling Notation(BPMN). Both provide businesses with the capability of defining and understanding their internal andexternal business procedures through a Business Process Diagram, which will give organizations theability to communicate these procedures in a standardized manner. To become connected and inter-operable, the partners have to be coherent in their enterprise descriptions. One way to do this is touse models, which represent the world a bit more formal and simpler. These models describe thebusiness objects and explain the main concepts of enterprise organisation, process flow and rules.The organizational, functional, data and deliverable perspective are integrated within the process view.Therefore, processes are the most important perspective to describe Enterprise Architectures. Thesearchitectures specify the way, how the added value in enterprises and between enterprises is created.The process level is the space where Enterprise Architecture Management is placed to extend thereality on a model-based perspective for planning purposes. Established standards in the field of En-terprise Architecture Management are the different modelling languages itself which are used for dif-ferent perspectives.

Summarizing the mentioned points we want to create an initial framework for Flexible Business Mod-els. Firstly, they base upon the BMM which selects the necessary meta-information and processes.These are used for the resulting use case respectively the courses of action. Processes consist gen-erally on:

Functions, which describe which user a task with which application fulfilled

Deliverables, which show the service-fulfilment,

Organization, which shows the hierarchical structure of organizational units and their people,

Data, which represents the necessary information each enterprise needs for specific tasks orbusiness objects.

Processes belong to the group of information models, which are defined on meta-level by the informa-tion model types. The information model types consist of information model element types whose in-

Public


stances are the specific information model elements, which belong to the different information models.The special point in this framework is the description of the relations between the specific types andentities of information model elements and types. The documentation of the relations ensures later thepossibility of information model mapping on base of information model types and the other way roundatomic exchanges of process steps on information model element level.

6.4.5 SummaryThe discourse of flexibility is based on a technical understanding and has to be extended to achieve aconsistent understanding and terminology of it. Especially the implementation of business aspects andthe bridging of technical and economical concepts will lead to a sufficiently described Enterprise Inter-operability research – enabled by flexible business models. Therefore, we have presented in this pa-per an initial proposal for a Flexible Business Model definition, including a framework to extend andkeep ongoing the work with and around flexible business models.

There are challenges in different aspects: First, the bridging of BPMN and BMM according to ontolo-gies as the coherence ensuring instance. Second, there are no clear concepts that explain the diffu-sion of strategic decisions as a basis for BMM models as enabler of Enterprise Interoperability. Third,there is a lack of methodologies for creating and using BMM to explain the integration of business,process, and information system interoperability.

The challenges exist in harmonizing the existing standards on the technical levels. Future research willshow whether the standards BPMN 2.0 and BMM are appropriate to standardize the methods of col-lecting and specifying business requirements and to act as a basis for the technical implementationinto service oriented architectures and infrastructural components. This leads to the next research gapin business requirement modelling, concerning the syntax and notation used. Especially the mappingof language concepts, information model types and their coherent usage in communication is neededto enable a holistic interconnection of enterprises. We presented here only the process dimension,which belong to one of many different information model types. Therefore the complexity can only beresolved by a very concentrated view and by step by step integration of further information modeltypes.

Public


7 Conclusions and OutlookThis report has defined the initial version of the SHAPE Methodology, along with the first version of theSHAPE Methodology Tool and an extensive example for the methodological development of SOAsystems models by using SoaML.

The overall aim of the methodology is to enable users (i.e. business analysts, system architects, anddevelopers) to create customized methodologies that guide the complete system engineering processwith respect to the requirements and surroundings of the individual project. For this, we have decom-posed several existing methodologies related to SOA / SHA system engineering into smaller frag-ments, annotated them with meta-information that describe their usage conditions and dependencies,and – upon this basis – provided a generic tool that supports the creation, management, and mainte-nance of custom methodologies developed by users.

Therewith, in this deliverable we have defined the basis of the SHAPE Methodology, which will becontinuously enhanced and further developed in the course of the project. As the central elements, wehave:

Defined the SHAPE Reference Matrix as the overall integration view of the modelling tech-niques, software, and methodological support developed in the project

Defined the SHAPE Methodology Framework that defines the components and technical ar-chitecture for supporting the development

Defined the initial version of the SHAPE Methodology Description Model that defines themetamodels for describing the disciplines and methods

Specified the initial content of the SHAPE Methodology Libraries that contain the currentlyavailable disciplines and methods

Conducted a comprehensive analysis of 22 existing methodologies that resulted in theidentification of the SHAPE methods, and

Implemented the first prototype of the SHAPE Methodology Tool that supports the creation,management, and validation of custom methodologies developed by users.

In addition, we discussed an exhaustive example for methodology-guided development of SoaMLsystem models, i.e. with the central metamodel for model-driven development of SOA systems thathas been developed in the course of the SHAPE project.

The framework and specification in this document presents the initial version of the SHAPE Methodol-ogy. This will be continuously enhanced and further developed during the project, and be present thesubsequent deliverables of WP2. For this, we have already identified relevant aspects for refinementand enhancement that will be addressed in the next versions of the SHAPE Methodology. In particu-lar, these are:

Refinements and extensions of the methodology framework with respect to more extensivedescription models for the fragments as well as enhanced user support for the development,management, and validation of custom methodologies

Additional methodology support for the extensions towards SHA system engineering, whichincludes several technology platforms and service variability modelling

Integrated of advanced techniques for semantically enabled contract compliance checking aswell as support for the development of flexible business models.

Public


References

[Ambler, 2005] Scott W. Ambler: Introduction to the Enterprise Unified Process (EUP), October 2005;online: http://www.enterpriseunifiedprocess.com/essays/introduction.html.

[Arsanjani et al, 2008] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, and K. Holley;SOMA: A method for developing service-oriented solutions, IBM Journal “SOA: From Model-ling to Implementation”, Volume 47, Number 3, 2008.

[Berre and Elvesæter, 2008] Arne-Jørgen Berre, Brian Elvesæter: MDE for SOA (COMET-S withBMM, BPMN and UPMS) Notes for Course material “Model Based System Development”,INF5120 – Spring 2008.

[Berre et al., 2006] Berre, A.-J., Hoff, H., Skogan, D., Tsalgatidou, A., Athanasopoulos, G., and Pan-tazoglou, M. 2006. Service-Oriented Development In a Unified framework (SODIUM) - FutureResearch Challenges. In 1st International EASST-EU Workshop on Future Research Chal-lenges for Software and Services, Vienna, Austria, April 2006.

[Bonner and Kifer 1996] A. J. Bonner and M. Kifer, "Concurrency and Communication in TransactionLogic". In Proc. of the Joint International Conference and Symposium on Logic Programming,1996.

[Bruijn, et al. 2008] J. d. Bruijn, D. Fensel, M. Kerrigan, U. Keller, H. Lausen, and J. Scicluna, "Mod-elling Semantic Web Services – The Web Service Modelling Language", Springer, 2008.

[CBDI 2007] CBDI Journal February 2007, ISSN1745-1884.

[Constantine et al., 2003] Constantine, L. L: Canonical Abstract Prototypes for Abstract Visual andInteraction. In Jorge, J., Nunes, N. J., e Cunha, J. F. (ed.), Proceedings of DSV-IS 2003, 10thInternational Conference on Design, Specification and Verification of Interactive Systems. Lec-ture Notes in Computer Science, Vol. 2844. Springer-Verlag, Berlin, 2003, 1--15.

[Davis, 2001] Rob Davis: Business Process Modelling with ARIS: a practical guide, Springer: LondonBerlin Heidelberg, 2001.

[Davulcu, et al. 2004] H. Davulcu, M. Kifer, and I. Ramakrishnan, "CTR-S: A Logic for SpecifyingContracts in Semantic Web Services", in WWW 2004, 2004, pp. 144+.

[EPF] Eclipse Process Framework Project. http://www.eclipse.org/epf/ (accessed: 2008).

[Fensel, et al. 2007] D. Fensel, H. Lausen, A. Polleres, J. d. Bruijn, M. Stollberg, D. Roman, and J.Domingue, "Enabling Semantic Web Services – The Web Service Modelling Ontology",Springer, 2007.

[Fensel, et al. 2008] D. Fensel, M. Kerrigan, and M. Zaremba, "Implementing Semantic Web Ser-vices – The SESA Framework", Springer, 2008.

[Goetz, 2008] J. von Goetz: 360° View on Enterprise SOA, Parts 1 – 10. SAP Service DeveloperNetwork, 18 April 2008; online: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9340.

[Gomez-Perez 1995] A. Gomez-Perez, "Criteria to Verify Knowledge Sharing Technology", Knowl-edge Systems Laboratory, Stanford University, 1995.

[Harding, 2008] Chris Harding: SOA Ontology Draft 2.0. The Open Group. 14 July 2008; online:http://www.opengroup.org/projects/soaontology/doc.tpl?CALLER=index.tpl&gdid=16940.

[IFIP, 1999] Bernus Nemes & Kosanke Vernadat: GERAM: Generalised Enterprise Reference Archi-tecture and Methodology, March 1999 online:https://www.cit.gu.edu.au/~bernus/tskforce/geram/version/geraml-6-3/v1.6.3.html.

[Jones, 2005] S. JONES, A methodology for service architecture, on web, 26th October 2005,http://www.oasis-open.org.

[Kang et al., 1990] K. C. Kang, G. S. G. Cohen, A. A. Hess, W. E. Novak, A. S. Peterson: Feature-

http://www.enterpriseunifiedprocess.com/essays/introduction.html.

http://www.eclipse.org/epf/

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9340.

http://www.opengroup.org/projects/soaontology/doc.tpl?CALLER=index.tpl&gdid=16940.

https://www.cit.gu.edu.au/~bernus/tskforce/geram/version/geraml-6-3/v1.6.3.html.

http://www.oasis-open.org./

Public


Oriented Domain Analysis (FODA) Feasibility Study. Software Engineering Institute, TechnicalReport ESD-90-TR-222, 1990.

[Lankhorst et al., 2005] Marc Lankhorst (ed.) et al.: Enterprise Architecture at Work. Modelling,Communication, and Analysis. Springer, 2005.

[Lenat, et al. 1990] D. Lenat, R. Guha, K. Pittman, D. Pratt, and M. Shepherd, "CYC: Toward Pro-grams With Common Sense", ACM Communications, vol. 33, pp. 30-49, 1990.

[Lewis et al, 2008] Grace A. Lewis, Edwin J. Morris, Dennis B. Smith and Soumya Simanta;SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Archi-tecture Environment, Technical note, CMU/SEI-2008-TN-008, June 2008.

[Mellor et al., 2004] Stephen J. Mellor, Kendall Scott, Axel Uhl, and Dirk Weise: MDA Distilled. Princi-ples of Model-Driven Architecture. Addison-Wesley, Object Technology Series, 2004.

[Neon Project] http://www.neon-project.org/.[Nilsen, 2008] Geir Anders Nilsen, Analysis of service identification in SOA methodologies – with a

unification in POSI, Perspective Oriented Service Identification, 8, December, 2008.

[OASIS 2006] OASIS, "Reference Model for Service Oriented Architecture 1.0", OASIS, OASISStandard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

[OASIS 2007] OASIS, "Web Services Business Process Execution Language (WSBPEL) TC", Or-ganization for the Advancement of Structured Information Standards (OASIS).http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel (accessed: 2007).

[OASIS,2006] OASIS, Reference model for service oriented architecture 1.0, on web, 2 August 2006,http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

[OMG 2003] OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG), Documentomg/03-06-01, June 2003. http://www.omg.org/docs/omg/03-06-01.pdf

[Pinto, et al. 2004] S. Pinto, S. Staab, and C. Tempich, "DILIGENT: Towards a fine-grained method-ology for Distributed, Loosely-controlled and evolving Engineering of oNTologies", in Proc. ofthe 16th European Conference on Artificial Intelligence (ECAI 2004), Heraklion, Crete, Greece,2004.

[Roman and Kifer 2007] D. Roman and M. Kifer, "Reasoning about the Behavior of Semantic WebServices with Concurrent Transaction Logic", in VLDB, 2007, pp. 627-638.

[SAP PM, 2008] SAP Product Management and Development. Enterpise SOA DevelopmentHandbook 13 May 2008.

[SeCSE Composition, 2005] ESI, CA, CEFRIEL,. RUG, TILAB (ed.): Report on methodological ap-proach to design service composition, SeCSE Deliverable A3.D3.1., August 2005.

[SeCSE, 2007] ATOS, ESI, Lancaster, Engineering (ed.): SeCSE Methodology, version 3, SeCSEDeliverable A5.D4.2., March 2007.

[Senkul, et al. 2002] P. Senkul, M. Kifer, and I. Toroslu, "A Logical Framework for Scheduling Work-flows under Resource Allocation Constraints", in VLDB, 2002, pp. 694-705.

[SHAPE 2007] SHAPE, "Annex I – ‘Description of Work’", SHAPE STREP, 16 October 2007.

[SHAPE D1.1] C. Hahn (ed.): Case Study Scenario Descriptions and Requirements Specifications.SHAPE Deliverable D1.1, 19 December 2008.

[SHAPE D2.1] S. Johnsen (ed.): Model-driven Methodology and Architecture Specification. SHAPEDeliverable D2.1, 16 October 2008.

[SHAPE D3.1] G. Benguria (ed.): Consolidation of Common Basis for Metamodels and Languagesfor SHA. SHAPE Deliverable D3.1, 09 September 2008.

[SHAPE D3.2] G. Benguria (ed.): Metamodel and language for service modelling (UPMS), exten-sions for flexible business models and service variability – Initial version. SHAPE Deliverable

http://www.neon-project.org/.

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

http://www.omg.org/docs/omg/03-06-01.pdf

Public


D3.2, 31 December 2008.

[SHAPE D4.1] Andrey Sadovykh (ed.): MDE Toolset and Architecture Specification. SHAPE Deliver-able D4.1, 19 December 2008.

[SHAPE D4.2] Andrey Sadovykh (ed.): SHAPE MDE Toolset – Initial Version. SHAPE DeliverableD4.2, 09 January 2009.

[SoaML, 2008] A. J. Berre (ed.): Service oriented architecture Modeling Language (SoaML) -Specification for the UML Profile and Metamodel for Services (UPMS). Revised Submission,OMG, 01 November 2008.

[SPEM] Software Process Engineering Meta-Model, version 2.0. online:http://www.omg.org/technology/documents/formal/spem.htm (accessed: 2008).

[Sure, et al. 2004] Y. Sure, S. Staab, and R. Studer, "On-To-Knowledge Methodology (OTKM)", inHandbook on Ontologies, 2004, pp. 117-132.

[TEXO D6.2.1] Cardoso, J. (ed.): Description of Basic Methodology and Modeling Approach for Busi-ness Services. TEXO Deliverable D6.2.1.

[Trætteberg et al., 2006] Trætteberg, H. A Hybrid Tool for User Interface Modelling and Prototyping,In: Computer-Aided Design of User Interfaces V. Springer Science Business Media. B.V, 2006.

[Uschold and Gruninger 1996] M. Uschold and M. Gruninger, "Ontologies: Principles, Methods andApplications", The Knowledge Engineering Review, vol. 11, no. 2, 1996.

[Uschold and King 1995] M. Uschold and M. King, "Towards a methodology for building ontologies",In Workshop on Basic Ontological Issues in Knowledge Sharing, held in conjunction withIJCAI-95.

[W3C 2004] W3C, "Web Services Choreography Description Language Version 1.0", World WideWeb Consortium (W3C), W3C Working Draft, 17 December 2004a. online:http://www.w3.org/TR/ws-cdl-10/.

[Zachman, 1987] Zachman, J. A.: A framework for information systems architecture. In IBM SystemsJournal, Vol. 26, No. 3, 1987, S. 277-293.

[Zimmermann, et al. 2004] O. Zimmermann, P. Krogdahl, and C. Gee, "Elements of Service-Oriented Analysis and Design, An interdisciplinary modeling approach for SOA projects", IBM,2 June 2004. http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/.

http://www.omg.org/technology/documents/formal/spem.htm

http://www.w3.org/TR/ws-cdl-10/.

http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/.

Public


APPENDIXThe appendices contain the following accompanying information:

Appendix A: List of the candidate methodologies that have been analyzed in detail for definingthe initial version of the SHAPE Method Library

Appendix B: Detailed analysis results of the candidate methodologies (the actual results areprovided in an accompanying document).

Appendix C: Information on the availability and the installation instructions for the SHAPEMethodology Tool, initial version (available for download in the eRoom)

Appendix D: The initial version of the complete SHAPE Reference Matrix, including:

1. The metamodels developed in WP 3

2. The tools developed in WP 4 and WP5

3. The Method Chunks developed in WP 2.

Appendix E: Detailed overview of the SHAPE Method Library (initial version) as the identifiedmethod chunks and their allocation within the SHAPE Reference Matrix

Public


A Source MethodologiesThis appendix provides a concise overview of the existing methodologies that have been analyzed inorder to obtain the initial version of the SHAPE Method Library as defined in Section 3.3.

Table 30 shows the 22 methodologies that have been identified as candidates in the course of ourrequirements- and state-of-the-art analysis in [SHAPE D2.1]. We here enlist the title, the acronymused in the SHAPE project, the provider / owner of the methodology, and the SHAPE partner thatserves as an expert for the analysis.

Table 30: Overview of Analyzed Methodologies

No. Title Acronymin SHAPE

Provider Expert inSHAPE

Enterprise Architecture (EA) Methodologies

1Generalised EnterpriseReference Architecture andMethodology

GERAM

IFIP-IFACTask Force on

Architectures forEnterprise Integration

SINTEF

2 Architecture of IntegratedInformation Systems ARIS

Institute for EconomicInformation at the

University of SaarlandSINTEF

3 Enterprise Unified Process EUPScott W. Ambler leader ofagile development at IBM

CorporationSINTEF

Service-Oriented Architecture (SOA) Methodologies

4 Inter-enterprise Service Engi-neering ISE SAP / TEXO Project SAP

5 Service-Oriented Modelling andArchitecture SOMA IBM Corporation ESI

6Component and Model-baseddevelopment Methodology forServices

COMET-S SINTEF SINTEF

7 SAE Reference Model for SOA SAE CBDI Forum ESI

8 Service Migration and ReuseMethodology SMART European Software

Institute (ESI)ESI

9 Service Oriented AnalysisDesign Methodology SOAD IBM Corporation ESI

10 SeCSE Methodology SM SeCSE Consortium (EUProject)

ESI

11 SeCSE Composition Methodol-ogy SCM SeCSE Consortium (EU

Project)ESI

12 Enterprise SOA ESOA SAP SAP

13 ESI Methodology ESIM European SoftwareInstitute (ESI)

ESI

14 OASIS Methodology OASIS OASIS / Capgemini UK SINTEF

15 Open Group SOA Ontology OGSOA Open Group SINTEF

Public


Ontology Engineering (OE) Methodologies

16 Cyc Methodology CYC Cyc Project UIBK

17 Enterprise Ontology EONTO Individuals UIBK

18 TOVE Methodology TOVE Individuals UIBK

19 METHONTOLOGY METHONTO Individuals UIBK

20 NeOn Methodology NEON NeOn Project Consortium UIBK

21 On-To-Knowledge Methodology OTK Individuals UIBK

22 DILIGENT Methodology DILIGENT Individuals UIBK

Public


B Methodology AnalysisThis appendix documents the work that has been conducted for the detailed analysis of the candidatemethodologies as enlisted in Appendix A. These have been identified to be relevant for the SHAPEMethodology in [SHAPE D2.1], and constitute the initial version of the Method Library that is defined inSection 3.3.

The actual analysis results are provided in a separate document. This contains the detailed analysis ofthe candidate methodologies selected for closer inspection (cf. Appendix A), and is provided as anaccompanying document to this deliverable.

The following presents the template that has been used for the analysis of the methodologies.

1 Overview

1.1 Analyzed Methodology1) Name

2) SHAPE Acronym

3) Provider / Owner

4) Description (1 sentence / paragraph)

1.2 Relevance for SHAPE5) To which SHAPE level does the methodology suit best (CIM / PIM / PSM)?

6) Which areas of the SHAPE Matrix are covered (Information – Service – Process – Rules – Events– Organization – Motivation – NFA)?

2 Analysis

2.1 Overall MethodologyProvide a brief overview of the methodlogy

overview picture

overall system engineering process

2.2 DecompositionDecompose the methodology into method chunks

ID-structure: <SHAPE-Acronym> –- <Chunk-No.> –- [optional: - <Sub-Chunk-No.>

Tabular description of each method chunk

Method Chunk Description

ID-1 what the method chunk is for

ID-2 what the method chunk is for

Public


2.3 Allocation to SHAPE MatrixAllocate the method chunks identified above to boxes of the SHAPE Reference Matrix

ASPECT

LEVELInformation Service Process Rules Events Organization Goals NFA

CIM

CIM2PIM

PIM

PIM2PSM

PSM

3 Method DescriptionsProvide a detailed description of each method identified above

Description Aspects:1) Discipline: what engineering disciplines is the method suitable for?

2) Procedure: textual description of the engineering process defined by the method

3) Visualization: graphical visualization of the procedure

4) Notation: which notation / specification language is support by the method?

3.1 ID-1Provide description of the method chunk according to above scheme

…

Public


C SHAPE Methodology Tool – Availability and InstallationThis section provides the user manual for the SHAPE Methodology Tool as presented in Section 4.

C.1 ScopeThis user manual includes installation and configuration instructions for the SHAPE Methodology Tool.Instructions are accompanied by the screen shots.

C.2 InstallationThis chapter provide an installation instruction for SHAPE Methodology Tool.

The installation includes two steps. First you need to obtain EPF composer fro Eclipse ProcessFramework Project. Then, you need to download SHAPE practice (SHAPE plug-in) from the SHAPEwebsite and import the plug-in to EPF Composer.

C.2.1 Install Eclipse EPFThis section describes how to install EPF Composer. Please follow the following steps:

1. Download and install the Java Runtime Environment 1.5 or above. Download the JREfrom http://java.sun.com/javase/downloads/index.jsp and follow the installationinstruction available on the Java download site.

2. Download and install EPF composers. Download the EPF composer archive fromhttp://www.eclipse.org/epf/downloads/tool/tool_downloads.php. Extract thedownloaded archive to the folder of your choice. We will refer to this folder asEPF_FOLDER in the following sections.

C.2.2 Install SHAPE Methodology prototypeThe SHAPE Methodology prototype is implemented as plugin for EPF composer.

It is available for download at SHAPE website:

https://project.sintef.no/eRoomReq/Files/ikt/SHAPE/0_18740/SHAPE-MethTool-prototype-V1.zip.

Extract SHAPE-MethTool-prototype-V1.zip archive to the folder of your choice. We will refer to thisfolder as SHAPE_FOLDER in the following section.

C.3 ConfigurationThis section describes how to configure the SHAPE methodology Prototype:

1. Start EPF composer by running EPF_FOLDER/epf-composer/epf.exe file

2. Go to File->Import, and choose Method Plug-Ins source as shown on in Figure 50.

3. Then, click the Next button.

http://java.sun.com/javase/downloads/index.jsp

http://www.eclipse.org/epf/downloads/tool/tool_downloads.php.

https://project.sintef.no/eRoomReq/Files/ikt/SHAPE/0_18740/SHAPE-MethTool-prototype-V1.zip.

Public


Figure 50: Import Dialog

4. Specify the SHAPE_FOLDER\EPF folder in the “Specify Import Directory” dialog thatappears. Click the Next button.

5. Select the Shape Method Components plug-in in the next window as shown in Figure51.

6. Then click Finish.

Public


Figure 51: Select SHAPE plug-in

7. You can backup the previous configuration as proposed in the following step, or ig-nore it and continue.

8. The import wizard is finished. Make sure you are located in the Authoring perspectiveand check if you see the “SHAPE Method Components” plug-in in the Library view asshown in Figure 52.

9. Now the SHAPE Methodology tool prototype is ready to use.

Public


Figure 52: SHAPE plug-in appears in EPF library

Public


D SHAPE Reference Matrix – Initial VersionThis appendix contains the current version of the SHAPE Reference Matrix.

The structure and purpose of the SHAPE Reference Matrix as the central integration view of the tech-nology developments in the project has been explained in detail in Section 2.2. The following containsthe completed content specification of the boxes, representing the aggregated results of the technol-ogy developments in the SHAPE project. In particular, it contains:

(1) The metamodels developed in WP3 [SHAPE D3.1], [SHAPE D3.2]

(2) The tools developed in WP4 [SHAPE D4.1], [SHAPE D4.2] and WP5

(3) The Method Chunks developed in WP2 (this document).

Figure 53 below shows the initial version of the SHAPE Reference Matrix. The boxes are defined asfollows (cf. Figure 3 in Section 2.2):

Aspect

Metamodel (from WP3)

suitable metamodel for describing the aspect on the MOF-2 level

SHAPE Tool (from WP4 / WP5)

- tool for creating MOF-1 models from metamodel (MOF-2)

- model transformation (for CIM2PIM / PIM2PSM)

Level

Methodology (from WP2)

method fragment (= guided procedure) for building the MOF-1 models

On the PSM level, we merely list the technologies / languages that are used to describe the respectivemodelling aspects; the creation of the PSM models is done by the automated transformation from thePIM-level models. These are indicated by grey boxes.

Further Remarks:

On the transformation levels CIM2PIM and PIM2PSM, we merely define a tool and supportingmethodology fragments: a metamodel is not needed here, because the transformations areperformed in a (semi-)automated manner

Here, the methodology slots only contain the source methodologies where the method chunkshave been extracted from; a detailed overview of the methods for each box is provided belowin Appendix E.


Aspect /Level Information Service Process Rules Events Organization Goals NFA

MM Ontologies - ODM (BPMN2)(SoaML) BPMN EPC SBVR EPC

BPMN (EMP) OSM BMMOMG MM for per-

formance / security/ quality

Tool Objecteering,WSMT Objecteering CIMFlex CIMFlex CIMFlex CIMFlex, Objec-

teeringCIMFlex, Objec-

teeringObjecteering,

WSMTCIM

Meth

OE Methodologies,GERAM,ARIS,

EUP, COMET-S,ESIM, SCM, SM,

ISE, ESOA

GERAM,ARIS, EUPCOMET-S, OG-SOA, ESIM, SM,SCM, SMART,

SOMA, ISE, ESOA

GERAM,ARIS, EUP,COMET-S, OGSOA,

ESIM, SAE,SCM,SM, SMART, SOAD,SOMA, ISE, ESOA

GERAM, EUP,ESIM, SM, SOMA,ISE, ESOA, Cyc

GERAM, EUP

GERAM,ARIS,EUP, ESIM, SAE,SM, SMART, SO-MA, ISE, ESOA

GERAM,ARIS,EUP, COMET-S,

ESIM, SM, SMART,SOMA, ISE, ESOA

GERAM, ESIM,SCM, SM, SOMA,

ISE, ESOA

ToolCIM2PIMMeth COMET-S COMET-S COMET-S

MM UML Class diagramODM, IMM SoaML UML Behaviour

(BPMN) (BPR) EMPSoaML Participant,

UML Deploym.Element

(Agent Goals),(WSMO Goals)

OMG MM for per-formance, security,

quality

Tool WSMT Objecteering,PIM4Agents,WSMT Objecteering WSMT CIMFlex Objecteering PIM4Agents,

WSMTObjecteering,

WSMTPIM

Meth

COMET-S, OASIS,ESIM, SCM, SM,SMART, SOMA,

ISE, ESOA

COMET-S, OASIS,OGSOA, ESIM,

SAE, SCM, SOAD,SMART, SOMA,

ISE, ESOA

OASIS, OGSOA,ESIM, SAE, SCM,SMART, SOAD,

SOMA, ISE, ESOA

SMART, ISE,ESOA OASIS SMART, ESOA SMART

OASIS, ESIM,SCM, SMART,

SOMA, ISE, ESOA

Tool [automated modeltransformation]

[automated modeltransformation]






[automated modeltransformation]PIM2PSM

Meth COMET-S ESOA, COMET-S ESOA ESIM, ESOA ESIM ESIM ESIMWS XML WSDL BPEL RTF - - - WS*-standards

Agent Jack: DataJade: Classes - Jack: Plans

Jade: BehaviorsJack: Plans

Jade: -Jack: Events

Jade: MessagesJack: Team

Jade: Agent/Organ.Jack: Goals

Jade: - -

SWS OWLWSML

OWL-SWSMO

OWL-SWSMO

SWRLWSML - - WSMO Goals WSMO NFP

P2P - JXTA JXTA - (JXTA) - - -

PSM

Grid Grid ResourceOntologies

OGSA (Open GridService Architect.) OGSA - -

OGSA(Virtual Organiz.Management)

JSDL(Job Submission

Description Lang.)

Grid Security Infra-structure (GSI)

Figure 53: SHAPE Reference Matrix (Initial Version)

Public


E Method Library – Allocation in SHAPE Reference MatrixThis appendix provides a detailed overview of the methods available in the initial version of theSHAPE Method Library as defined in Section 3.3. We here list the method chunks with respect to theirallocation in the SHAPE Reference Matrix as defined in Appendix D.

E.1 CIM Level MethodsTable 31: CIM Level Methods for INFORMATION Aspect

ID Name Disciplines NotationARIS-2 Data View CIMmodel VAC / EPCCOMET-S-1

BM-Bussness resourceModelling

CIMmodel BPEL

Cyc-1 Manual extraction ofcommonsenseknowledge fromknowledge sources

CIMmodel CYC-L


CIMmodel CYC-L


CIMmodel CYC-L

DILIGENT-1

A central board buildsan initial core ontology

CIMmodel Ontology lan-guage (any)

DILIGENT-2

End users take the coreontology and performlocal adaptation on it

CIMmodel Natural lan-guage in tabu-lar form

DILIGENT-3

The central board ana-lyzes the changes madeby the end users

CIMmodel Tabular

DILIGENT-4

The central boardmakes a revision to thecore ontology


DILIGENT-5

The new revision of thecore ontology is adoptedby the end users


EOnto-1 Identify the purpose ofthe ontology

CIMmodel Natural lan-guage

EOnto-2 Building the ontology CIMmodel Ontology lang.(any)

EOnto-3 Evaluate the ontology CIMmodel Non-technicalEOnto-4 Document ontology CIMmodel Natural Lan-

guageESIM-1 Requirements

IdentificationReqAna UML


ReqAna UML

ESOA-1 Business Requirements CIMmodel Natural Lan-guage


CIMmodel UML

EUP-5 The Retirement Phase CIMmodel UML

Public


GERAM -4 Generic EnterpriseModelling Concepts

CIMmodel EnterpriseModellingLanguage

GERAM -5 Partial Enterprise Mod-els


GERAM -8 (Particular) EnterpriseModels


ISE-3 Data Modelling CIMmodel Mind MapMethOnto-1

Management CIMmodel Natural lan-guage / non-technical

MethOnto-2

Development-oriented CIMmodel Tables

MethOnto-3

Support CIMmodel Non-technical

NeOn-1 Management CIMmodel Natural lan-guage / non-technical

NeOn-2 Development-oriented CIMmodel TablesNeOn-3 Support CIMmodel Non-technicalOTK-1 Knowledge Meta

ProcessCIMmodel Ontology

Lang. (any)OTK-2 Knowledge Process CIMmodel Ontology

Lang. (any)SCM -2 Functional

Specification/ServiceSpecificationArchitecture

CIMmodel Natural Lan-guage,

SCM-1 Enterprise ArchitectureEngineering

Gov NaturalLanguage,

SM -2 Requirements Definition ReqAna NaturalSM-1 Business Modelling CIMmodel NaturalTOVE-1 Identify a set of

motivating scenariosCIMmodel Natural Lan-

guageTOVE-2 Formulate informal

competency questionsCIMmodel Natural Lan-

guageTOVE-3 Formally specify the

terminology of the ontol-ogy within a formal lan-guage

CIMmodel FOL / anyontology lan-guage

TOVE-4 Formally define thecompetency questions


TOVE-5 Specify axioms in theontology


TOVE-6 Check completeness CIMmodel Non-technical

Public


Table 32 CIM Level Methods for SERVICE Aspect

ID Name Disciplines NotationARIS -5 Product\Service View CIMmodel Service Dia-

gramCOMET-S-2

Busness Process andRole Modelling

CIMmodel BPMN

ESIM-1 RequirementsIdentification

ReqAna UML


CIMmodel UML

ESOA-1 Business Requirements ReqAna Natural Lan-guage


LifeCyc UML

EUP-4 The Production Phase LifeCyc UMLEUP-5 The Retirement Phase LegAna UMLGERAM -2

Enterprise EngineeringMethodology


GERAM -3

Enterprise ModellingLanguages


GERAM -4

Generic EnterpriseModelling Concepts


GERAM -5

Partial Enterprise Mod-els


GERAM -7

Enterprise Modules CIMmodel EnterpriseModellingLanguage

GERAM -8

(Particular) EnterpriseModels


GERAM -9

(Particular) EnterpriseOperational Systems


GERAM-1 Generic Enterprise Ref-erence Architecture


ISE-1 Service Modeling CIMmodel Mind MapOGSOA-1 Basic Concept CIMmodel OWLOGSOA-2 Business Activity CIMmodel OWLSCM -2 Functional

Specification/ServiceSpecificationArchitecture

Legacy System XML


LifeCyc XML

SM-2 Requirements Definition ReqAna Language,XML

SM-1 Business Modelling CIMmodel LanguageSMART-1 Establish Migration CIMmodel Natural

Public


Context LanguageSOMA-1 Business Modelling and

TransformationCIMmodel Natural

SOMA-3 Identification PIMmodel UML

Table 33: CIM Level Methods for PROCESS Aspect

ID Name Disciplines NotationARIS -4 Control View CIMmodel KPI diagramCOMET-S-2

Busness Process andRole Modelling

CIMmodel BPEL

ESIM-1 Requirements Identifica-tion

ReqAna UML

ESIM-2 Business Model Analy-sis

ReqAna, CIMmodel UML

ESOA-1 Business Requirements LegAna Natural Lan-guage

ESOA-6 Service Consumption PSMmodel UML, WSDLEUP-3 The Enterprise Disci-

plinesGov UML

GERAM -2 Enterprise EngineeringMethodology

CIMmodel, Maint,LifeCyc

NaturalLanguage


CIMmodel NaturalLanguage







ISE-2 Workflow Modelling CIMmodel Mind MapOGSOA-2 Business Activity PIMmodelSAE-1 SOA Adoption and

ExcellenceGov Natural

Language,SAE-2 SOA Governance Gov Natural

Language,XML

SCM -2 Functional Specifica-tion/Service Specifica-tion Architecture

Analysis Natural Lan-guage, XML


Gov, LifeCyc Natural Lan-guage

SM -2 Requirements Definition CIMmodel, LegAna Natural Lan-guage, XML

SM-1 Business Modeling Gov, LifeCyc Natural Lan-guage, XML

SMART-1 Establish MigrationContext

LifeCyc Natural Lan-guage

SOAD-1 Services identification CIMmodel XML, Businessprocess mod-elling notation(BPMI)

SOMA-1 Business Modelling andTransformation

LegAna Language,XML

SOMA-3 Identification CIMmodel, LegAna UML

Public


Table 34: CIM Level Methods for RULES Aspect

ID Name Disciplines NotationCyc-1 Manual extraction of

commonsenseknowledge fromknowledge sources

CIMmodel Cyc-L


CIMmodel Cyc-L


CIMmodel Cyc-L


ReqAna UML

ESOA-7 Governance Gov UMLEUP-1 The Development Disci-

plineCIMmodel, Impl,ReqAna

UML


CIMmodel, Impl,ReqAna

UML







ISE-5 Rules PIMmodel OCLSM -2 Requirements Definition ReqAna Natural Lan-

guage, XMLSM-1 Business Modelling CIMmodel Natural Lan-

guageSOMA-2 Solution Management CIMmodel Natural Lan-

guage

Table 35: CIM Level Methods for EVENTS Aspect

ID Name Disciplines NotationARIS -3 Function View CIMmodel BPMLEUP-2 The Operations and

Support DisciplineCIMmodel UML

EUP-4 The Production Phase LifeCyc, Maint, De-ploy

UML

EUP-5 The Retirement Phase CIMmodel, LegAna UMLGERAM -4 Generic Enterprise

Modelling ConceptsCIMmodel Enterprise

ModellingLanguage

Public


Table 36: CIM Level Methods for ORGANIZATION Aspect

ID Name Disciplines NotationARIS-1 Organisation View CIMmodel Business

Process Mod-elling Lan-guage


ReqAna UML

ESIM-2 Business Model Analy-sis

ReqAna, CIMmodel UML

ESOA-7 Governance Gov UMLEUP-3 The Enterprise Disci-

plinesCIMmodel, Impl,ReqAna

UML









ISE-4 People and Roles CIMmodel Mind MapSAE-1 SOA Adoption and

ExcellenceGov UML

SAE-2 SOA Governance Gov UMLSM -2 Requirements Definition ReqAna Natural Lan-


guageSMART-1 Establish Migration Con-

textMaint Natural Lan-

guageSOMA-2 Solution Management Language,

XML

Table 37: CIM Level Methods for GOALS Aspect

ID Name Disciplines NotationARIS -3 Function View CIMmodel BPMLARIS-1 Organisation View CIMmodel Organization

ChartCOMET-S-3

Busness Process GoalModeling

CIMmodel BMM


ReqAna UML

ESOA-1 Business Requirements CIMmodel, ReqAna,LegAna

Natrual Lan-guage

EUP-2 The Operations andSupport Discipline

Maint UML


CIMmodel, LifeCyc,Gov

UML

EUP-4 The Production Phase Deploy UML

Public








ISE-5 Rules CIMmodel Mind MapSM -2 Requirements Definition ReqAna Natrual Lan-


guageSMART-1 Establish Migration Con-

textLegAna Natural Lan-

guageSOMA-1 Business Modelling and

TransformationReqAna Natural Lan-

guage, XMLSOMA-3 Identification CIMmodel, LegAna UML

Table 38: Methods for NFA Aspect

ID Name Disciplines NotationESIM-1 Requirements Identifica-

tionReqAna UML

ESOA-7 Governance Gov UMLESOA-8 Lifecycle Management LifeCyc UMLGERAM -4 Generic Enterprise

Modelling ConceptsCIMmodel Enterprise

ModellingLanguage



ISE-1 Service Modeling CIMmodel, PIM-model, PSMmodel

MindMap,UML, WSDL

SCM -2 Functional Specifica-tion/Service Specifica-tion Architecture

CIMmodel, LegAna Natural Lan-guages, XML


Gov, LifeCyc Natural Lan-guages, XML

SM -2 Requirements Definition ReqAna Natural Lan-guage, XML

SM-1 Business Modelling CIMmodel Natural Lan-guage

SOMA-3 Identification CIMmodel, LegAna UML

E.2 CIM2PIM LevelTable 39: CIM2PIM Level Methods for INFORMATION Aspect

ID Name Disciplines NotationCOMET-S-4

RM: BCE modelling UML

Public


Table 40 CIM2PIM Level Methods for SERVICE Aspect


RM: Use Case Modeling UML

Table 41: Methods for PROCESS Aspect


BM: Work ElementAnalysis

BPMN, BMM

E.3 PIM LevelTable 42: PIM Level Methods for INFORMATION Aspect


Architecture Modeling PIMmodel SoaML


LegAna UML

ESOA-5 and Description PSMmodel UMLISE-3 Data Modelling PIMmodel UMLOASIS-1 Information Model PIMmodel UMLSCM -3 Design-Time Service

Composition & VariationPoint Management

PIMmodel NaturalLanguage,

SM -5 Service Specification PIMmodel XML, WSDLSMART-2 Define Candidate

ServicesPIMmodel Natural

LanguageSMART-3 Define Existing

CapabilityPIMmodel Natural

LanguageSOMA-4 Specification PIMmodel UML, WSDL

Table 43 PIM Level Methods for SERVICE Aspect


Architecture Modeling PIMmodel SoaML


LegAna UML


PIMmodel UML

ESOA-2 Service Modelling PIMmodel BPELISE-1 Service Modeling PIMmodel UMLOASIS-2 Reference Model PIMmodel UMLOGSOA-2 Business Activity CIMmodel, PIMmode OWLOGSOA-3 SOA Service PIMmodel OWLOGSOA-4 SOA Architecture PIMmodel OWLSAE-7 Legacy Transition

PlanningLegAna Natural

Language,SCM -3 Design-Time Service


PIMmodel XML

SMART-2 Define CandidateServices

Test Natural Lan-guage

Public


SMART-3 Define ExistingCapability

LegAna Natural Lan-guage


PIMmodel NaturalLanguage

SMART-5 Analyze the Gap PIMmodel NaturalLanguage


PIMmodel NaturalLanguage

SOAD -3 Subsytem analysis PIMmodel UMLSOMA-4 Specification PIMmodel UML

Table 44: PIM Level Methods for PROCESS Aspect

ID Name Disciplines NotationESIM-3 Software System Analy-

sisLegAna UML


PIMmodel UML

ESOA-6 Service Consumption PIMmodel UML, WSDLISE-2 Workflow Modelling PIMmodel UMLISE-4 People and Roles PIMmodel UMLOASIS-3 Behavioral Model PIMmodel UMLOASIS-4 Process Model PIMmodel UMLSAE-3 SOA Business

Requirements PlanningReqAna Natural

Language,SAE-4 SOA Business

ImprovementCIMmodel Natural

Language,SCM -3 Design-Time Service


PIMmodel NaturalLanguage,XML

SMART-2 Define Candidate Ser-vices

PIMmodel NaturalLanguage,

SMART-3 Define Existing Capabil-ity

PIMmodel, LeqAna NaturalLanguage,


Gov, PIMmodel,LifeCyc, ReqAna

NaturalLanguage,

SMART-5 Analyze the Gap LegAna NaturalLanguage,


LifeCyc NaturalLanguage,

SOAD -2 Service clasification PIMmodel UMLSOAD -3 Subsytem analysis LegAna UMLSOAD-1 Services identification PIMmodel UMLSOMA-4 Specification PIMmodel UMLOGSOA-2 Business Activity PIMmodel OWL

Table 45: PIM Level Methods for RULES Aspect

ID Name Disciplines NotationESOA-7 Governance Gov Natural Lan-

guagesISE-5 Rules CIMmodel, PIM-

model, PSMmodelOCL, DecisionTables


LifeCyc Natural Lan-guages

Public


SMART-5 Analyze the Gap PIMmodel. LegAna Natural Lan-guages

SMART-6 Develop Migration Strat-egy

Gov Natural Lan-guages

Table 46: PIM Level Methods for EVENTS Aspect

ID Name Disciplines NotationOASIS-5 Action Model PIMmodel UML

Table 47: PIM Level Methods for ORGANIZATION Aspect


guagesSMART-2 Define Candidate Ser-

vicesPIMmodel, Test Natural Lan-

guagesSMART-3 Define Existing Capabil-

ityPIMmodel, LegAna Natural Lan-

guagesSMART-4 Describe Target SOA

EnvironmentReqAna Natural Lan-

guagesSMART-5 Analyze the Gap PIMmoel, LegAna Natural Lan-

guagesSMART-6 Develop Migration Strat-

egyPIMmodel, LifeCyc,Gov

Natural Lan-guages

Table 48: PIM Level Methods for GOALS Aspect

ID Name Disciplines NotationSMART-5 Analyze the Gap PIMmodel, LegAna Natural Lan-

guages

Table 49: PIM Level Methods for NFA Aspect

ID Name Disciplines NotationESIM-3 Software System Analy-

sisLegAna UML

ESOA-7 Governance Gov Natural Lan-guages

ESOA-8 Lifecycle Management LifeCyc Natural Lan-guages

ISE-1 Service Modeling CIMmodel, PIM-model, PSMmodel

UML

OASIS-6 Needs and CapabilityModel

PIMmodel UML

SCM -3 Design-Time ServiceComposition & VariationPoint Management

PIMmodel Natural Lan-guages, XML


PSMmodel XML, WS-BPEL


ReqAna Natural Lan-guages

SMART-6 Develop Migration Strat-egy

PIMmodel, LifeCyc,Gov

Natural Lan-guages

SOMA-4 Specification PIMmodel UML, WSDL

Public


E.4 PIM2PSM LevelTable 50: PIM2PSM Level Methods for INFORMATION Aspect


MOFScript mapping MOF

Table 51 PIM2PSM Level Methods for SERVICE Aspect


MOFScript mapping MOF

ESOA-4 Service Implementation PSMmodel XML, WSDL

Table 52: PIM2PSM Level Methods for RULES Aspect

ID Name Disciplines NotationESOA-4 Service Implementation Impl, PSMmodel XML, WSDL

Table 53: PIM2PSM Level Methods for EVENTS Aspect

ID Name Disciplines NotationESIM-7 Integration and Testing Deploy UMLESOA-4 Service Implementation Impl WSDL

Table 54: PIM2PSM Level Methods for ORGANIZATION Aspect

ID Name Disciplines NotationESIM-8 Validation Test UML

Table 55: PIM2PSM Level Methods for GOALS Aspect

ID Name Disciplines NotationESIM-7 Integration and Testing Test UML

Table 56: PIM2PSM Level Methods for NFA Aspect

ID Name Disciplines NotationESIM-7 Integration and Testing Deploy, Test UML

E.5 PSM LevelTable 57: PSM Level Methods for INFORMATION Aspect


Component implementa-tion modeling

PSMmodel UML

ESIM-5 Detailed Design PSMmodel UMLESIM-6 Implementation Impl UMLESOA-5 Discovery Impl XML, WSDLISE-3 Data Modelling PSMmodel OWLSCM -4 Composition & Variation

Point RealizationPSMmodel XML,

Public


SM -5 Service Specification PSMmodel XML. WSDLSOAD -4 Component Specifica-

tionPSMmodel UML

SOMA-6 Implementation PSMmodel UML

Table 58 PSM Level Methods for SERVICE Aspect


PSM: Component im-plementation modeling

PSMmodel UML

ESIM-5 Detailed Design PSMmodel UMLESIM-6 Implementation Impl UMLESIM-9 System Deployment Deploy UMLESOA-3 Service Definition PSMmodel UMLISE-1 Service Modeling PSMmodel WSDLSAE-11 Service Operations and

ManagementLifeCyc Natural Lan-

guage,SAE-5 Solution Assembly PIMmodel Natural Lan-

guage,SAE-7 Legacy Transition Plan-

ningLegAna UML

SAE-8 Service Provisioning Impl Natural Lan-guage,


PSMmodel WS-BPEL,ECA Rules

SCM -5 Validation Gov XMLSM -3 Service Discovery PSMmodel UDDI, WS-

DiscoverySM -4 Binding PSMmodel XML, WS-

BPELSM -5 Service Specification PSMmodel, PIM-

modelNatural Lan-guage

SOAD -4 Component Specifica-tion

LifeCyc UML

SOAD -5 Service Allocation PSMmodel UML, XML,BPEL

SOAD -6 Service realization Impl XML, BPELSOMA-5 Realization PSMmodel UML,SOMA-6 Implementation Impl UMLSOMA-7 Deployment, Monitoring

and ManagementMaint UML

Table 59: PSM Level Methods for PROCESS Aspect

ID Name Disciplines NotationESIM-5 Detailed Design PSMmodel UMLESIM-6 Implementation Impl UMLESIM-9 System Deployment Deploy UMLESOA-6 Service Consumption Impl WSDLISE-2 Workflow Modelling PSMmodel BPELISE-4 People and Roles PSMmodel DiamindlSAE-6 Service Oriented Archi-

tecture and DsignPSMmodel Natural Lan-

guage,SCM -4 Composition & Variation

Point RealizationPSMmodel WS-BPEL

Public


SCM -5 Validation PSMmodel XMLSM -3 Service Discovery PSMmodel UDDI, WS-

DiscoverySM -4 Binding PSMmodel WS-BPELSM -5 Service Specification PSMmodel, PIM-

modelXML, WSDL

SOAD -4 Component Specifica-tion

PSMmodel, LifeCyc UML

SOMA-5 Realization LifeCyc UML

Table 60: PSM Level Methods for RULES Aspect

ID Name Disciplines NotationESIM-9 System Deployment Deploy UMLESOA-5 and Description Main XML, WSDLESOA-7 Governance Gov non-technicalESOA-8 Lifecycle Management LifeCyc non-technicalISE-5 Rules PSMmodel, PIM-

model, CIMmodelOCL, DecisionTables, Drools

SM-7 Service Monitoring LifeCyc SecMOLSM-8 Service Negotiation Gov XML,SOAD -4 Component Specifica-

tionPSMmodel, LifeCyc UML

SOMA-7 Deployment, Monitoringand Management

Deploy UML

Table 61: PSM Level Methods for EVENTS Aspect

ID Name Disciplines NotationSOAD -4 Component Specifica-


Table 62: PSM Level Methods for ORGANIZATION Aspect

ID Name Disciplines NotationESOA-8 Lifecycle Management LifeCyc Natural Lan-

guage,SAE-10 Service Platform Design

& InstallationMaint Natural Lan-

guage,SM-8 Service Negotiation Gov WS-

AgreementSOAD -4 Component Specifica-


Table 63: PSM Level Methods for GOALS Aspect

ID Name Disciplines NotationSOAD -4 Component Specifica-


Table 64: PSM Level Methods for NFA Aspect


guage

Public


ESOA-8 Lifecycle Management LifeCyc Natural Lan-guage

SM-7 Service Monitoring LifeCyc, Maint SecMOLSM-8 Service Negotiation Gov XML, WS-

AgreementSOMA-7 Deployment, Monitoring

and ManagementLifeCyc UML

SHAPE - STI Innsbruck · This report presentsDeliverable D2.2 “Integrated and tool-supported...

Documents

Transcript of SHAPE - STI Innsbruck · This report presentsDeliverable D2.2 “Integrated and tool-supported...