The Orchestra of Multiple Model Repositories

The Orchestra ofMultiple Model Repositories

Sergejs Kozlovič[email protected]

Research Laboratory of Modeling and Software TechnologiesInstitute of Mathematics and Computer Science, University of Latvia

The ``Orchestra'' Metaphor

Orchestra:• multiple musical instruments• playing simultaneously

002Research Laboratory of Modeling and Software TechnologiesInstitute of Mathematics and Computer Science, University of Latvia


Orchestra:• multiple musical instruments• playing simultaneously • multiple model repositories• accessed simultaneously

(inter-repository links are possible)



Orchestra:• multiple musical instruments• playing simultaneously • multiple model repositories• accessed simultaneously

(inter-repository links are possible)


Meta-s* a publication * a newspaper * The San Francisco Chronicle * the May 18 edition of the The San Francisco Chronicle * my copy of the May 18 edition of the The San Francisco Chronicle

* my copy of the May 18 edition of the The San Francisco Chronicle as it was when I first picked it up (as contrasted with my copy as it was a few days later: in my fireplace, burning)


The "Gödel, Escher, Bach" bookby Douglas Hofstadter

MOF Meta-Levels (Linguistic)



Artifacts are organized into three layers:• the meta-metamodel;• metamodels conforming to the meta-

metamodel;• models conforming to some particular

metamodel.

The Three-Level Conjecture(I. Kurtev and J. Bézivin)

The Three-Level Conjecture(I. Kurtev and J. Bézivin, 2005)

Artifacts are organized into three layers:• the meta-metamodel;• metamodels conforming to the meta-

metamodel;• models conforming to some particular

metamodel.

The meta-metamodel is able to describe itself.


MOF Meta-Levels (Linguistic)


UML metamodel

UML model

MOF

conforms to

conforms to

conforms to

Technical Spaces(I. Kurtev, J. Bézivin, and M. Aksit; 2002, 2005)


UML metamodel

UML model

MOF

conforms to

conforms to

conforms to

MOF TS

OWL classes

OWL individuals

OWL DL

conforms to

conforms to

conforms to

RDF/OWL TS

ER-model (DB schema)

DB rows

DB system tables

conforms to

conforms to

conforms to

Relational DB TS

Technical Spaces (cont.)(I. Kurtev, J. Bézivin, and M. Aksit; 2002, 2005)


XML schema(.xsd)

XML document

XML metaschema

(XSD.xsd)

conforms to

conforms to

conforms to

XML TS

Java grammar

Java program

BNF

conforms to

conforms to

conforms to

Grammarware TS

Why different technical spaces?

• One TS can be more suitable than another• Reusing skills and knowledge of a familiar TS• A capability not available in a desired TS can

be borrowed from another TS


TS interoperability

• Offline solution: using projectors and extractors (B´ezivin et al.)

• “Online” (On-the-fly) solution: this paper!o No deep copying of the data is required!


Problem 1: Numerous different repositories


See Table 1 in the paper!

Repositories


See Table 1 in the paper!

MOF TS:• EMF• CDO• MDR (NetBeans)• Enchanced Model

Repository• MetaMart Metadata

Repository• JR• ...

Repositories


The solution is a univeral Repository Access API, RAAPI• tda.lumii.lv/raapi.html

Problem 2: Ontological meta-levels


Ontological meta-levels


Meta-Levels (Ontological)A meta-metamodel that supports infinitely many ontological

meta-levels (used by the JR repository):


Meta-Levels (Ontological)A meta-metamodel that supports infinitely many

ontological meta-levels (used by the JR repository):


Meta-Levels (Ontological)

OWL Full also supports infinitely many ontological meta-levels.


Shostaks' conjecture

It is difficult for a human to think at more than two meta-levels at a time.

Still, it is pretty easy for a human to focus on any two adjacent meta-levels.


Shostaks' conjecture

It is difficult for a human to think at more than two meta-levels at a time.

Still, it is pretty easy for a human to focus on any two adjacent meta-levels.


Agris Šostaksat SOFSEM 2012

We divide the repository into two parts:

• M3 contating the meta-metamodel; fixed for a particular repository/technical

space;• all other data (either M2+M1 or multiple

ontological meta-levels)


Dealing with Šostaks' conjecture

Dealing with Šostaks' conjecture


• RAAPI is designed to work with any two adjacent meta-levels• Switching between levels and mixing them is possible by, e.g.,

passing a reference to a class when a reference to an object is expected.

The Idea

• The kernel represents all repositories as one big virtual repository.

• The kernel substitutes native references (integers) of each repository by globally unique proxy references.

• Inter-repository links are stored in the pivot repository.


Kernel Metamodel (the essence)


ProxyReferencedomesticReference:int64proxyReference:int64

Kernel

Repositoryurl:string

InterDirectedLink InterAttributeValuevalue:string

InterDirectedAssociationtargetRole:stringtargetCardinality:stringisComposition:Boolean

PackagesimpleName:stringnameInRepo:string

0..1 mounted Repository

1 mountPoint

1

pivot Repository

outgoingLinktarget Object

ingoingLink

source Object

0..1inverse

asso- cia- tion object

value

attributeinterSuperClass

interSubClass

outgoing Association

sourceClass1

ingoing Association

1 targetClass

0..1inverse

0..1parent

*child1rootPackage

1associated Repository

1 *

RAAPI call example: createLink()

createLink(obj1_ref, obj2_ref, association_ref);

• If all proxy references point to the same repository, the call is forwarded to this repository.

• Otherwise, an inter-repository link is created and stored in the pivot repository.


Organizing repositories

• Unix file system directory tree:/boot/bin/mnt /mnt/c /mnt/d/media /media/cdrom/etc


mount points


• Package tree (~ UML package tree):Package1Package2Package2::SubPackagePackage3Package4

• Use “MountPoint::ClassName” to access a class in a mounted repository


mount points



Pivot

Rootpackage

P1 P2

Sergejs Kozlovics



Pivot

Rootpackage

P1 P2

New repositorySubP

Sergejs Kozlovics


Problem 3:Manipulating the packages

How to merge packages?

I.e., when working with class Package1::A, objects and properties of Package2::A are also taken into a consideration.

Sergejs Kozlovics

Virtual repositories


Pivot

Rootpackage

P1 P2

Virtual repositorySubP

Relies on data from somewhere else (or, invents data)

Sergejs Kozlovics



Pivot

Rootpackage

P1 P2


Relies on data from somewhere else

Sergejs Kozlovics



Pivot

Rootpackage

P1 P2


Relies on data from somewhere else

On-the-flymodeltransformation

Sergejs Kozlovics

Use cases for virtual repositories


Views on metamodels


Pivot

Rootpackage

P1 P2


View

Basemetamodel

Sergejs Kozlovics

Volatile repository


Pivot

Rootpackage

P1 P2

Virtual repository(stores its content

In RAM)

SubP

Volatilerepository

Sergejs Kozlovics

Virtual merge


P

Q

Sergejs Kozlovics

Virtual merge


P

Virtual repositoryimplementing

“merge”

Q

P

Sergejs Kozlovics

Derived (calculated) associations and properties


A B

Sergejs Kozlovics



A B A B

Virtual repositorycomputes

the association

Sergejs Kozlovics



A B A B

Virtual repositorycomputes

the association

Finally, we just need to virtually merge these two packages!

merge

Sergejs Kozlovics

Virtual copy


P

Sergejs Kozlovics

Virtual copy


P Virtualrepository

2

P’

P(old data)

Virtualrepository

1

Sergejs Kozlovics

Virtual copy


P Virtualrepository

2

P’

P(old data)

Virtualrepository

1

Δ2Δ1

Sergejs Kozlovics

Thank you!Děkuji!


The Orchestra ofMultiple Model Repositories

[email protected]

The Orchestra of Multiple Model Repositories

Documents