ICT INF5120 – Modellbasert Systemutvikling F13: Model Driven Interoperability and MDA Industrial...

ICT

INF5120 – Modellbasert Systemutvikling

F13: Model Driven Interoperability and MDA Industrial Evolution (Genova example)

Lecture 03.05.2010

Arne-Jørgen Berre

ICT 2

INF5120 - Lecture plan - 2010 1: 25/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA, 4 parts: MDE/SSS/MS/MDI

(AJB)

Part I: MDE – Model Driven Engineering 2: 1/2: MDE I: Metamodeling. DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (AJB/BRE)

Part II: SSS – Service Science and Service/SOA technologies 3: 8/2: SSS I: Service science (top down) - Service and SOA Technologies (bottom up) (AJB)

Part I continued: MDE – Model Driven Engineering 4: 15/2: MDE II: Model transformations with MOFScript, ATL and other technologies (GO/JO) 5 :22/2: MDE III: Code generation with MOFScript, ATL and other technologies (GO/JO)

Part III: MOS – Modeling of Services - with SoaML 6: 1/3: MOS I: Business Process Modeling (CIM) - with BPMN 2.0, and BMM, EA with UPDM (AJB) 7: 8/3: MOS II: Soaml, UML2 and SysML, Modelio SOA and Scope, –Collaboration and Component models (AJB) 8: 15/3: MOS III: SoaML (PIM) and Requirements modeling , CIM->PIM and SoaML (AJB) 9: 22/3: MOS IV: Method Engineering and SPEM / EPF - for Service systems (BRE)

EASTER Part IV – Model Driven Interoperability 10: 12/4: MS V: SOA and Service Design, MDA and ADM - Intro to MDI (AJB ) 11: 19/4: MDI I: Semantic Web with Ontologies and Model Driven Interoperability (TIR) 12: 26/4: MDI II: Semantic Services and Model Driven Interoperability (TIR) 13: 3/5: MDE IV: Model Driven Interoperability and Industrial Evolution of MDA/MDE (AJB), Knut Sagli/ESITO)

14: 10/5: Course summary and preparation for Exam 31/5 (AJB)

Exam: May 31st, 2010 (Monday), 0900-1200 (3 hours)

ICT

Agenda

Model Driven Interoperability MODELS 2010, Oslo, 3-8. October 2010 Ref. 2 papers on MDI

Industrial evolution of MDA/MDE Modeling tools: MagicDraw, Enterprise

Architect, Modeio, IBM Software Architect, Microsoft Domain Specific Languages, Oracle, ...

Guest lecture, ESITO – Genova, Knut Sagli

ICT

MODELS 2010, Oslo, 3-8. October 2010

See: http://models2010.ifi.uio.no Student volunteers ?

ICT

Model Driven Interoperability

ICT 6

Current MDA Interoperability Architecture

CIM/EMmodels

PIMSystemmodels

PSMSystemmodels

System

Ref.ontologySemantic

annotation

Semanticannotation

Semanticannotation

CIM/EMmodels

PIMSystemmodels

PSMSystemmodels

System

Semanticannotation

Semanticannotation

Semanticannotation

Sem.mapping

Technicalmapping

Interoperabilityexecution

IF IF

ICT

Run-time

SemAnnot

Set#2

InternetSemRec

Rules#2

Local

Software &

Data

SwApp#1

Local

Software &

Data

SwApp#2Sem

AnnotSet#1

SemRec

Rules#1

ReferenceOntology

Architecture for semantic annotation and reconciliation

Reconciliation

Design-time

ICT

Model Driven Service Interoperability through use of

Semantic Annotations

I-ESA 2009 paperArne-Jørgen Berre

Fangning LiuJiucheng Xu

Brian ElvesæterSINTEF ICT

ICT

Model Driven Interoperability through Semantic Annotations using SoaML

and ODM

JiuCheng Xu*, ZhaoYang Bai*,

Arne J.Berre*, Odd Christer Brovig**

INCOM’09, Moscow,

3. June. 2009

9

fenglin Han

correct date April 22ndAll authors of the paper, with affiliation, ...

ICT

Contents

Introduction Description of EMPOWER and MEMPOWER

EMPOWER Project MEMPOWER Project

Comparison Semantic mappings Conclusion & Further work

ICT

EMPOWER

an innovative framework for interoperability between enterprise systems

a flexible and extensible architecture a system environment

System Interoperability LayerInteroperable

Enterprise Service

Designer

Wrapper Definition and Customization

Web Services Repository

Semantic Adaptation Layer

(2)Services Semantic

Annotator(SAWSDL)

(3)Ontology Handling

Utilities(OWL)

(5)Transformations Creator

Interoperable Enterprise Service

Wrapper

Mediator Services Web Server

Semantic Services Registry

Transformations Repository

ModelRepository

Legacy System Wrappers

Legacy Systems

(1)WSDL, OWL-S, WSML (4)Semantic Map

ICT

a Model Driven variant of EMPOWER, Compare with advantages and disadvantages of Model

Driven Interoperability

MEMPOWER

System Interoperability Layer

SemaphoreWrapperWeb Services Repository

(1)Model Mapping (SoaML)

Legacy System Wrappers

Legacy Systems

(4)Model Map

Semantic Adaptation Layer

(2)SAM (3)ODM

(5)Model Transformation

ServicesWrapper

Mediator Server

Semantic Services Registry Transformation

s Repository

ModelRepository

Ontology Definition Meta-model is a family of MOF meta-models,

mappings between those meta-models, and a set of profiles that

enable ontology modeling through the use of UML-based tools.

Ontology Definition Meta-model is a family of MOF meta-models,

mappings between those meta-models, and a set of profiles that

enable ontology modeling through the use of UML-based tools.

SoaML describes the services models. The Model Mapping in the MEMPOWER includes transformations from models to

ontology and ontology to models.

SoaML describes the services models. The Model Mapping in the MEMPOWER includes transformations from models to

ontology and ontology to models.

Semantic Annotation Model editor is used to relate different PIM models and ontology. It is used to annotate

the SoaML model with Ontology.

Semantic Annotation Model editor is used to relate different PIM models and ontology. It is used to annotate

the SoaML model with Ontology.

Model Transformation Services support the runtime lifting and lowering transformations among messages and ontologies based on the Model Map.

Model Transformation Services support the runtime lifting and lowering transformations among messages and ontologies based on the Model Map.

Model Map stores mapping rules.Model Map stores mapping rules.

ICT

The EMPOWER Enterprise Interoperable Services Semantic Map

13

ICT 14

SemanticAdaptation Architecture

ICT

PIM level use of Ontology mappings

15

ICT

Use of SoaML for PIM modeling

16

ICT

SAM – Semantic Annotations tools

17

(SASO: semantic annotation tool using SoaML and ODM)

ICT

Ontology example

18

ICT

Address Ontology

19

ICT

Address in Source and UML

20

ICT

“Address” in the source and target transformation rules

21

ICT

“Address” transformations from source.xml and target.xmi

22

ICT

SAM editor realized in tree views

23

ICT

Interface of demoInterface of demo

A simple example of class annotations on the PIM

level

A simple example of class annotations on the PIM

levelAnnotationsAnnotations

Ontology is represented as a structured and classified tree view. It

shows the properties and relationships between those classes.

Ontology is represented as a structured and classified tree view. It

shows the properties and relationships between those classes.

ICT

<soaml:Class name="POMessage” saName=“PurchaseOrderMessage” soaml:sterotype="messageType">

</soaml:Class> <soaml:Class name="Customer" saName=“Customer”

soaml:sterotype="DataType"> <soaml:Attribute name="customerId" saName=“hasCompanyRegNo”

type="String" modifier="public" /> <soaml:Attribute name="name" saName=“hasComanyName”

type="Name" modifier="public" /> <soaml:Attribute name=“address“ saName=“hasAddress”

type="String" modifier="public" /> <soaml:Attribute name=“creditScore" type="Integer" modifier="public" /> </soaml:Class>

<soaml:Class name="POMessage” saName=“PurchaseOrderMessage” soaml:sterotype="messageType">

</soaml:Class> <soaml:Class name="Customer" saName=“Customer”

soaml:sterotype="DataType"> <soaml:Attribute name="customerId" saName=“hasCompanyRegNo”

type="String" modifier="public" /> <soaml:Attribute name="name" saName=“hasComanyName”

type="Name" modifier="public" /> <soaml:Attribute name=“address“ saName=“hasAddress”

type="String" modifier="public" /> <soaml:Attribute name=“creditScore" type="Integer" modifier="public" /> </soaml:Class>

After annotating and exporting the model, you will get the file with a additional attribute. The annotations are displayed in red.

ICT

Semantic Mapping

1. Ontology-based mapping on the PSM-Level (EMPOWER) 2. Direct mapping on the PSM-Level 3. Ontology-based mapping on the PIM level(MEMPOWER) 4. Direct mapping on the PIM level

1 2 3 4

Approach Ontology-based PSM

Direct mapping PSM

Ontology-based PIM

Direct mapping PIM

ICT

Example: Address

Address in Target.xsd has only

one elements: Address

Address in Target.xsd has only

one elements: Address

Address in Source.xsd is divided into three elements: Address, Place, and Province

Address in Source.xsd is divided into three elements: Address, Place, and Province

Address in Ontology is divided into three

elements: Address, Region, and Province

Address in Ontology is divided into three

elements: Address, Region, and Province

ICT

1.PSM: Ontology-based Annotation based on ontology on the PSM-level

--Annotate source.xml and target.xml using Ontology

OntologyOntology

Source.xmlSource.xml

Address annotationAddress

annotation

ICT

2.PSM: Direct Mapping Mapping without ontology on the PSM-level

--Map between source.xml and target.xml (xsl:easy)

Target.xmlTarget.xml

Source.xmlSource.xml

ICT

3.PIM: Ontology-based 1.Transformation From PSM level to PIM level

--Generate sources.uml and target.uml from schemas (HyperModel Designer 3.1)

Address in Source.xsdAddress in Source.xsd

Address in Source.uml corresponds to

Source.xsd

Address in Source.uml corresponds to

Source.xsd

ICT



2.Mapping Between Models based on ontology on the PIM level

Step 1: Generate meta-models of models and ontology using

EMF

Step 1: Generate meta-models of models and ontology using

EMF

ICT




Step 2:Create mapping rules from source to ontology, and ontology to

target using ATL

Step 2:Create mapping rules from source to ontology, and ontology to

target using ATL

Ontology-Target

Ontology-Target

Source-OntologySource-Ontology

ICT


--Generate sources.uml and target.uml from schema (HyperModel Designer 3.1)


Step3: Transform source into ontology and ontology into

target

Step3: Transform source into ontology and ontology into

target

ICT

Transformation Between Models without ontology on the PIM level

--Use Semaphore tool to map source to target

4.PIM: Direct Mapping

Source.umlSource.uml

Target.umlTarget.uml

ICT

Conclusion

Ontology -based mapping (S-O-T) VS Direct mapping (S-T) on the PIM level 2N vs N²

Mapping between all model pairs will result in

N-squared mappings

Mapping between each model and ontology will result a linear growth of

number of mappings

Standard OntologyStandard Ontology

ICT

Conclusion

Mapping PIM-Level VS PSM-Level

Ontology-basedPSM

Direct mapping PSM

Ontology-basedPIM

Direct mapping

PIM

Mapping 2N N² 2N N²

StandardOntology

Y N Y N

PlatformIndependent

N N Y Y

Multi-source documents

Input

N N Y Y

Multi-target documents

Output

N N Y Y

ICT

Conclusion & Further work

Conclusion Ontology-based semantic annotations reduces mapping times

from N-squared to 2N, but cost is a standard ontology. Model Driven approach supports the interoperability independent

from platform technologies, compared to a platform specific technical approach.

Further work Implement multiple industrial use cases with five scenarios for

comparing EMPOWER and MEMPOWER.

ICT

Another example of Ontology-based Service: Message Reconciliation

ICT

Ad hoc reconciliation vs Ontology-based Reconciliation

Ad-Hoc Based on ad hoc adapters between pair of partners Not scalable respect to the growing of the number of partners

Ontology-based Highly independent solution, the semantic annotation does not

depend on the other business partners Highly scalable, the complexity of the Semantic Annotation

does not depend on the cardinality of the partners

ICT

Ontology-based reconciliation

Local Schema Local Schema

Enterprise A Enterprise B

SemanticAnnotation

SemanticAnnotation

ReconciliationRules

CustomizedMRE

CustomizedMRE

ReconciliationRules

Local Data Local Data

Design phase

Run-time phase

Interch.Repres.

Reference

Ontology

FWD transf BWD transf

BWD transf FWD transf

SW App SW App

Semantic Mediation and Reconciliation

Platform

Semantic Mediation and Reconciliation

Platform

ICT

Lossless and Lossy Annotations Lossless SA: when the annotation fully captures the intended

meaning A Local Schema (LS) element corresponds exactly to a concept in

the RO The meaning of a LS element can be precisely derived from

concepts in the RO

Lossy SA: when the annotation fails to fully representing the intended meaning The meaning of a LS element does not have a matching concept in

the ontology, nor the possibility of deriving it, since:- the intended meaning is outside the scope of the RO- The LS elem is not sufficiently refined (i.e., it does not match the

accuracy level of e ontology) [underspecification]- The LS element presents a level of refinement not deemed useful

[overspecification]

ICT

Example of Mismatch

Structuring

Purchase Order

• Order_Number

• Order_Date

• Buyer_Info– Name

– Address• Street_Name• Street_Num• City_Post_Code• Country

– Telephone

• Products_Info– Product_Code

– Description

– Quantity

– Price (unitary)

• Currency (Dollar, Euro, Pound)

• Charge

• RequestedDeliveryDate

Sale Order

• Date• Organization_Name• Contact_Person• Location

– Street_Address– City– LoCode– Country

• Phone_Number– Area_Code– Number– Ext

• Client_Order_Number• Order_Lines

– Product_Code– Description– Quantity– Price (total per line)

• Currency (USD, Euro, Yen)• Total

EnterprA (Buyer) EnterprB (Supplier)

ICT

Ontology-based Reconciliation Approach

Address

Street SnumCountryZip_Code

Location

Street_Address

Reference Ontology

City

Street_Name

Street_Number

City-Post_Code

Country

LoCode

Country

City

ICT

Local Schema (LS) Reference Ontology (RO)

Purchase Order (PO)…Address … City-Post_Code: literal

Address [ … City : literal Zip_Code: literal ]

Structuring Clash

Example of actual reconciliation

LS.PO.Address.City-Post_Code =:

RO. Address.City AND RO.Address.Zip_Code

Semantic Annotation

unpack(LS.PO.Address.City-Post_Code, “-”)

(RO.Address.City, RO. Address.Zip_Code)Reconciliation

Rule

{“Rome - 00185”} {“Rome”, “00185”}Run-time Reconciliation

ICT

…

<xsd:element name=“Address”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“Street_Name” type=“xsd:string”/>

<xsd:element name=“Street_Number” type=“xsd:positiveInteger”/>

<xsd:element name=“City-Post_Code” type=“xsd:string”/>

<xsd:element name=“Country” type=“xsd:string”>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

…

…<owl:Class rdf:ID=“Address”/>

<owl: DatatypeProperty rdf:ID=“Street”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Snum”> <rdfs:domain rdf:resource=“Address”/>

<rdfs:range rdf:resource=“&xsd;positiveInteger”/></owl: DatatypeProperty>

<owl: DatatypeProperty rdf:ID=“City”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Zip_Code”>

<rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty><owl: DatatypeProperty rdf:ID=“Country”> <rdfs:domain rdf:resource=“Address”/> <rdfs:range rdf:resource=“&xsd;string”/>

</owl: DatatypeProperty>…

Local Schema (XML Schema) Reference Ontology (OWL)

ICT

From Semantic Annotation to Transformation Rules

order.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson. hasPart _FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart _Surname

>:

AIDIMA order

RO

orderorder

orderheaderorder

header

productsinfo

productsinfo

supplierinfo

supplierinfo

buyerinfo

buyerinfo

orginfoorginfo

contactpersoncontactperson namename

orgNameorgName

addressdetails

addressdetails

productrecord

productrecord

descriptiondescription

productCodeproductCode

quantityquantity

……

……

……

buyerOrderNumberbuyerOrderNumber

……

……

orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


orderorder

orderheaderorder

header buyerinfo

buyerinfo

orginfoorginfo


PurchaseOrderPurchaseOrder

OrderLineOrderLine

IDID IssueDateIssueDate

BuyerBuyer

SupplierSupplier

ContactPerson

ContactPerson

SurnameSurnameFirstNameFirstName

ProductProduct

LinePriceLinePriceQuantityQuantity

BOD BOD

AA AA

BODAA

BA

CABA

BA

AA

AA

DescriptionDescriptionAA

NameNameAA

YearYearAA

MonthMonthAA


BuyerBuyer

ContactPerson

ContactPerson



BuyerBuyer

ContactPerson

ContactPerson


Split

SSAX

SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name

INTOPurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname

ForwardTransf Rule

ICT

An example of Transformation Rule in the Jena2 syntax

NameSplitting: [(?x0 rdf:type ai:order) (?x0 ai:has_orderHeader ?x1) (?x1 rdf:type ai:orderHeader) (?x1 ai:has_buyerInfo ?x2) (?x2 rdf:type ai:buyerInfo) (?x2 ai:has_organizationInfo ?x3) (?x3 rdf:type ai:organizationInfo) (?x3 ai:has_contactPerson ?x4) (?x4 rdf:type ai:contactPerson)(?x4 ai:has_name ?x5)]

[(?x0 rdf:type ro:PurchaseOrder_BOD) (?x0 ro:relTo_Buyer ?x2) (?x2 rdf:type ro:Buyer_BA)(?x2 ro:relTo_ContactPerson ?x4) (?x4 rdf:type ro:ContactPerson_BA)Split(?x4, “ ”, ?y1, ?y2, 'http://www.w3.org/2001/XMLSchema#string')(?x4 ro:hasPart_FirstName ?y1) (?x4 ro:hasPart_Surname ?y2)]

SPLITorder.has_orderHeader.has_buyerInfo.has_organisationInfo.has_contactPerson.has_nam

eINTOPurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName

PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname

ForwardTransf Rule

Rule in the Jena2 syntax

ICT

Conclusion and outlook BMM can be used to support discussions on Organisational

interoperability Support for semantics with ontologies and mediation is available now Short term benefit can be gained in the area of services for semantic

interoperability – through the use of ontologies, and use of mappings and transformations for information and service interoperability

i.e. – start here from an industrial perspective, establish ontologies, use these directly or mediate through semantic annotation.

Semantic Web Services and Service-oriented Semantic Architectures (SESA) is a promising future technology

Longer term benefits can be expected related to matching goals with services for process and service composition and process interoperability

48

ICT INF5120 – Modellbasert Systemutvikling F13: Model Driven Interoperability and MDA Industrial...

Documents

Transcript of ICT INF5120 – Modellbasert Systemutvikling F13: Model Driven Interoperability and MDA Industrial...