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
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 http://www.omg.org/mda
5 Widening scope The Challenge of Enterprise Java (.NET, z/OS…) Number of pages in specification
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
7 Models, Metamodels, and the Platform Stack Standards: - UML - standardized UML profiles - XMI - Progr. Languages Standard: - MOF Standards: - CORBA - J2EE -.NET - Linux - Windows
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 Formal: Mapping Techniques for Representations Example: UML Profile
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 ^
12 Annotations for Specific Mapping Techniques Example: Record of the transformation
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?
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 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.
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.
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?
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
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)
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)
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
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
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
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 iterator.py 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
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
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 Cartridge Configuration Specify base cartridge(s) Set root generatable ( >) Associate utility class
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
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
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
35 Example: Adding an Artifact to Java2 Cartridge
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%)
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
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)?
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
Your consent to our cookies if you continue to use this website.