A Validation of ISO 19763-2: the Metamodel Framework for Interoperability - Core Model Baba Piprani...

A Validation of ISO 19763-2:the Metamodel Framework for Interoperability - Core Model

Baba Piprani (SICOM Canada) Robert Henkel (Transport Canada)

Baba Piprani / Robert Henkel Metadata Open Forum Sydney - 2008-05-20

2

Your presenter…Baba Piprani, SICOM Canada

• Senior IT Consultant with over 30 yrs standardization experience…Computer Languages, SQL, Conceptual Schema, Data Modelliing, IRDS, Metadata Registry, MOF…

• Developed award winning implementations of standards-based Data Quality Firewalls with advanced generation architecture data warehouses and Web based applications using SBVR, ORM, NIAM, Master Data Management, Metadata Repositories/Registries using SQL DBMSs…

• Clients: Canadian Government departments Transport, Foreign Affairs, Defence, Superintendent of Financial Systems, Public Works…including private sector, and CNIS (China National Institute for Standardization)


3

Agenda

1. Overview of ISO 19763-2 Metamodel Framework for Interoperability - Core Model

2. Object Role Model based schema for 19763-2 3. Validation Package approach 4. Scoping and Transformation to attribute based

model for prototype implementation 5. The ISO 9075 SQL based physical prototype

schema 6. Validation Population

7. Validation results 8. Summary and Conclusions


4

The ISO/IEC 19763 Framework for Metamodel Interoperability standard consists of 4 parts:

Part 1 – Reference Model Part 2 – Core Model Part 3 – Metamodel for Ontology Registration Part 4 – Metamodel for Model Mapping

Part 1 describes concepts and architecture to be applied in the development and registration of individual metamodel frameworks in other parts.

Part 2 specifies the core model to describe metamodel items Part 3 specifies the metamodel that provides a facility to register

administrative information about ontologies Part 4 provides a metamodel for describing differences in format

and type of objects and transformation rules to be exchanged or shared


5

19763-2 Objective:

• Standardize domain specific business models and standard modelling constructs

• Provide a unified framework for classifying and registering normative model elements

• Specify common bases for consistent development and registration of metamodels

• Establish harmonisation of metamodels that have been developed independently

• Facilitate their reuse widely across organisations


6

19763-2 Core provides:

• A set of modeling elements, including the rules for their use, with which to register models

• An infrastructure for sharing information enabling cooperation between companies in e-business and e-commerce

• Facilitates sharing of independently developed metamodels and models

• A set of modeling elements and the rules for their use to support development of metamodels

• Adherence to the four layer architecture of the Meta Object Facility (MOF)


7

Type-Instance

Pattern :

Universe of Discourse

Modeling Constructs

Meta-metamodel

Stereotype :

Template:

MetaModel MetaModel

MetaModel

Modeling Facility

ModelingMethodology

M3

M2

M1

M0

ModelModel

XML SchemaXML Schema

XML InstanceObject

Super-Sub,Base-Variant

Type-Instance

Abstract syntax-Expression

Metadata Architecture and artifacts for registration


8

Main purpose of ISO/IEC 19763: Metamodel Framework for Interoperability (MFI)

• To achieve the sharing of common and useful modeling artefacts

• MFI core model is located within the MOF architecture as a metamodel conforming to MOF

• Other metamodels described using MOF can also be placed independently within the MOF architecture

• From the MFI viewpoint, those metamodels are referred as components defined by MOF and UML

Type-Instance

Pattern :

Universe of Discourse

Modeling Constructs

Meta-metamodel

Stereotype :

Template:

MetaModel MetaModel

MetaModel

Modeling Facility

ModelingMethodology

M3

M2

M1

M0

ModelModel

XML SchemaXML Schema

XML InstanceObject

Super-Sub,Base-Variant

Type-Instance

Abstract syntax-Expression


9

MOF

MDR- ByMOF

ObjectByMOF

MFI- Core

Classifier

Target

LevelPair Registry Relationship

<<use>>

<<instanceOf>>

<<instanceOf>>

<<use>>

<<reference>><<use>>

<<use>> <<use>>

<<use>>

<<use>>

<<reference>>

<<reference>>

<<instanceOf>>

MFI -Core Packages and Target Models


10

MFI core model as a MOF conforming metamodel

• MFI core model is located within the MOF architecture as a metamodel conforming to MOF

• Other metamodels described using MOF can also be placed independently within the MOF architecture

MOF

MDR- ByMOF

ObjectByMOF

MFI- Core

Classifier

Target

LevelPair Registry Relationship

<<use>>

<<instanceOf>>

<<instanceOf>>

<<use>>

<<reference>><<use>>

<<use>> <<use>>

<<use>>

<<use>>

<<reference>>

<<reference>>

<<instanceOf>>


11

19763-2 MFI core model …

• The MFI core model is organized into five functional packages:

• Registry Package (normative)• Target Package (normative) • Relationship Package (normative) • ModelClassifier Package (informative)• LevelPair Package (informative)


12

ModelSign

namespace: string[1..1]sign: string[1..1]

ModelConcept

model type: typeCode[1..1]

ModelSelection

condition: string[0..1]

ModelComponentSet

conceptualization type: typeCode[1..1]component type: typeCode[1..1]format: string[1..1]

ModelDomainProfile

name: string[1..1]conformance: string[0..*]

ModelClassifier

model type: typeCode[1..1]usage type: typeCode[1..1]xmi text: string[0..1]attachment type: string[0..1]attachment: URI[0..1]

ModelComponent

Administered Item

has

0..*

specifies 0..*

specified by 1

classifies

0..*classified by

0..1

conceptualizes0..*

conceptualized by1

selected by

0..*

selects

1

expresses 0..*

expressed by 1

designated by

0..*

designates

1

Figure 4- Registry package in MFI Core


13

ModelDomainProfile

name: string[1..1]conformance: string[0..*]

ModelSpecification

format: string[1..1]original: URI[1..1]issue date: date[1..1]source: string[1..1]status: string[1..1]version: number[1..1]purpose: string[1..1]title: string[1..1]normativeReference: string[0..*]scope: string[1..1]termDefinitions: string[0..*]conformance: string[0..*}

ModelComponentModelSelection

condition: string[0..1]

Administered Item

ModelByMOF

model layer level: string[1..1]isMOFcompliant: boolean[1..1]MOFversion: string[1..1]

ModelClassifier

model type: typeCode[1..1]usage type: typeCode[1..1]attachement type: string[0..1]xmi text: string[0..1]attachement: URI[0..1]

PackagedObject

NamedElementModelConstruct has

1..*

1

has

0..1

uses 0..*

definedwith UML

0..1

has

0..*

consists of 0..*

specified by

0..*

references

0..*

described by 0..*

Figure 5- Target package in MFI Core


14

ModelConcept ModelClassifier

ModelAssociationModelAssociationEnd

name: String[0...1]annotation: String[0..1]

ends

2

Figure 6- Relationship package in MFI Core


15

Agenda


2. Validation Package approach 3. Object Role Model based schema for 19763-2 4. Scoping and Transformation to attribute based


schema 6. Validation Population7. Validation results 8. Summary and Conclusions


16

Validation Package Approach…

1. Transform UML models in MFI packages to Object Role Model (ORM) schema (at the context class level)

2. Analyze ORM schema for inconsistent semantics for further reference

3. Transform ORM schema to attribute based data model using IDEF1X and associated tool ERWin

4. Transform ERWin data model to ISO 9075 based SQL Schema DDL

5. Create Database instance for prototype on MS SQL Server 2005

6. Populate sample instances in database to validate model as per inconsisten semantics developed in #2


17

Agenda


2. Validation Package approach 3. Object Role Model based schema for 19763-24. Scoping and Transformation to attribute based


schema 6. Validation Population

7. Validation results 8. Summary and Conclusions


18

ModelComponent

OWNED BY/has

ModelComponent

Set

ModelDomainProfileOWNED BY/consists of

ModelClassifier

ModelSelection

ModelSign

ModelConcept

Conceptualized by/conceptualizes

ModelAssociation

ModelAssociation

EndOWNED BY / ends

2

References/OWNED BY

Defined with UML / uses

Model ByMOF

OW

NE

D B

Y/S

peci

fied

by

Design

ates

/des

ignat

ed b

yS

elec

ts/S

elec

ted

by

Expressed by/expresses

ModelSpecification

described by / CO

MP

OS

ED

OF

classifies/Classified by

Spe

cifie

d by

/spe

cifie

s

OW

NE

D B

Y/ h

as

Integrated Object Role Model (ORM) Schema for 19763-2

LegendGrey : Figure 4Red : Figure 5Green : Figure 6


19

ORM analysis inconsistencies…

Scenario 1: Component to DomainProfile – 2 paths

Scenario 2: ComponentSet to Sign– 2 paths

Scenario 3: Selection with incorrect association – 2 paths

Scenario 4: Classifier to component to item 1 – 2 paths

Scenario 5: DomainProfile to Concept to ComponentSet to Component – no reuse, data integrity issues


20

Agenda




schema 6. Validation Population7. Validation results 8. Summary and Conclusions


21IDEF1X Data Model of Figs 4, 5


22

ISO 9075 SQL based physical prototype schema…1


23



24



25



26

Agenda




schema 6. Validation population7. Validation results 8. Summary and Conclusions


27

Validation sample population..


28

Scenario 1: Component to DomainProfile – 2 paths ModelComponent population as per IS 19763-2 Fig 4


29

Scenario 1: Component to DomainProfile – 2 paths Populations: ModelComponentSet


30

Scenario 1: Component to DomainProfile – 2 paths Populations: ModelConcept


31

Scenario 1: Component to DomainProfile – 2 paths Populations: ModelDomainProfile


32

Scenario 1: Component to DomainProfile – 2 paths ModelComponent population as per

IS19763-2 Fig 4 – Fig 5


33

Scenario 1: Component to DomainProfile – 2 paths ModelComponent population as per

IS19763-2 Fig 4 – Fig 5

Possible anomaly :“The [ModelDomainProfile consists of ModelComponent ] must be same as the [ModelDomainProfile that specifies ModelConcept that conceptualizes ModelComponentSet that has [ModelComponent]” Since there are 2 navigatable paths to ModelDomainProfile from ModelComponent when the Registry and Target Package models are integrated, either the rule is needed or the redundant path [ModelDomainProfile consists of ModelComponent] of Fig 5 does not belong.


34

Scenario 2: ComponentSet to Sign– 2 paths ModelSelection


35

Scenario 2: ComponentSet to Sign– 2 paths ModelSelection

Anomaly: Valid values but incorrect associations….


36

Validation sample population..Now add FA2400…


37

Scenario 3: Selection with incorrect association – 2 paths Introducing more Populations: ModelComponentSet


38

Scenario 3: Selection with incorrect association – 2 paths Introducing more populations: ModelComponent


39

Validation sample population..Note following slide discrepancy FA2400


40

Scenario 3: Selection with incorrect association – 2 paths Populations: ModelSelection

Valid values but incorrect associations….


41

Scenario 4: Classifier to component to item 1 – 2 paths Add Populations: ModelDomainProfile


42

Scenario 4: Classifier to component to item 1 – 2 paths Populations: ModelClassifier

Association Anomaly: Currently reads as[ModelComponent has ModelClassifier] or alternatively[ModelClassifier owned by Model Component]


43

Scenario 5: DomainProfile to Concept to ComponentSet to

Component Add populations ModelComponentSet


44

Scenario 5: DomainProfile to Concept to ComponentSet to Component

Add populations ModelComponent

No Reusability of Components: City, Province, Country


45

Agenda




schema 6. Validation Population7. Validation results

8. Summary and Conclusions


46

Summary and Conclusions

1. Unable to fit Model Component examples into schema2. Unable to reconstruct from inputed data3. Unable to reuse – granularity at lowest level not

reusable4. Absence of model semantics rule check on inputted

data IDEF1X & IDEF0 – an entity can be matched without

constraint with a UML class for a given association---action NOT permitted across 2 semantic model sets

IDEF1X can be shared in IDEF0 across 2 model semantics – permitted action this info is missing in model

5. Incomplete solution


47

SemanticModels

(SBVR, ORM, OWL, RDF)

Applications

Attribute BasedModels

(UML,ER,Relationaletc)

Platform Independent

Models

MFI Services•Model Integrity•Model Validation•Model Consistency•Model Exchange•Model Registry•Model Transforms

MFI Metadata Registry

MFI Core Schema

Users

Systems

Our Vision of 19763 Reference Model.

A Validation of ISO 19763-2: the Metamodel Framework for Interoperability - Core Model Baba Piprani...

Documents

Transcript of A Validation of ISO 19763-2: the Metamodel Framework for Interoperability - Core Model Baba Piprani...