Presentation is loading. Please wait.

Presentation is loading. Please wait.

THE IT-ARCHITECTURE PROFESSIONALS MDA Discussion Overview Axel Uhl © Interactive Objects Software –

Similar presentations

Presentation on theme: "THE IT-ARCHITECTURE PROFESSIONALS MDA Discussion Overview Axel Uhl © Interactive Objects Software –"— Presentation transcript:


2 THE IT-ARCHITECTURE PROFESSIONALS MDA Discussion Overview Axel Uhl © Interactive Objects Software –

3 2 Agenda Motivation for MDA Terminology: Models, Metamodels, Representations, Mappings, Platforms, PIM/PSM, Annotations (and Related Standards / Technologies) Model Transformations and Annotations: Facts and Visions (and Related Standards / Technologies) Specifying / Implementing Standardization Efforts MDA Process Shaping and executing an MDA Instance

4 3 References ormsc/01-07-01 (previous ormsc guide) ormsc/02-04-02 (latest ormsc guide) ormsc/02-01-04 (Interactive Objects Position Paper) MOF 2.0 Queries / Views / Transformations RFP Other papers from

5 4 a.k.a. The MDA Phase Diagram. From iOs OMG MDA submission Dec. 2001 Change Platforms 2 & 1 Rework effort w/ high-end Architectural IDE P-stack 4P-stack 3P-stack 2P-stack 1 Manual Rework Lines Content Level (extent of convergent metamorphosis) Complete Systems Whiteboard Sketches MDA automation lines PIM -> PSM P-stacks Deployable Infrastructure on Target Platform, Completely Specified. Effective representation (modeling styles) and automation begins in higher P-stacks: Effective representation and automation begins at lower P-stacks. Rework effort w/o high-end Architectural IDE $ ROI with each and every change! MDA and the Architectural IDE: High ROI © 2002, Interactive Objects GmbH

6 5 Widening scope The Challenge of Enterprise Java (.NET, z/OS…) Number of pages in specification

7 6 Takes the path of lowest effort & risk each time Detailing at low abstraction level causes extra effort and errors. Example: Associations between EJB components Metamodels / P-Stacks Content Level

8 7 Models, Metamodels, and the Platform Stack Standards: - UML - standardized UML profiles - XMI - Progr. Languages Standard: - MOF Standards: - CORBA - J2EE -.NET - Linux - Windows

9 8 The Heart of MDA: Mapping Models Specification / implementation getting standardized by MOF 2.0 Query / View / Transformation RFP. Implementation also called " Cartridge ". terminology: mapping = transformation ^ Multiple mappings may be applied successively in a chain

10 9 Representing Models: Some Examples programmatically accessible representation editable metamodels UML textual notation syntax UML textual notation syntax UML Profile for JSR 26 UML Profile for "EJB Compact Bean" Java Syntax EJB Compact Bean EJB Expanded Bean (JSR 26) UML ASCII UML ASCII UML Graphical Notation Java Abstract Syntax Tree UML Graphical Notation

11 10 Formal: Mapping Techniques for Representations Example: UML Profile

12 11 Keeping The Model Platform-Independent Unannotated PIM annotations for platform A annotations for platform B annotations for platform A annotations for platform B annotations for platform A annotations for platform B Unannotated PSM Platform A Unannotated PSM Platform B terminology: annotation = marking ^

13 12 Annotations for Specific Mapping Techniques Example: Record of the transformation

14 13 Abstraction or Refinement? Mapping techniques sometimes intuitively seem to implement an abstraction, leading to more abstract metamodels, or a refinement, leading to more detailed metamodels, between two metamodels. Consequently, the one metamodel is sometimes called an abstraction or a refinement of the other What does this mean formally? When do we call a mapping technique a "refining" one? When do we call it an "abstracting" one?

15 14 Formal Definition: Refinement Let A and B be two metamodels B is said to be a refinement of A if a "reasonable" (semantic-preserving) surjective mapping technique (or mapping in the algebraic sense) from A to B cannot be provided.

16 15 Refining Mappings Visualized

17 16 Formal Definition: Abstraction Let A and B be two metamodels B is said to be an abstraction of A if a "reasonable" (semantic-preserving) surjective and non-injective mapping technique (or mapping in the algebraic sense) from A to B can be provided. Non-injectiveness implies that a mapping technique exists that maps at least two instances of A to the same instance of B.

18 17 Abstraction and Refinement: Conclusions There may be mapping techniques which are formally neither an abstraction nor a refinement. Example: Java C++ transformation Formalizing the terms is possible but doesn't really help. An intuitive use aligned along the particular MDA instance and its goals seems most appropriate.

19 18 PIM and PSM: The Endless Debate PIM: Platform Independent Model What is a platform ? Is a (vertical) domain a platform? Do platforms have to be executable ? What platform(s) is a PIM independent of? How can you call a PIM "platform independent" if it eventually needs one to run on? PSM: Platform Specific Model What platform(s) is a PSM specific to? Can a PSM be PIM with regard to other platforms?

20 19 PIM and PSM: Resolving the Dispute A model can be PIM and PSM at the same time. PIM and PSM are roles a model can assume with regard to a specific (set of) platform(s). Platforms can be seen as specific domains Example: A Java program is a PIM with regard to the operating system platforms that Java runs on. A Java program is a PSM with regard to the programming language and API platform (the JDK) JDK / JVM SolarisLinuxWindows Java Program PSM PIM

21 20 Model Transformations: Facts and Visions MOF as basis for metamodels becomes common. Exception: ASCII-based target "metamodels". Specification of transformations varies ASCII-based target metamodels templates mixed with scripting (akin to JSP approach) UML-based (ArcStyler / CARAT) XML / XSLT hard-wired mostly irreversible (often not possibly without ambiguities) MOF-based target metamodels rules-based hard-wired sometimes reversible (when unambiguously possible)

22 21 Transform. Spec.: Requirements and Criteria (partly taken from MOF 2.0 Queries, Views, and Transformations RFP, and from ormsc/02-04-02): reusability extensibility scalability (for large metamodels) handling complexity efficiency (for large models) incremental applicability (transforming changes only) reversibility (where possible)

23 22 MDA Process [ Instantiating the MDA ] 1 Identify the set of target platforms 2 Identify the metamodels you want to use 3 Define the mapping techniques between the metamodels 4 Define the annotation models required by the previously defined mapping techniques 5 Implement the mapping techniques

24 23 MDA Process (cont'd) [ Executing the MDA Instance ] 6 Conduct the iterations of the project 6.1 Add/edit detail in one or more of the mapping's source models 6.2 Add/edit contents of the mapping-specific annotations to one or more of the mapping's source models 6.3Verify the model for mappability 6.4 Perform the mapping, which results in a new or changed target model These three steps can be repeated iteratively / incrementally

25 24 Example: Cartridge Development at iO three years of profound, hands-on experience projects and product (ArcStyler) from CRC cards via UML to J2EE technologies, CORBA, host-based environments (COBOL, XML adapters,...) went through three generations of cartridge architectures productized cartridge extensibility since ArcStyler 1.0 customers using it in real-world projects But: Still some issues to be solved

26 25 Cartridge Architecture History at iO ArcStyler 1.x w/ CARAT 0.0 template files weaving in JPython script parts with plain text large "flat" JPython function libraries with little structure master.tpl and controlled generation process Pros: templates correspond closely with output Cons: little reuse within single cartridge even less reuse across cartridges hard to extend "design" not scalable for more complex cartridges

27 26 Cartridge Architecture History at iO ArcStyler 2.x w/ CARAT 1.0 using OO to structure cartridges into classes and objects inheritance possible between whole cartridges complete re-write of cartridges, beginning with IAS/BAS Pros: significantly increased reuse within and across cartridges improved design, geared towards extensibility Cons: generated output harder to recognize in templates tricky wiring of cartridge elements (who triggers what,...) hard to get a grip on how the pieces work together

28 27 Cartridge Architecture History at iO ArcStyler 3.x w/ CARAT 2.0 cartridges modeled using CARAT-specific meta-model with corresponding UML profile generate cartridge impl. using CARAT cartridge, fill in PAs Pros: practice what you preach: reaps MDA benefits for cartridge devel. comparatively easy visual configuration of cartridges scales up to very complex cartridges eased extensibility improved integration into ArcStyler due to consistent cartridges: selective artifact generation, progress indication cartridge profiling and improved precompilation

29 28 Generating Cartridges with a Cartridge

30 29 Cartridge Configuration Specify base cartridge(s) Set root generatable ( >) Associate utility class

31 30 Model - Artifact Relationship What we have UML business model representing some functionality What we want (for model to code transformations) Physical artifacts executing this functionality within an IT infrastructure, e.g. Java classes in a JVM

32 31 Grouping Artifacts into Sets

33 32 Defining Extension Points: Artifact Sections Modeled artifacts can define fine-grained artifact sections

34 33 Representing the Source Metamodel Blueprints correspond with metamodel elements (Class, Attribute, Operation, AssociationEnd,...) Blueprint inheritance mimics metamodel inheritance Reuse of whole inheritance subtrees by registries

35 34 Model - Artifact Relationship This is "where the rubber hits the road" Blueprints know the representation of "their" metamodel elements in the contexts they are registered with Use "protected areas" in places where refinements may be applied to results

36 35 Example: Adding an Artifact to Java2 Cartridge

37 36 Example (cont'd)

38 37 Cartridges Developed with this Approach at iO >30MB UML cartridge models ~1700 classes with multiple rules each ~6700 rule connections (as UML associations) ~22MB Jython sources generated, 1.5MB of them manually refined (<7%)

39 38 Caveats: MOF Q/V/T Still at the Very Beginning MDA tools are now ready for prime-time. We should apply them in order to not to abstract from 0 to n, standardizing prematurely make sure a standard is built on solid, profound experience from real-world projects allow for diversity of approaches before validation and consolidation takes place

40 39 Open Issues Regarding Transformations How can manual refinements in non-ASCII target models be supported? "Protected Areas" defined on MOF-specified metamodels techniques to detect manual refinements in such areas How to reverse-enable transformation fan-out? How to combine reversibility with extensibility? How do different approaches handle large-scale transformations? How to derive an implementation from the specification (we can do ~93% for model-to-code today)?

41 40 Outlook Development and standardization of domain- / platform- specific metamodels, using MOF Development and standardization of mapping techniques (transformations) between them, using MOF 2.0 Q/V/T

42 THE IT-ARCHITECTURE PROFESSIONALS Interactive Objects Software GmbH Basler Strasse 65 79100 Freiburg, Germany Tel. [+49] 761 / 4 00 73 - 0 Fax [+49] 761 / 4 00 73 – 73 MDA Discussion Overview June 26, 2002 OMG_Orlando.ppt

Download ppt "THE IT-ARCHITECTURE PROFESSIONALS MDA Discussion Overview Axel Uhl © Interactive Objects Software –"

Similar presentations

Ads by Google