Downloaded 17 times
![MDA – Model Separation and Composition Compose generated and non-generated models Build consistently architected systems from components Specialize and Configure Generate plug-ins, bridges, adaptors Connect together Example inspired by Kevin Tyson 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 ] Futures Trading (commodity, payment) Consumption (consumable, …) generate: electricity, water futures electricity, water futures compose with …](https://image.slidesharecdn.com/uml01-110806063339-phpapp02/85/UML01-8-320.jpg)
![MDA – Model Separation and Composition Compose generated and non-generated models Build consistently architected systems from components Specialize and Configure Generate plug-ins, bridges, adaptors Connect together Example inspired by Kevin Tyson 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 ] Futures Trading (commodity, payment) Consumption (consumable, …) generate: electricity, water futures electricity, water futures compose with …](https://image.slidesharecdn.com/uml01-110806063339-phpapp02/75/UML01-8-2048.jpg)
More Related Content
UML01
- 1. Tony Clark KingsCollege London, UK – anclark@dcs.kcl.ac.uk Andy Evans University of York, UK – andye@cs.york.ac.uk Stuart Kent University of Kent at Canterbury, UK – sjhk@ukc.ac.uk September 2001 precise UML (pUML) group www. puml .org Realising MDA – a Precise Metamodeling Approach Acknowledgements Steve Cook, Desmond D’Souza, Steve Mellor
- 2. Outline MDA Modelingspace 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 – modelingspace 1
- 4. MDA – platformindependence business model supporting systems Technology independent Domain expert oriented Involves a range of technologies Intermixed with manual processes Business processes and rules scattered and implicit Architecture, patterns, templates current practice paperware
- 5. MDA – platformindependence business model supporting systems Technology independent Domain expert oriented Involves a range of technologies Intermixed with manual processes Business processes and rules scattered and implicit Architecture, patterns, templates future practice precise models, templates & patterns code/test generation traceability management tools chain
- 6. MDA scenario –b2c TESTS ? UML Spec Model UML Impl Model db set up .html cgi script Platform 1 .php Platform 2 UML Spec Model UML Impl Model = extension = refinement Platform 3 .jsp .java (with embedded sql) java compilation script java interface to legacy wrapper = translation
- 7. MDA – modelingspace 2
- 8. MDA – ModelSeparation and Composition Compose generated and non-generated models Build consistently architected systems from components Specialize and Configure Generate plug-ins, bridges, adaptors Connect together Example inspired by Kevin Tyson 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 ] Futures Trading (commodity, payment) Consumption (consumable, …) generate: electricity, water futures electricity, water futures compose with …
- 9. MDA – modelingspace 3
- 10. MDA – Needfor 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 – meta modeling space 1
- 12. MDA – meta modeling space 2
- 13. MDA – Defininga Family of Languages Precise templates for the domains of language definition Concrete notation Abstract syntax Instances Mappings between these compose with … Generate models of languages (or fragments) from these templates Classes, attributes Objects, slots Compose fragments Build consistently architected language family Even including relationships across languages Classes Specification Instances Namespaces Instance class attrib object slot generate: , class, attribute object, slot
- 14. MDA – meta modeling space 3
- 15. Rate of changeTools 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 all the time hardly ever instances filmstrips traces language 4 defining languages specifications PIMs UML models PSMs programs language definitions
- 16. Metatools Don’t livein 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 Modelingspace 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. Three Principles GenerativeArchitecture ensures consistency avoids duplication easily re-factored Unambiguous Language verifiable models translatable models richer tool support Layered Definitions pluggable definitions extensible definitions composition avoids errors Consistent Core
- 20. Three Techniques PackageTemplates ensures consistency avoids duplication easily re-factored Instance Constraints verifiable models translatable models richer tool support Package Generalization pluggable definitions extensible definitions composition avoids errors Consistent Core
- 21.
- 22.
- 23.
- 24. Structured Language Definition:Java class A extends B { int I; m () { …. } } every instance of A will … when class A is loaded, a new class object … 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 class needs valid identifier name, can extend 0..1 class, has instance variables … Specification: rules about well-formed expressions Instance/Example: rules about valid instances Language Element
- 25. Structured Language Definition:UML every object of class Dog has slots name, breed, weight every slot has a value of the type of the corresponding attribute 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 … Specification: rules about well formed models Instance/(Counter)Example Language Element Dog Name Breed Weight Owner Dog Owner Name Address {Dogs} 1 1 .. * A counter-example discovered during instance modeling Class contains attributes; Attributes have distinct names Attributes are in middle compartment Dog Name Breed Weight
- 26. To Define aLanguage … 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 How abstract syntax constrains instances Java: instantiation, binding, execution UML: instantiation, deletion, query, computation Concrete syntax to / from abstract syntax Java: strings to tokens to abstract syntax trees UML: boxes to classes, lines to associations, …
- 27. Cover All 4Aspects 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 specification concepts instance visualiser text tools instance checker instance generator diagram editor xml tools text parser text generator xml tools repository management version control concepts layout engine Body of examples & counter examples – tests specification Translator, Traceability manager
- 29. 2U Submission ArchitectureNote: Picture in initial submission document is incomplete
- 30. Compare with… …current architecture of UML / MOF UML 1.x (concepts) UML core UML 1.x “ physical meta-model” MOF CWM maps extends OCL instantiates uses uses XMI, IDL defines Profile adapted from a slide by Steve Cook subsets/ extend s
- 31.
- 32. Package UML2.StaticCore: focuson Classes
- 33. Portion of UML2Template Library
- 34. Generate StaticCore.Classes fromTemplates: 1
- 35. Easy step to rule on naming: <X> , <X>Instance Instances of a generalisable element can be viewed as different types Instances of any container will contain instances of the container’s contents A container whose contents are calculated from locally introduced contents and from its parents’ contents and which applies the namespace pattern
- 36. Generating StaticCore.Classes fromTemplates: 2 If elements E1 and E2 are related by name1 and each element is generalizable Then each E1’s parents must be related (name1) to the parents of its corresponding E2s E1’s instances must be related (name2) to the parents of 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
- 37. Generated StaticCore.Classes: 1of 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: 2of 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: 3of 3 Instance constraints between objects/slots and classes/attributes Associations generated OCL constraints generated
- 40. Result of OurApproach 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 1 st class MDA support
- 41. More on templatesfrom submission
- 42. Outline MDA Modelingspace 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 tooldemo
- 44. Outline MDA Modelingspace 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! Languagedefinition Between languages Business models to PIMs PIMs to PSMs Between models in the same language Refinement
- 46. Relation template 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)
- 47.
- 48.
- 49. Refinement Car hireexample (rental action) Consider mapping of dynamic behaviour
- 50. Outline MDA Modelingspace 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
- 51. Conclusions MDA needslanguages in families education and training tooling MDA needs advanced tools to explore models by example to check well-formedness to automate and track model transformations MDA applied at the metamodeling level could deliver technology to generate tools from definitions MDA needs an approach to metamodeling which delivers complete consistently architected unambiguous and machine processable definitions of language families Transformations are critical candidate for first class language support
- 52. Discussion If MDAis realised, what impact will it have? On people analysts, designers, engineers, programmers, … On solutions for customers quality, costs, time-to-deployment, ongoing evolution, … On margins for solution providers productivity, tools, … Are there other (non-technical?) things we should be doing that would have greater impact?
Editor's Notes
- #18 Do demo of MMT here: just run check of MMF against itself
- #20 No method can really be coherent with some underlying principles that it (or its creators) hold dear. In Catalysis, these principles are: Abstraction: It is overwhelming to deal with the complexity of a software system at the level of code. Abstract models of that code let us separately describe its functional behavior, its relationship to the problem domain, its performance characteristics, the architecture it uses, etc. Any piece of source code will have been written to satisfy a combination of requirements imposed from each of these different points of view, each describing a different aspect of the problem. Examples of common abstractions are interfaces (which hide information about implementation ), and architectural patterns (which hide details of usages of those patterns in different domains). Precision: Abstract descriptions, unfortunately, have a history of being extremely fuzzy and poorly defined. As a consequence, a very elegantly laid out drawing of boxes which claims to describe the system architecture may not have sufficiently precise meaning to show that a particular implementation either does or does not conform to that architecture. Abstraction does not require loss of precision -- provided the appropriate tools and constructs are used. Abstraction with precision lets us work at different levels of detail with some confidence that the abstractions are accurate representations of the eventual implementation. Note, however, that precision must have its rightful place. There is always need for creativity, and formalism is not always appropriate. Different projects and development staff also justify different degrees of precision. Pluggable parts: All development work should be done by (a) adapting and assembling existing parts, be they implementation code, requirements specs, or design patterns, or (b) disassembling existing design to re-factor out more abstract parts from it. These three principles support each other in very powerful ways, yielding: robust, reliable abstractions; reuse at all levels from code to business models; and reliable composition and plugging together at all levels.
- #21 No method can really be coherent with some underlying principles that it (or its creators) hold dear. In Catalysis, these principles are: Abstraction: It is overwhelming to deal with the complexity of a software system at the level of code. Abstract models of that code let us separately describe its functional behavior, its relationship to the problem domain, its performance characteristics, the architecture it uses, etc. Any piece of source code will have been written to satisfy a combination of requirements imposed from each of these different points of view, each describing a different aspect of the problem. Examples of common abstractions are interfaces (which hide information about implementation ), and architectural patterns (which hide details of usages of those patterns in different domains). Precision: Abstract descriptions, unfortunately, have a history of being extremely fuzzy and poorly defined. As a consequence, a very elegantly laid out drawing of boxes which claims to describe the system architecture may not have sufficiently precise meaning to show that a particular implementation either does or does not conform to that architecture. Abstraction does not require loss of precision -- provided the appropriate tools and constructs are used. Abstraction with precision lets us work at different levels of detail with some confidence that the abstractions are accurate representations of the eventual implementation. Note, however, that precision must have its rightful place. There is always need for creativity, and formalism is not always appropriate. Different projects and development staff also justify different degrees of precision. Pluggable parts: All development work should be done by (a) adapting and assembling existing parts, be they implementation code, requirements specs, or design patterns, or (b) disassembling existing design to re-factor out more abstract parts from it. These three principles support each other in very powerful ways, yielding: robust, reliable abstractions; reuse at all levels from code to business models; and reliable composition and plugging together at all levels.