modelog model oriented development with executable logical object generation n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
MODELOG – Model-Oriented Development with Executable Logical Object Generation PowerPoint Presentation
Download Presentation
MODELOG – Model-Oriented Development with Executable Logical Object Generation

Loading in 2 Seconds...

play fullscreen
1 / 47

MODELOG – Model-Oriented Development with Executable Logical Object Generation - PowerPoint PPT Presentation


  • 114 Views
  • Uploaded on

MODELOG – Model-Oriented Development with Executable Logical Object Generation. Franklin Ramalho Universidade Federal de Pernambuco PhD candidate Jacques Robin Advisor. ORCAS Group. Outline. 1 Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'MODELOG – Model-Oriented Development with Executable Logical Object Generation' - truly


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
modelog model oriented development with executable logical object generation

MODELOG – Model-Oriented Development with Executable Logical Object Generation

Franklin Ramalho

Universidade Federal de Pernambuco

PhD candidate

Jacques Robin

Advisor

ORCAS Group

outline
Outline

1 Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

introduction
Introduction
  • Initial role of UML (Unified Modeling Language)
    • Visual notation for high-level blueprints in Object-Oriented Software Engineering (OOSE);
    • Standard, intuitive, expressive, extensible, many CASE tools available.
  • New roles for UML:
    • Model-Driven Engineering:
      • Abstract visual syntax for meta-modeling;
      • Low-level specification language for fully automated code generation;
      • Formal specification language for formal verification.
    • Knowledge-level representation language for:
      • Autonomous agents and multi-agent systems (MAS)
      • Semantic web service for knowledge management and intelligent information retrieval
introduction1
Extensions to the UML:

OCL (Object Constraint Language);

MOF (Meta-Object Facility);

XMI (XML Metadata Interchange);

UML Profiles;

Formal Semantics for UML and OCL;

AUML (Agent UML).

Introduction
motivation

Model-Driven

Engineering

Formal

Development

and model-checking

  • Automatic generation of complete structural and behavioral code
  • Real-size example fully adopting a MDE approach
  • Integrated semantics for
  • UML and OCL
  • Verification of executable
  • formal model

Semantic Web

Service

Development

Agent Oriented

Engineering

  • combine strengths of AOextensions of OO andLogic/Formal methods
  • Automatic code generation
  • of OO Logic agents
  • SWS representation
  • and reasoning

Agile Development

  • Fast prototyping
  • Automatic structural and
  • behavioral code generation
Motivation
modelog

Target language: Flora

Object-Oriented

Logic Programming

W3C Standard for

Semantic Web Services

OCL

UML

  • UML2 class diagrams annotated
  • with OCL2 structural constraintsand behavior specification
MODELOG
  • MODELOG goal:
    • Address all 5 new application areas of UML by single automated mapping
    • From UML2 class diagram w/ OCL2 structural constraints and behavior specifications
    • To executable, Turing-complete, programming language with formal semantics

MODELOG

outline1
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

model driven engineering

Abstraction

Scale

Executability

Scale

Model-Driven Engineering

Current Standard Practice:

Object-Oriented Development

UML + NL

Application

Requirements

UML

Model

Mix 2 orthogonal concerns: business refinement and translation to platform

Source

Code

Virtual

Machine

Code

Binary

Code

model driven engineering1

Abstraction

Scale

UML/OCL

Business

CIM

Profiled

UML/OCL

Application

Realization

PSM

Source

Code

Virtual

Machine

Code

Binary

Code

UML/OCL

Application

Specification

PIM

UML/OCL

Application

Realization

PIM

Executability

Scale

Model-Driven Engineering

Today’s MDE:

Extreme Modeling

model driven engineering2

Abstraction

Scale

Model

Refinement

Patterns

Model

Translation

Patterns

UML/OCL

Business

CIM

Profiled

UML/OCL

Application

Realization

PSM

Source

Code

Virtual

Machine

Code

Binary

Code

UML/OCL

Application

Specification

PIM

UML/OCL

Application

Realization

PIM

Executability

Scale

Model-Driven Engineering

Tomorrow’s MDE:

UML Programming

mde languages

MOF, XMI, KM3, Ecore

Meta-

meta-model

Meta-

model

Meta-

model

Rule X{...}

Rule X{...}

Rule X{...}

Definições de transformação

Definições de transformação

Definições de transformação

Code

CIM

PIM

PSM

Transformation

Engine

Transformation

Engine

Transformation

Engine

QVT, ATL, Flora, ATL-DT

UML and OCL

UML Profiles

MDE Languages

Aplicação

source models uml and ocl

context Triangle::isCompatible(other:Triangle, selfSide:SegmentLine, otherSide:SegmentLine):boolean

body:

let

selfSide1 : SegmentLine = self.triangleSide->select(side = hypotenuse).adjacent->first().side,

selfSide2 : SegmentLine = self.triangleSide->select(side = hypotenuse).adjacent->at(2).side,

otherSide1 : SegmentLine = other.triangleSide->select(side =hypotenuse).adjacent->first().side,

otherSide2 : SegmentLine = other.triangleSide->select(side = hypotenuse).adjacent->at(2).side,

in

self <> other and self.right and other.right and

self.hypotenuse.length = other.hypotenuse.length and

((selfSide1.length = otherSide1.length and

selfSide2.length = otherSide2.length) or

(selfSide1.length = otherSide2.length and

selfSide2.length = otherSide1.length)) and

selfSide = self.hypotenuse and otherSide = other.hypotenuse

context Triangle::hypotenuse : SegmentLine

derive:

let base : SegmentLine =

triangleSide->select(position = TriangleSideKind::base)->asSequence()->first().side,

left : SegmentLine =

triangleSide->select(position = TriangleSideKind::left)->asSequence()->first().side,

right : SegmentLine =

triangleSide->select(position = TriangleSideKind::right)->asSequence()->first().side

in

if (base.length > left.length and base.length > right.length)

then base

else if left.length > right.length

then left

else right

endif

endif

context Robot::buildRectangle(New:Rectangle):boolean

pre:

availableTriangle(part1) and availableTriangle(part2) and

part1.isCompatible(part2, part1Side, part2Side)

post:

let pol3:Rectangle = pol3.oclIsNew() …

in

. . .

table.convexPolygon->includes(pol3) and …

New = pol3 and result = availableRectangle(New)

context EquilateralTriangle inv inv_12:

side->forAll(s1, s2 | s1.length = s2.length)

Source models: UML and OCL
outline2
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

target model sequential transaction frame logic stfl

- class::superclass[...attri typOpi typei,..., methj(...,paramjk,...) typOpj typej...]- object:class[...attri assignOp1 valuei, ...,methj(...,paramjk,...) assignOpj valuej ...]

High Order

Meta-atoms

  • a(X) (b, c)
  • W(b, c)

Structural

Diagram

OO atoms

Equality

Frame

Logic

HiLog

p1 ...  naf pn  c

p1 ...  pn  c

Sequential

Transaction

Frame

Logic

Normal

Logic

DefiniteLogic

OCL

SequentialTransaction

Logic

p1 ...  pn  c1  ...  cn

a(Y, b)

Connectives: , 

Predicates: delete, insert

Behavioral

Diagram

Target Model: Sequential Transaction Frame Logic (STFL)

Classical

First

Order

Logic

a stfl program
A STFL Program

Acct[withdraw(Amt)] :- Acct[balance-> Bal]  Bal ≥ Amt  Acct[change_balance( Bal, Bal - Amt)].

Acc[deposit(Amt)] :- Acct[balance-> Bal]  Acct[change_balance( Bal, Bal + Amt)].

Acct[change_balance( Bal1, Bal2)] :- btdelete{Acct[balance->Bal1]}  btinsert{Acct[balance-> Bal2]}.

transfer( Acct1, Acct2, Amt) :- Acct1[withdraw(Amt)]  Acct2[deposit(Amt)].

buy(Client, Seller, Cost) :- transfer(Client, acc5, 0,5 * Cost)  transfer(Client, Seller * Cost).

acc1[balance->50, owner->philip].

acc2[balance->600, owner->daniel].

acc3[balance->1200. owner->roger].

acc4[balance->10, owner->mary].

acc5[balance->5000, owner->broker].

?- buy(acc3, acc4, 500).

stfl denotational semantics

Data oracles (optimistic 3-valued Herbrand models)

+ transition oracles (execution paths)

optmistic 3-valued Herbrand Models

Well-founded 3-valued Herbrand Models

Sequential

Transaction

Frame

Logic

2-valued Herbrand Models

Data oracles (well-founded 3-valued Herbrand models)

+ transition oracles (execution paths)

STFL Denotational Semantics

Frame

Logic

HiLog

First

Order

Predicate

Logic

Normal

Logic

DefiniteLogic

SequentialTransaction

Logic

stflp semantics data oracles
STFLP Semantics – Data Oracles

Od(D0) = M0

Od(D1) = M1

Od(D2) = M2

Od(D3) = M3

Od(D4) = M4

Od(D5) = M5

Od(D6) = M6

Od(D7) = M7

Od(D8) = M8

M0 = {acc1[balance->50], acc1[owner->philip], acc2[balance->600], acc2[owner->daniel],

acc3[balance->1200], acc3[owner->roger], acc4[balance->10], acc4[owner->mary],

acc5[balance->5000], acc5[owner->broker]}

M1 = {acc1[balance->50], acc1[owner->philip], acc2[balance->600], acc2[owner->daniel],

acc3[owner->roger], acc4[balance->10], acc4[owner->mary],

acc5[balance->5000], acc5[owner->broker]}

M2 = {acc1[balance->50], acc1[owner->philip], acc2[balance->600], acc2[owner->daniel],

acc3[balance->1175], acc3[owner->roger], acc4[balance->10], acc4[owner->mary], acc5[balance->5000], acc5[owner->broker]}

stflp semantics transition oracles
STFLP Semantics – Transition Oracles

Ot(D0, D1) = btdelete{acc3[balance->1200]}

Ot(D1, D2) = btinsert{acc3[balance->1175]}

Ot(D2, D3) = btdelete{acc5[balance->5000]}

Ot(D3, D4) = btinsert{acc5[balance->5025)}

Ot(D4, D5) = btdelete{acc3[balance->1175]}

Ot(D5, D6) = btinsert{acc3[balance->675]}

Ot(D6, D7) = btidelete{acc4[balance->10]}

Ot(D7, D8) = btinsert{acc4[balance->510]}

Ot(D0, D2) = {acc3[change_balance(1200, 1175)], acc3[withdraw(25)]}

Ot(D2, D4) = {acc5[change_balance(5000, 5025)], acc5[deposit(25)]}

Ot(D0, D4) = transfer(roger, broker, 0,5 * 500)

Ot(D4, D6) = {acc3[change_balance(1175, 675)] , acc3[withdraw(500)]}

Ot(D6, D8) = {acc4[change_balance(10, 510)], acc4[deposit(500)]}

Ot(D4, D8) = transfer(roger, mary, 500)

Ot(D0, D8 = buy(roger, mary, 500)

outline3
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

modelog s approach

Flora

ATL

MODELOG’s Approach

ATL

Flora

UML

OCL

flora metamodel

<<import>>

<<r&g>>

<<r&g>>

<<r&g>>

<<r&g>>

<<r&g>>

<<r&g>>

<<r&g>>

<<combine>>

<<r&g>>

<<r&g>>

<<import>>

30 packages

200 meta-

classes

<<r&g>>

<<r&g>>

<<combine>>

<<r&g>>

<<import>>

<<import>>

Flora Metamodel
modelog modules
MODELOG Modules

MODELOG

Class Diagram

Transformations

Module

OCL

Transformations

Module

modelog modules1
MODELOG Modules

Class Diagram Transformations Module

Class

Transformations

Module

Attribute

Transformations

Module

Operation

Transformations

Module

Generalization

Transformations

Module

Dependency

Transformations

Module

Realization

Transformations

Module

Association

Transformations

Module

modelog modules2
MODELOG Modules

OCL Transformations Module

Constraint Transformations Module

Invariant

Transformations

Module

Derive

Transformations

Module

Post-Condition

Transformations

Module

Body

Transformations

Module

OCL Expressions Transformations Module

IFExp

Transformations

Module

LiteralExp

Transformations

Module

LetExp

Transformations

Module

VariableExp

Transformations

Module

CallExp

Transformations

Module

class diagrams transformation
Class Diagrams Transformation

1 convexPolygon[].

2 convexPolygon[right *=> void].

3 atomicPolygon[].

4 atomicPolygon::convexPolygon.

5 triangle[].

6 triangle::atomicPolygon.

7 triangle[hypotenuse *=> segmentLine]

8 triangle[side *=>> segmentLine].

9 segmentLine[].

10 segmentLine[length *=> float].

atl transformation
ATL Transformation

1 module ClassTransformations;

2 create OUT : Flora from IN : UMLOCL;

3 rule Class2Flora{

4 from c : UMLOCL!Class

5 using {allStereotypes : Sequence(UMLOCL!Stereotype) = c.stereotype; }

6 to

7 class : Flora!SubClassFAtom( subClass <- subClass),

8 subClass : Flora!Symbol(

9 ground <- true,

10 name <- c.name ),

11 att : Flora!AttributeSignatureSpecification (

12 feature <- umlLabel,

13 host <- hostLabel,

14 inheritable <- true,

15 multiplicity <- Flora!MultiplicityKind::single,

16 type <- typeLabel),

17 umlLabel : Flora!Symbol( name <- 'uml'),

18 hostLabel : Flora!Symbol( name <- c.name),

19 typeLabel : Flora!Symbol(name <- 'umlMeta'),

20 umlClassInstance : Flora!InstanceFAtom (

21 object <- objectLabel,

22 floraClass <- classLabel),

23 objectLabel : Flora!Symbol(name <- thisModule.getOid(c.name, 'umlClass')),

24 classLabel : Flora!Symbol( name <- 'umlClass'),

25 umlMetaInstance : Flora!InstanceFAtom (

26 object <- umlMetaObject,

27 floraClass <- umlMetaClass),

28 umlMetaObject : Flora!Symbol(name <- thisModule.getOid(c.name, 'umlMeta')),

29 umlMetaClass : Flora!Symbol( name <- 'umlMeta'),..

7 class : Flora!SubClassFAtom( subClass <- subClass),

8 subClass : Flora!Symbol(

9 ground <- true,

10 name <- c.name ),

class diagrams transformation1
Class Diagrams Transformation

1 convexPolygon[].

2 convexPolygon[right *=> void].

3 atomicPolygon[].

4 atomicPolygon::convexPolygon.

5 triangle[].

6 triangle::atomicPolygon.

7 triangle[hypotenuse *=> segmentLine]

8 triangle[side *=>> segmentLine].

9 segmentLine[].

10 segmentLine[length *=> float].

atl transformation1
ATL Transformation
  • 1 module AttributeTransformations;
  • 2 create OUT : Flora from IN : UMLOCL; ...
  • 13 rule Attribute2Flora{
  • 14 from
  • 15 a : UMLOCL!Attribute
  • 16 using {
  • 17 Oid_umlAttr : String = thisModule.new('umlAttr'); ...
  • 20 }
  • 21 to
  • 22 att : Flora!AttributeSignatureSpecification (
  • 23 feature <- featureLabel,
  • 24 host <- hostLabel,
  • 25 inheritable <- true,
  • 26 multiplicity <- a.getMultiplicity(),
  • 27 type <- attTypeLabel),
  • 28 featureLabel : Flora!Symbol(name <- a.name),
  • hostLabel : Flora!Symbol(name <- a.owner.name),
  • attTypeLabel : Flora!Symbol(name <- a.type.name)
  • ...
class diagrams transformation2
Class Diagrams Transformation

1 convexPolygon[].

2 convexPolygon[right *=> void].

3 atomicPolygon[].

4 atomicPolygon::convexPolygon.

5 triangle[].

6 triangle::atomicPolygon.

7 triangle[hypotenuse *=> segmentLine]

8 triangle[side *=>> segmentLine].

9 segmentLine[].

10 segmentLine[length *=> float].

invariant transformation
Invariant Transformation

/* OCL invariant specification */

context class inv inv_name:

OCLExp

/* Flora code */

#violated_inv_name(Self) :- Self:class and

naf (OCLExp)

derive transformation
Derive Transformation

/* OCL specification for a derived property of a Class*/

context Class::property : propertyType

derive: OCLExp

/* Flora code */

Self[property *-> Result] :- Self:class and

Result = OCLExp.

pre and post conditions transformation

/* OCL specification of the Class::operation method pre and post-conditions */

context Class::operation(para : paramType) : NonBooleanType

pre: preOCLExp

post: postOCLExp

/* Flora code */

Self[operation(Param) *-> Result] :- Self:class and

preOCLExp and Result = postOCLExp.

Pre and Post-conditions Transformation

/* OCL specification of the Class::operation method pre and post-conditions */

context Class::operation(para : paramType) : boolean

pre: preOCLExp

post: postOCLExp

/* Flora code */

Self[operation(Param)] :- Self:class and preOCLExp and postOCLExp.

callexp transformation
CallExp Transformation

/* OCL implies operation */

a implies b

/* Flora code */

naf(a) or b

outline4
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

case study
Case Study
  • Representative of many classical AI tasks and OO modeling
  • Rich application: structural and behavioral
  • I have created Triangram
    • Table initially composed of atomic triangles
    • Goal: assembly a regular hexagon according to some rules
  • Formed by:
    • UML class diagram containing 27 classes and diver relationships
    • More than 400 lines of OCL code
    • Eight Object diagrams illustrating the tans on the table initial setting
    • More than 1000 lines of Flora code
triangram

tri1 + tri2 = rectangle1

tri2

tri4

tri3

tri1

s11

s21

s21

s21

4

4

4

5

5

5

s42

4

4

s32

4

4

s43

s33

s13

s11

s21

s23

4

5

3

5

3

5

4

3

3

3

3

4

3

3

s22

s22

s22

s12

rectangle1 + tri3 = pentagon1

s41

s31

s22

s12

tri5

tri6

tri7

tri8

s32

4

s11

3

5

3

3

3

3

s51

s52

s61

s62

s71

3

3

s72

s81

3

3

s82

4

4

s33

4

4

3

3

s12

s53

s63

s73

s83

pentagon1 + tri4 = hexagon1

s42

s32

4

4

s11

3

3

5

4

4

4

s43

s33

s12

Triangram
triangram flora code
Triangram Flora code

/* Flora code generated containing the table setting shown in Fig. 5.17 */

1 bot:robot.

2 bot[table->t1].

3 t1:table[tans ->> {tri1, tri2, tri3, tri4, tri5, tri6, tri7, tri8}].

/* Flora code generated from the triangle tri1 shown in Fig. 5.17 */

4 tri1:scaleneTriangle.

5 tri1[right].

6 s11:segmentLine[length -> 3].

7 s12:segmentLine[length -> 4].

8 s13:segmentLine[length -> 5].

9 tri1[side ->> {s11, s12, s13}].

10 tri1[triangleSide ->> {ts11, ts12, ts13}].

11 ts11:triangleSide[triangle->tri1, side->s11, position->left, adjacent->>{ts12, ts13}].

12 ts12:triangleSide[triangle->tri1, side->s12, position->base, adjacent->>{ts11, ts13}].

13 ts13:triangleSide[triangle->tri1, side->s13, position->right, adjacent->>{ts11, ts12}].

14 s11[triangleSide->>ts11].

15 s12[triangleSide->>ts12].

16 s13[triangleSide->>ts13].

triangram flora code1
Triangram Flora Code

/* OCL invariant inv_9 */

context Triangle inv inv_9:

right implies hypotenuse->size() = 1

/* Flora code from inv_9 mapping */

1 #violated_inv9(Self) :- Self:triangle and

2 naf(

3 (naf (Self[right])) or

4 (Col = collectbag{Var | Self[hypotenuse->Var]} and

5 size(Col, 1))

6 ).

/* Flora code from inv_9 mapping */

1 #violated_inv9(Self) :- Self:triangle and

2 naf(

3 (naf (Self[right])) or

4 (Col = collectbag{Var | Self[hypotenuse->Var]} and

5 size(Col, 1))

6 ).

/* Flora code from inv_9 mapping */

1 #violated_inv9(Self) :- Self:triangle and

2 naf(

3 OCLExp

6 ).

/* Flora code generated containing a culprit object*/

1 tri1:scaleneTriangle.

2 tri1[right].

3 s11:segmentLine[length -> 3].

4 s12:segmentLine[length -> 4].

5 s13:segmentLine[length -> 5].

6 tri1[side ->> {s11, s12, s13}].

7 tr1[hypotenuse -> s11].

8 tri1[hypotenuse -> s12].

Flora-2 ?- #violated_inv9(X).

Yes

X = tri1

outline5
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

related works
Related Works
  • Not executable, very strict subset of UML/OCL 1.4
    • [Kyas and Fecher, 04] maps UML/OCL to PVS input language
    • [Beckert et al., 02] maps UML/OCL 1.4 to Dynamic Logic
    • [Oliver, 99] purposes animation for validation
    • [Berardi, 02] maps only UML class diagrams to DLs
    • [Shen et al., 02] maps tor ASM
    • [Lilius and Paltor, 99] maps only UML to PROMELA
    • [Henocque, 04] maps UML/OCL to Z (only OCL invariants)
    • [Roe et al, 03] maps UML/OCL 1.4 to Object-Z
  • Executable, but without a formal semantics
    • [Gray and Schach, 00] maps UML/OCL 1.4 to Prolog++
      • Prolog++ does not have a formal semantics
      • Only for invariants
      • Fully manual
      • Prolog ++ does not support transactions nor meta-programming
related works1
Related Works
  • [Marcano and Levy, 02] and [Ledang and Souquières, 02] map UML/OCL to B (following a MDE approach)
    • Contemplates OCL 1.4
    • OCL metamodel pursued is not that provided by the OMG
    • Transformations expressed in T
    • B is no object-oriented
    • B does not support transactional operations
    • B does not support meta-programming
    • The Theorem-prover ATELIER B proves automatically about 70% of proof obligations
related works2
Related Works
  • Semantic Web Service
    • [Baclawski et al., 01] and [Cranefield, 01] maps UML to RDF abd DAML-OIL, respectively
    • Only structural constraints
    • Generating only ontologies (Not Semantic Web Services)
modelog1

MoDELS

2005

Model-Driven

Engineering

Formal

Development

and model-checking

OCL Mini-course in WMF 2003

  • Automatic generation of complete structural and behavioral code
  • Real-size example fully adopting a MDE approach

WisME-MODELS

2004

  • Integrated semantics for
  • UML and OCL
  • Verification of executable
  • formal model

WMF and ENTCS 2003

WIRE Talk

Semantic Web

Service

Development

Agent Oriented

Engineering

  • combine strengths of AOextensions of OO andLogic/Formal methods
  • Automatic code generation
  • of OO Logic agents
  • SWS representation
  • and reasoning

Agile Development

  • Fast prototyping
  • Automatic structural and
  • behavioral code generation

SBLP and JUCS

2003

MODELOG

MODELOG through UML-OCL to

Flora mapping

outline6
Outline

1Introduction and Motivation

2 MDE and OMG Languages

3 OOLP

4 MODELOG

5 Case Study

6 Related Works

7 Conclusions

limitations
Limitations
  • Transformation definitions concerning OCL are not complete
  • Transformations are not completely implemented
  • Class diagram module does not cover active classes
  • Flora metamodel does not cover all extra logical predicates
  • Incomplete OCL specification of Flora metamodel
  • EMF objects are generated instead of full textual Flora code
future work
Future Work
  • MODELOG as QVT or ATL transformation engine
  • MODELOG as KobrA model checking engine
  • MODELOG as Semantic Web Ontology and agent CASE tool
  • Using metamodels for specifying and integrating formal semantics
  • Proving conformance of the generated Flora code and the forthcoming UML and OCL formal semantics
  • Extending MODELOG to cover other UML diagrams
  • Specify Object diagram transformations