1 / 90

MDA Praktisch Modellbasierte Java Entwicklung Markus Völter voelter@acm voelter.de

MDA Praktisch Modellbasierte Java Entwicklung Markus Völter voelter@acm.org www.voelter.de. Table of Contents. MDA/D Introduction and Overview Metamodelling Example Metamodel Implementing the metamodel Generating Code The future: Model Transformations Summary. Table of Contents.

baakir
Télécharger la présentation

MDA Praktisch Modellbasierte Java Entwicklung Markus Völter voelter@acm voelter.de

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. MDA Praktisch Modellbasierte Java Entwicklung Markus Völtervoelter@acm.orgwww.voelter.de

  2. Table of Contents • MDA/D Introduction and Overview • Metamodelling • Example • Metamodel • Implementing the metamodel • Generating Code • The future: Model Transformations • Summary

  3. Table of Contents • MDA/D Introduction and Overview • Metamodelling • Example • Metamodel • Implementing the metamodel • Generating Code • The future: Model Transformations • Summary

  4. Characterizing 3D • The following mindmap originates from a BoF Meeting at OOPSLA 2003 which tried to characterize the essential properties of Domain Driven Development, and also relate things such as • GP • MDA • ...

  5. Characterizing 3D Model

  6. Characterizing 3D Model Domain Specific Language

  7. Characterizing 3D semantics Model Domain Specific Language

  8. Characterizing 3D knowledge semantics Model Domain Specific Language

  9. Characterizing 3D knowledge semantics Model Domain Specific Language Metamodel

  10. Characterizing 3D knowledge semantics Model Domain Specific Language graphical Metamodel textual

  11. Characterizing 3D knowledge Domain semantics Model Domain Specific Language graphical Metamodel textual

  12. Characterizing 3D bounded area of knowlege/interest knowledge Domain semantics Model Ontology Domain Specific Language graphical Metamodel textual

  13. Characterizing 3D bounded area of knowlege/interest knowledge Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  14. Characterizing 3D subdomains bounded area of partial knowlege/interest multiple knowledge viewpoint Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  15. Characterizing 3D subdomains bounded area of partial knowlege/interest composable multiple knowledge viewpoint Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  16. Characterizing 3D Metametamodel subdomains bounded area of partial knowlege/interest composable multiple knowledge viewpoint Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  17. Characterizing 3D Metametamodel target subdomains software architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  18. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  19. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint transform Domain semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  20. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint transform Domain compile semantics Model Ontology precise/ Domain executable Specific Language graphical Metamodel textual

  21. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint transform Domain compile semantics Model Ontology interpret precise/ Domain executable Specific Language graphical Metamodel textual

  22. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret precise/ Domain executable Specific Language graphical Metamodel textual

  23. Characterizing 3D Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel textual

  24. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel textual

  25. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution

  26. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution customizability

  27. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution customizability software families

  28. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution customizability software families product lines

  29. Characterizing 3D several Metametamodel target subdomains software software designexpertise architecture architecture bounded area of partial knowlege/interest composable multiple knowledge viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution customizability software families product lines portability

  30. MDA? And MDA?

  31. MDA Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language graphical Metamodel rapid textual evolution customizability software families product lines portability

  32. MDA Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  33. MDA MOF Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  34. MDA MOF Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific OCL, Action Semantics Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  35. MDA MOF Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific OCL, Action Semantics Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  36. MDA MOF Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable PIM, PSM, .... multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific OCL, Action Semantics Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  37. MDA MOF Metametamodel target subdomains software software architecture architecture bounded area of partial knowlege/interest composable PIM, PSM, .... multiple viewpoint multi-step transform Domain single-step compile semantics Model Ontology interpret no precise/ Domain roundtrip executable Specific OCL, Action Semantics Language UML+Profiles graphical Metamodel rapid textual evolution customizability software families product lines portability

  38. MDD defined • Model Driven Development (MDD) means developing executable software from higher-level models. • A Model in this context is defined to be some specification that cannot be directly executed on current mainstream platforms (such as Java, .NET, Intel x86, ...). • Models can be graphical (e.g. UML, Aris) or they can be textual (typically called DSLs, or Domain-Specific Languages). • Code, on the other side, is a directly executable artifact on current platforms. • Thus, the definition of what is a model and what is code is always relative to current mainstream platforms. • See comparison to lower level / higher level languages and compilers

  39. How to execute models • Executing models can happen in different ways: • Models can be interpreted by a „model-VM“. Dirk Riehle‘s UML virtual machine is an example. • Typically, however, models are compiled into lower-level models or code, which is then executed (compiled or interpreted).

  40. Abstraction and Concretization • To make model-driven development worthwhile, models must provide some higher level of abstraction over the platform on which they are executed. • This higher-level of abstraction is typically achieved by using domain-specific abstractions in the models. • „Domain specific“ can denote a business domain or a technical domain • UML models which show a box for each and every implementation class might be useful, but this is not an example of model-driven development. • These higher-level models are then typically transformed to more concrete models (and/or finally, code). • This can happen in a single step or in multiple steps. • The rules for such transformations must be specified somewhere.

  41. Abstraction and Concretization: Example

  42. Software System Families • Typically, MDD makes most sense in the context of software system families because developing modeling environments, generators, translators, etc. can be a lot of work and it pays only if reused. • What is a software system familiy?We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members. Definition by Parnas

  43. Examples for Software System Families • A set of projects in the same domain (banking, telecom switching, automotive diagnosis). • You might be able to generate recurring business logic from models. • A set of artifacts based on the same infrastucture (such as EJB) in one project. • Here, you might be able to to generate all the infrastructure-specific code around manually implemented business logic. • you have some specific business logic that you want to run on different platforms. • You might be able to generate platform-specific implementation code from the models (this is the focus of MDA) • a set of artifacts based on the same modelling paradigm, such as state chart. • You might be able to generate the complete implementation based on the model and its predefined mapping to lower-level implementations.

  44. Models in MDA • This is a taxonomyof models in MDA (adapted from David Frankel‘s MDA book)

  45. Models in MDA II • PIMs are independent of any particular implementation platform. They only capture the business logic – the problem space in terms of GP. • A series of model transformations is then applied to concretize the model for specific platforms. • Mapping rules (as covered later) are part of the core model definition – they operate on the metamodel defined by the core model.

  46. Software System Families revisited • Developing an MDD infrastructure – however simple or sophisticated it may be – is always additional effort. • Such an infrastructure can include • A clearly defined system architecture • Modelling abstractions, metamodels and profiles • Model verifiers and design checkers • Reusable components and composition rules, frameworks and libraries • Generators and/or model interpreters • You only want to do this if this additional effort pays off! • Like with mass production, the amount of effort you put into the infrastructure must be less than the amount of effort you save when developing the products.

  47. Product Line Engineering • Domain Scoping • Variability Analysis • Domain Structuring • Define common architecture • Define Production Plan • Define Building Blocks • Components • DSLs & Generators • Production Process

  48. Variability Analysis • Variability analysis discovers the variable and fixed parts of a product in a domain. Parts can be • Structural or behavioral • Functional or non-functional (technical) • Modularized or aspectual • To define variable parts, we need to have a commonality base: a base platform, a common architecture • There are two kinds of variability: • positive variability: add something (optional) • negative variability: removes something (essential) • Positive variability leaves the concept intact, while netative variability does not.

  49. Example Feature Diagram • Example products: • An aircraft with a low wing, piston engine and made of metal, wood and cloth: Robin DR-400 • An aircraft with shoulder wing, no engine and made of plastic: ASW-27 • An aircraft with low wing, jet engine(s) and made of metal: Airbus A320

  50. Feature Diagrams cont‘d • They can contain constraints on the combinations of features • They can define „names“ for specific combinations of features; feature groups • Features can be open: additional subfeatures can be added • Features can be incomplete: the subfeatures are not yet defined • Multiplicity of subfeatures can be added • And more...

More Related