1 / 47

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. 1 Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study

truly
Download Presentation

MODELOG – Model-Oriented Development with Executable Logical Object Generation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MODELOG – Model-Oriented Development with Executable Logical Object Generation Franklin Ramalho Universidade Federal de Pernambuco PhD candidate Jacques Robin Advisor ORCAS Group

  2. Outline 1 Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  3. 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

  4. 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

  5. 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

  6. 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

  7. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  14. - 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

  15. 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).

  16. 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

  17. 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]} …

  18. 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)

  19. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  20. Flora ATL MODELOG’s Approach ATL Flora UML OCL

  21. <<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

  22. MODELOG Modules MODELOG Class Diagram Transformations Module OCL Transformations Module

  23. 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

  24. 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

  25. 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].

  26. 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 ),

  27. 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].

  28. 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) • ...

  29. 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].

  30. Invariant Transformation /* OCL invariant specification */ context class inv inv_name: OCLExp /* Flora code */ #violated_inv_name(Self) :- Self:class and naf (OCLExp)

  31. 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.

  32. /* 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.

  33. CallExp Transformation /* OCL implies operation */ a implies b /* Flora code */ naf(a) or b

  34. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  35. 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

  36. 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

  37. 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].

  38. 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

  39. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  40. 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

  41. 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

  42. 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)

  43. 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

  44. Outline 1Introduction and Motivation 2 MDE and OMG Languages 3 OOLP 4 MODELOG 5 Case Study 6 Related Works 7 Conclusions

  45. 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

  46. 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

More Related