T ony Clark Kings College London, UK – anclark@dcs.kcl.ac.uk

1. Realising MDA –a Precise Metamodeling Approach Tony ClarkKings College London, UK – anclark@dcs.kcl.ac.uk Andy EvansUniversity of York, UK – andye@cs.york.ac.uk Stuart KentUniversity of Kent at Canterbury, UK – sjhk@ukc.ac.uk September 2001 precise UML (pUML) group www.puml.org AcknowledgementsSteve Cook,Desmond D’Souza, Steve Mellor

2. Outline • MDA • Modeling space • Metamodeling space • Language engineering – precise meta-modeling approach • Three principles and techniques • Excerpts from the 2U submission • Tools • Tool demonstration • Future developments • Transformations • Importance of transformations • The relation template • Example mappings • Conclusions & Discussion

3. MDA – modeling space 1

4. currentpractice Architecture, patterns, templates paperware MDA – platform independence Technology independent Domain expert oriented business model supporting systems Involves a range of technologies Intermixed with manual processes Business processes and rules scattered and implicit

5. futurepractice Architecture, patterns, templates precise models,templates &patterns tools chain code/test generation traceability management MDA – platform independence Technology independent Domain expert oriented business model supporting systems Involves a range of technologies Intermixed with manual processes Business processes and rules scattered and implicit

6. Platform 1 Platform 2 UML Spec Model UML Impl Model Platform 3 = translation UML Spec Model UML Impl Model = extension = refinement TESTS ? javacompilationscript .java(withembeddedsql) javainterface to legacy wrapper .jsp dbset up .php .html cgiscript MDA scenario – b2c

7. MDA – modeling space 2

8. Compose generated and non-generated models Build consistently architected systems from components Specialize and Configure Generate plug-ins, bridges, adaptors Connect together Consumption (consumable, …) Futures Trading (commodity, payment) generate: electricity, water futures electricity, water futures compose with … MDA – Model Separation and Composition • Precise templates of domains and business processes • Futures Trading – orange juice, pork bellies, … electricity, drinking water? • Consumption – auto parts, … orange juice, pork bellies, … electricity, drinking water? • Generate models from templates specialized with domain specifics • Futures Trading [ electricity / commodity, drinking water futures / payment ] • Consumption [ futures electricity purchase / consumable ] Example inspired by Kevin Tyson

9. MDA – modeling space 3

10. MDA – Need for tools • Problems with modeling on an industrial scale: • tests/inspections/proofs of large models? • validation… do the models support the business well? • code & test generation to different platforms? • A lesson from eXtreme programming (XP) • forget paperware… focus only on stuff that executes • (automated) testing • refactoring • responsive to change • XP works on homogeneous systems • written in one language & environment • MDA abstracts from heterogeneous environment to homogeneous environment • abstractions are closer to business model • tools required to move X practices to MDA

11. MDA – metamodeling space 1

12. MDA – metamodeling space 2

13. Instance Specification Instances Namespaces generate: , class, attribute object, slot class attrib object slot Classes MDA – Defining a Family of Languages • Precise templates for the domains of language definition • Concrete notation • Abstract syntax • Instances • Mappings between these • Generate models of languages (or fragments) from these templates • Classes, attributes • Objects, slots • Compose fragments compose with … • Build consistently architected language family • Even including relationships across languages

14. MDA – metamodeling space 3

15. specifications instancesfilmstrips traces language 4 defininglanguages languagedefinitions PSMs programs PIMs UML models all the time hardly ever Rate of change • Tools that support exploration of specifications through instances • Permits automated testing of specs (programs or models) • A tool implementing a language 4 defining languages can be used to generate tools to support particular languages

16. Metatools • Don’t live in a world of fixed languages • different domains use different modeling patterns (architectures) • some can be captured by templates, others need domain specific languages (DSLs) • But, if modeling is to be used in anger we need tools • tools need to be modeling language specific (both PS and PI) • main ‘brake’ is time-to-market of tools • Metatools generate tools from language definitions • through interpretation or compilation • still a long way to go • Metatools would admit opportunistic invention of DSLs • opportunistic identification and definition of patterns • more powerful than templates

17. Example metatools • MOF – www.omg.org • MetaEdit+ – www.metacase.com • Dome – www.htc.honeywell.com/dome/ • XML – www.w3c.org • PROGRESS – graph grammars • MMT

18. Outline • MDA • Modeling space • Metamodeling space • Language engineering – precise meta-modeling approach • Three principles and techniques • Excerpts from the 2U submission • Tools • Tool demonstration • Future developments • Transformations • Importance of transformations • The relation template • Example mappings • Conclusions & Discussion

19. Consistent Core Three Principles Generative Architecture • ensures consistency • avoids duplication • easily re-factored Layered Definitions • pluggable definitions • extensible definitions • composition avoids errors Unambiguous Language • verifiable models • translatable models • richer tool support

20. Consistent Core Three Techniques Package Templates • ensures consistency • avoids duplication • easily re-factored Package Generalization • pluggable definitions • extensible definitions • composition avoids errors Instance Constraints • verifiable models • translatable models • richer tool support

21. Apply Template

22. Merge Templates

23. Package Generalization

24. class A extends B { int I; m () { …. } } Instance/Example: rules about valid instances Language Element Specification: rules about well-formed expressions Structured Language Definition: Java • every instance of A will … • when class A is loaded, a new class object … • class needs valid identifier name, can extend 0..1 class, has instance variables … T x = new A(p); • matching constructor available, return value type T match • new instance of A created and variable x is bound to it

25. Dog Name Breed Weight Structured Language Definition: UML Language Element Specification: rules about well formed models Instance/(Counter)Example • every object of class Dog has slots name, breed, weight • every slot has a value of the type of the corresponding attribute • Class contains attributes; Attributes have distinct names • Attributes are in middle compartment Dog Name Breed Weight Owner • Each binary association links two classes. Each association has a multiplicity string… • Association is drawn as a line joining classes • An instance of the association (a link) links a specific instance of Dog, Sarzak, to a specific instance of owner, Sally • The “dog owner” John owns no dogs • Every valid example … 1 .. * 1 Dog Owner Name Address {Dogs} A counter-example discovered during instance modeling

26. Concrete syntax to / from abstract syntax • Java: strings to tokens to abstract syntax trees • UML: boxes to classes, lines to associations, … • How abstract syntax constrains instances • Java: instantiation, binding, execution • UML: instantiation, deletion, query, computation To Define a Language … • Specification: abstract syntax for expressions • Java: class, variable, statements, constructors, … • UML: Class, Attribute, Association • Notation: concrete syntax for expressions • Java: strings, parentheses, … • UML: boxes, lines, text strings • Instances that are described by expressions • Java:objects, method invocations, threads, … • UML: Objects, Slots, Links

27. Cover All 4 Aspects Of Language Definition • From the RFP… • “Proposals shall enforce a clear separation of concerns between the specification of the metamodel semantics and notation, including precise bi-directional mappings between them.” • “Proposals should stipulate the mechanisms by which compliance to the specification will be determined…” • MDA requires that PSM implementations be testable against PIM specs • Need to know what a PIM specifies about instance behavior • (Plus the relation between PIM instances (data types, exceptions, slots) and PSM ones) • We want tools that do much more than in the recent past • Instance level exploration is key to understanding, debugging, testing, …

28. Federated tools: integration, interoperability Architecture of language = architecture of tools Body of examples & counter examples – tests specification instance textgenerator textparser texttools instancechecker concepts xmltools xmltools concepts instancegenerator visualiser diagrameditor Translator, Traceability manager repositorymanagement layoutengine specification versioncontrol

29. 2U Submission Architecture Note: Picture in initial submission document is incomplete

30. Compare with… …current architecture of UML / MOF UML 1.x “physical meta-model” UML 1.x (concepts) maps extends UML core instantiates CWM uses subsets/extends uses MOF OCL XMI, IDL defines Profile adapted from a slide by Steve Cook

31. Separation of concerns

32. Package UML2.StaticCore: focus on Classes

33. Portion of UML2 Template Library

34. Generate StaticCore.Classes from Templates: 1

35. A container whose contents are calculated from locally introduced contents and from its parents’ contents and which applies the namespace pattern Instances of a generalisable element can be viewed as different types Instances of any container will contain instances of the container’s contents Easy step to rule on naming: <X> , <X>Instance

36. If • elements E1 and E2 are related by name1 • and each element is generalizable Then • each E1’s parents must be related (name1) to theparents of its corresponding E2s • E1’s instances must be related (name2) to the parentsof the corresponding (name2) E2’s instances • E1’s instances can be viewed as of type E1 or of type any of E1’s transitive parents • Similarly for E2 See Template 4.16 for full model Generating StaticCore.Classes from Templates: 2

37. Generated StaticCore.Classes: 1 of 3 • Class has namespace for its attributes (alternative: parametric inheritance) • Classes are generalizable (have parents) • Attributes are generalizable (have parents) • All OCL constraints and query expressions generated as well

38. Generated StaticCore.Classes: 2 of 3 • Objects have slots, whose values are objects • Since Classes are generalizable, objects can be viewed as being of different classes (parents link) • Note: In document, “Object” might be better named “ObjectView”; and ID might be better named “Object” • Since Attributes are generalizable, slots can be viewed as being of different attributes

39. Generated StaticCore.Classes: 3 of 3 • Instance constraints between objects/slots and classes/attributes • Associations generated • OCL constraints generated

40. Result of Our Approach • Consistent structure, constraints, names introduced at will • Architectural integrity maintained through all lower templates • Consistency assured in every end-model template application • Consistency assured across languages and profiles, across concrete syntax, abstract syntax, and instance domains • Changes made in just on place • Final submission will develop ContainerMap branch: basis for 1st class MDA support

41. More on templates from submission

42. Outline • MDA • Modeling space • Metamodeling space • Language engineering – precise meta-modeling approach • Three principles and techniques • Excerpts from the 2U submission • Tools • Tool demonstration • Future developments • Transformations • Importance of transformations • The relation template • Example mappings • Conclusions & Discussion

43. Slides for tool demo

44. Outline • MDA • Modeling space • Metamodeling space • Language engineering – precise meta-modeling approach • Three principles and techniques • Excerpts from the 2U submission • Tools • Tool demonstration • Future developments • Transformations • Importance of transformations • The relation template • Example mappings • Conclusions & Discussion

45. Transformations Everywhere! • Language definition • Between languages • Business models to PIMs • PIMs to PSMs • Between models in the same language • Refinement

46. context <X>Rel<Y> inv:image()=pairs.<y>_r->asSet inverseImage()=pairs.<x>_d->asSet isFunctional()=pairs->forAll(p,q| p.<x>_d=q.<x>_d implies p=q) isInverseFunctional()= pairs->forAll(p,q | p.<y>_r =q.<y>_r implies p=q) isInjection()=isFunctional and isInverseFunctional isOnto()=(image=ran) isTotal()=(inverseImage=dom) isBijection()=isInjection() and isOnto() and isTotal() lookup(x)=pairs->select(p|p.<x>_d=x) lookup(y)=pairs->select(p|p.<y>_r=y) Relation template

47. Semantics

48. Example PIM to PSM

49. Refinement • Car hire example (rental action) • Consider mapping of dynamic behaviour

50. Outline • MDA • Modeling space • Metamodeling space • Language engineering – precise meta-modeling approach • Three principles and techniques • Excerpts from the 2U submission • Tools • Tool demonstration • Future developments • Transformations • Importance of transformations • The relation template • Example mappings • Conclusions & Discussion