Model Driven Engineering (MDE) and Diagrammatic Predicate ... · Diagrammatic Predicate Logic (DPL) DPL Aims to combine the intuition from graphical modeling languages with the semantic

Introduction and MotivationConcepts in DPL

OMG standards and Metamodeling LevelsTools

Key �ndingsModel Transformations

Model Driven Engineering (MDE) andDiagrammatic Predicate Logic (DPL)

Yngve Lamo

Department of Computer Engineering

Faculty of Engineering

Bergen University College

NORWAY

06.06.2008Institute of Mathematics and Informatics, Vilnius, LITHUANIA

Yngve Lamo MDE and DPL




Personal MotivationModel-driven Engineering (MDE)Modeling languages state of the artDiagrammatic Predicate Logic (DPL)

Project goal

To apply and adapt formal methods to software engineering

Actual research on MDE and MDE-related standards andapproachesDevelop a formal framework to express software models andmodel transformationsDevelop tools that justi�es the framework






Outline1 Introduction and Motivation


2 Concepts in DPLSpeci�cationExampleInstance

3 OMG standards and Metamodeling LevelsMetamodelingDPL meta modelEcore meta model in DPL

4 Tools5 Model Transformations






History of our project:

Ph.d in Theoretical Computer Science 2003, algebraicspeci�cations, logic and category theory

Discussions with professor Uwe Wolter since 2000 about howto use theory in practice

In 2000 Wolter introduced me to the Generalized Sketchesframework, created in Latvia in the 90's, by Diskin ++

2003, we decided to try to use the GS approach for practicalsoftware engineering






...

2004 master student Ørjan Hatland started to implement atool for GS, based on the .NET framework, (graduated 2006)

Early 2006 Ph.d student Adrian Rutle started to investigatethe subject and we get interested in MDE and the Eclipseframework

2006 Master student Stian Skjerveggen started to implement agraphical editor in Eclipse framework, (will graduate June2008)
















MDE

Engineering techniques where models are �rst-class entities

Evolved from the popularity of diagrammatic languages suchas UML and ER and their popularity for speci�cation anddocumentation of software systems

Aims to raise the abstraction level of software developmentfrom text to models

The development process is based on software models, not onplain text






Industry "standard" for MDE

Model Driven Architecture (MDA) approach from ObjectManagement Group (OMG) where:

First step is building platform independent domain models,PIM'sPIM's are re�ned to platform speci�c models PSM'sRe�nement process more or less automatized as modeltransformationsCode generation and model re�nement can be seen as modeltransformationsReuse of software models by using model transformations






MDD vs Traditional Development Processes






Key point for success for MDE

Models are no longer only for documentation

Models should be both:

intuitive for software engineers to intercept and work withformal such that machines could have precise understandingand reason about the models

⇒ Diagrammatic approach enhance human understanding⇒ Challenge to combine intuition with formalization




































Some facts about UML

UML is defacto industry standard for modeling

UML can only express constraints on binary relations

UML has serious issues regarding:

Semantics; UML models may be ambiguous and havesemi-formal semanticsComplexity; UML uses 13 di�erent types of diagramsExpressibility; To express constraints over higher order relationsone need to use string based logic, (Object Constraint Logic,OCL)






Formal modeling languages

Nice semantics, proven abilities and several fundamentalSoftware Engineering problems solved by use of formalmethods

Set based semantics (logic, algebras etc...)

Hard for software engineers to apply in practice

Lack of good software development tools based on formalapproaches

Only used by well trained experts

High cost low productivity
















DPL

Aims to combine the intuition from graphical modelinglanguages with the semantic rigor of formal methods

Based on Generalized Sketches

Sketches is a graphical representation of category theory,constraints expressed by universal constructions (limits andco-limits) of diagrams

Generalized Sketches is sketches extended with constraints onarbitrary diagrams, not only universal constructions

In DPL, sketches are generalized and adapted to model drivensoftware engineering






More on DPL

DPL will be used as a framework for de�ning modelinglanguages and transformations between them in a formalgraphical way

We work continuously on Investigating, Analyzing, Adapting,Verifying and Evaluating DPL

Potential to use the machinery from category to implementMDE tools





Speci�cationExampleInstance











Diagrammatic speci�cations

Signature

Set of constraint (predicate) names Π withAn arity function α : Π → graph

Diagrammatic Speci�cations consist of

the underlying graph G(S) together with aset of constraints CS i.e. diagrams δ : α(cS) → G, wherecS ∈ Π
















Signature � Example

Π α visualization intended semantics

[total] 1x // 2 A •

f // B ∀a ∈ A : |f (a)| ≥ 1

[key] 1x // 2 A

f [key ]// B ∀a, a′ ∈ A : a 6= a′ implies f (a) 6= f (a′)

[inv] 1

x

$$2

y

cc A

f

%%[inv ] B

g

dd ∀a ∈ A , ∀b ∈ B : b ∈ f (a) i� a ∈ g(b)

[jointly-key]or [1-1]

1x //

y

��

2

3

Af //

g

��

[1−1]

B

C

∀a, a′ ∈ A : a 6= a′ implies f (a) 6= f (a′) org(a) 6= g(a′)






Diagrammatic Speci�cation � Example

Person

Employment

Company

[1-1]

worksFor

hires

employee employer

[String] [String]

c_nameaddressp_name

[Int]

salary

[Date]

start_date

1 1

11

1

11

[key]

[inv]






Diagrammatic Speci�cation � Example

Person

Employment

Company

[1-1]

worksFor

hires

employee employer

[String] [String]

c_nameaddressp_name

[Int]

salary

[Date]

start_date

1 1

11

1

11

[key]

[inv]

Person

Employment

CompanyworksFor

hires

employee employer

[String] [String]

c_nameaddressp_name

[Int]

salary

[Date]

start_date

Constraints S(Pi):

[inv]

[1-1]

graph G(S)
















Instance of Diagrammatic Speci�cation � Example

p1:Person

e1:Employment

c1:Companyw2:worksFor

h2:hires

eme2:employee emr2:employer

Ola:Str Bergen:Str

cn2:c_namea2:addresspn2:p_name

30000:Int

s2:salary

01.01.2006:Date

sd2:start_date

HiB:Str

p3:Person

e3:Employment

w3:worksFor

h3:hires

eme3:employeeemr3:employer

Petra:Str

pn3:p_name

10000:Int

s3:salary

01.01.2008:Date

sd3:start_date

p2:Person

e2:Employment

c2:Companyw1:worksFor

h1:hires

eme1:employee emr1:employer

Per:Str Bergen:Str

cn1:c_namea1:addresspn1:p_name

20000:Int

s1:salary

01.01.2007:Date

sd1:start_date

UiB:Str






Instance of speci�cation

The semantic interpretation of Σ := (Π, α) assigns to eachp ∈ Π a set [[p]] of graph homomorphisms τ : O → α(p),where O may vary over all graphs.

An instance of a speci�cation S is a graph I together with agraph homomorphism ι : I → G (S), such that ι∗ ∈ [[p]], i.e. ι∗

is a valid instance of p for each constraint (p, δ) whereδ : α(p) → G (S).ι∗ is given by the pullback diagram:

α(p)δ // G (S)

O∗δ∗

//

ι∗

OO[PB]

I

ι

OO





MetamodelingDPL meta modelEcore meta model in DPL











OMG Metamodel Levels

OMG levels OMG Standards/examples

M3: Meta-metamodel MOF

M2: Metamodel UML language

M1: Model A UML model: Class "Person" withattributes "name" and "address"

M0: Instance An instance of "Person": "OlaNordmann" living in "Sotraveien 1,Bergen"
















DPL Methodology and Modeling Formalisms

Modeling Formalism F2 = (Σ1,M2,Σ2)

Meta-formalism F3 = (Σ2,M3,Σ3)

F3 is re�exive i� (Σ3 v Σ2)






DPL Methodology and Modeling Formalisms

Modeling Formalism F2 = (Σ1,M2,Σ2)

Meta-formalism F3 = (Σ2,M3,Σ3)

F3 is re�exive i� (Σ3 v Σ2)
















Ecore model expressed in DPL

Ecore is the metamodel of the Eclipse Modeling Framework, EMF

EClassifier

eStructuralFeatures

eAttributes

EClassifier

EPackage

eClassifiers

EClass EDataType

[disjoint]eSuperType eSuperType

eReferences

Meta-formalism E3 (EClassi�er, EReference),essentially Graph

Modeling Formalism,E2 (EPackage), typedover E3:t(EPackage) = t(EClassifier) =t(EClass) = t(EDataType) = EClassifier,

t(eClassifiers) = t(eType) =t(eAttribues) = t(eReferences) =eStructuralFeatures








EClassifier

eStructuralFeatures

eAttributes

EClassifier

EPackage

eClassifiers

EClass EDataType


eReferences











EClassifier

eStructuralFeatures

eAttributes

EClassifier

EPackage

eClassifiers

EClass EDataType


eReferences








Tools

Tools implemented as plug-ins to the Eclipse platform

Need tools for:

Drawing of models, partly �nished June 2008Serialization of models, work startedValidation of models, future research projectModel transformation tools, reasearch started





Drawing tool

Built over Eclipse Graphical Modeling Framework, GMF

Will build separate tool for building signatures, conforms to amodeling language

Tool for creating models over signatures, i.e. modeling tool inthe chosen language

Today drawing tool still some issues with diagrams with morethan 3 nodes





Summary

The industry have a lot of hidden knowledge, they have noneed for formalization

Modeling community work with �brations, not index as we aretrained to in mathematics

Practical problems seems easy in theory but you really get dirton your �ngers

We have obtained good understanding on modeling, metamodeling and model transformation





Further work

Work on classi�cation of model transformations, whatproperties has di�erent class of transformations?

Implement di�erent formalisms in DPL (UML, XML, ...)

Implement model transformation tool with code generationand cross platform translation





Model Transformation Concepts

Model Transformation = set of Transformation Rules +Coordinations (⇒ operational)

Model Transaction = declarative de�nition of thetransformation

Transformation Engine = executes the rules





Transformation Rules

PιP

||yyyyyyyyy

m

��

P′

ιP′

""FFFFFFFFF

[[t]](m)

��

� //

G (M1) Iιoo

[=]

trace

//I′

ι′

//[=]

G (M2)

Input and output patterns P and P ′

Input and out put instances I and I ′

The models M1 and M2

The matches m and [[t]](m)





Transformation Rules

PιP

||yyyyyyyyy

m

��

P′

ιP′

""FFFFFFFFF

[[t]](m)

��

� //

G (M1) Iιoo

[=]

trace

//I′

ι′

//[=]

G (M2)

Input and output patterns P and P ′

Input and out put instances I and I ′

The models M1 and M2

The matches m and [[t]](m)


Documents

Model Driven Engineering (MDE) and Diagrammatic Predicate ... · Diagrammatic Predicate Logic (DPL) DPL Aims to combine the intuition from graphical modeling languages with the semantic