1. Model Driven Architecture MDA SE-548 Lale Doğan 1708833

2. Content Introduction Structure of MDA Models in MDA Mapping – Model Transformation MDD, MDE. Advantages of MDD Example MDA Tool – Enterprise Architect

3. Introduction The MDA defines an approach that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform. The MDA approach allows; the same model specifying system functionality to be realized on multiple platforms through mapping standards different applications to be integrated by explicitly relating their models, enabling integration and interoperability.

4. MDA provides an approach for, and enables tools to be provided for: – specifying a system independently of the platform, – specifying platforms, – choosing a particular platform for the system, – transforming the system specification into one for a particular platform. The three primary goals of MDA are: – portability – interoperability – reusability through architectural separation of concerns.

5. Model Driven Architecture (MDA) is language-, vendor- and middleware-neutral.

6. The core of the architecture, at the center of the figure, is based on OMG’s modeling standards.

7. Modeling Standards UML, the Unified Modeling Language, allows a model to be constructed, viewed, developed, and manipulated in a standard way at analysis and design time. UML models allow an application design to be evaluated and criticized before it is coded, when changes are easier and less expensive to make. Common Warehouse Meta-model (CWM) standardizes how to represent database models (schema), schema transformation models, data mining models, etc. The Meta-Object Facility (MOF) standardizes a facility for managing models in a repository. XML Metadata Interchange (XMI) is an interchange format for models, based on the MOF and XML.

8. The first step when constructing an MDA- based application will be to create a platform- independent application model expressed via UML in terms of the appropriate core model. Platform specialists will convert this general application model into a specific platform such as EJB. Standard mappings will allow tools to automate some of the conversion. The target platforms occupy the thin ring surrounding the core in the figure.

9. “Companies that adopt the MDA gain flexibility: the ability to derive code from a stable model as the underlying infrastructure shifts over time.”

10. “When we map a platform-independent model to a particular platform, we produce not only artifacts native to that platform (IDL, deployment descriptors, etc.) but also a platform-specific UML model. We do this because the UML model can express the semantics of the platform-specific solution much more richly than IDL or XML.”

11. Platform Independent Model (PIM) A model of a subsystem that contains no information specific to the platform, or the technology that is used to realize it. Describes the structure and function of a system, but not the specific implementation.

12. Platform Specific Model (PSM) The platform-specific model represents both the business and technical run-time semantics of the application. It’s still a UML model, but is expressed in a dialect (i.e. a profile) of UML that precisely mirrors technical run-time elements of the target platform. Possible PSM artifacts may include source code, DDL, configuration files, XML and other output specific to the target platform. The semantics of the platform-independent original model are carried through into the platform-specific model.

13. Code Generation For component environments, the system will have to produce many types of code and configuration files including interface files, component definition files, program code files, component configuration files, and assembly configuration files. “We can generate a lot of the code and reduce the need for hand, and in some restricted cases we will be able to generate all of the code. “

14. The more completely the platform-specific UML dialect reflects the actual platform environment, the more completely the application semantics and run-time behavior can be included in the platform-specific application model and the more complete the generated code can be. “Modeling the application semantics as much precisely as possible enables a greater degree of code generation.”

15. Mapping

16. Metamodel Description of MDA- Mapping Models

17. Metamodel Mapping Transformation

18. A mapping is a set of rules and techniques used to modify one model in order to get another model. Mappings are used for transforming: PIM to PIM: – Analysis to design models transformation – PIM to PIM mappings are generally related to model refinement

19. PIM to PSM: – Includes platform characteristics – Describing the characteristics are done using a UML description – Going from a logical component model to a commercial existing component model (like EJB for J2EE) is a kind of PIM to PSM mapping

20. PSM to PIM: – Required for abstracting models of existing. – Implementations in a particular technology into a platform- independent model – Hard to be fully automated – May be supported by tools – Ideally this mapping should be equivalent to the reverse mapping

21. PSM to PSM: – Needed for component realization and deployment. – PSM to PSM mappings are generally related to platform dependent model refinement.

22. MDA increases reusability through separation of concern and abstraction. A PIM is an abstract model which contains enough information to drive one or more PSMs. MDA aims to enhance portability by way of separating system (abstract) architecture from platform (concrete) architecture. MDA has the capability to define transformations that map from PIMs to PSMs. This facilitates the development of a system in abstraction, and simplifies implementation.

23. MDA Transformation

25. Relationship between MDA, MDD and MDE

26. Model Driven Engineering (MDE) Model-driven engineering (MDE) is a software development methodology which focuses on creating and exploiting domain models. MDE aims to raise the level of abstraction in program specification and increase automation in program development. Higher-level models are transformed into lower level models until the model can be made executable using either code generation or model interpretation.

27. Model Driven Development (MDD) The solving of problems using Models and using Models as the inputs to parameterized implementation generators. The rapid solutioning of complex systems from Models which are smaller and more abstract.

28. Advantages of Model-Driven Development: – MDD is faster – MDD is more cost-effective – MDD leads to increased quality – MDD is less error-prone – MDD leads to meaningful validation – MDD empowers domain experts – MDD lets advanced programmers focus on the hard stuff

29. Advantages of Model-Driven Development: – MDD bridges the gap between business and IT – MDD results in software being less sensitive to changes in business requirements – MDD results in software being less sensitive to changes in technology – MDD really enforces architecture – MDD captures domain knowledge – MDD provides up-to-date documentation – MDD enables to focus on business problems instead of technology

30. Enterprise Architect UML 2.1 based modeling tool, Enterprise Architect. Used for developing and evolving MDA support Offers a number of tools, including – a comprehensive PIM to PSM Transformation Engine, allowing modelers to target multiple PSMs from a single PIM – and to synchronize PIM changes into the PSM on demand.

31. Has code generation templates, UML Profiles, UML Patterns, Frameworks,extensive reverse engineering capabilities and a complete automation API for scripting and extending.

32. For example, an MDA Transform from a PIM to a DDL will create DDL table elements from a class, whereas the same class transformed to an EJB Entity Bean will result in a package containing the class and interface elements required by EJB. Enterprise Architect (EA) helps you manage such transformations and even write your own transformation rules for any language. It will also aid you in keeping as many Platform Specific Models as you need synchronized to a single Platform Independent Model. Enterprise Architect has built-in support for MDA transforms, to C#, DDL, EJB, Java and XSD.

33. Summary of MDA and Model Driven Generation Support in Enterprise Architect Built-in Transforms for DDL, EJB, Java, C# and XSD Transform templates for defining user transforms Languages supported in base version: C++, Java, C#, VB.Net, Visual Basic, PHP, Delphi Plug-ins for CORBA available Support for pluggable technologies through – UML Patterns – UML Profiles – Code generation templates – Code parsing grammars – PIM to PSM Transformation Template empower

34. Details of Built-In Transforms: DDL: Transforms platform-independent class elements to platform-specific table elements. EJB Entity: Transforms platform-independent class elements to packages containing the class and interface elements that comprise an EJB Entity Bean. EJB Session: Transforms platform-independent class elements to packages containing the class and interface elements that comprise an EJB Session Bean. Java: Transforms platform-independent elements to Java language elements. C#: Converts a PIM to a standard C# implementation set. WSDL: Converts a simple representation of a WSDL interface into the elements required to generate that interface. XSD: Transforms platform-independent elements to XSD elements.

35. Database Modeling Extensive support for modeling database systems and generating DDL. Support for reverse engineering a range of popular database systems, including Oracle, MS Access, SQL Server and more. Access to Model Information Outside EA Support for XMI import/export to other tools (modeling tools and/or third party). Extensive automation API for accessing model elements and diagrams.

36. A Quick Overview of the MDA Transformation Process in Enterprise Architect The following slides show some details of a PIM to PSM transform and the result. In EA you can have multiple PSMs from a single PIM and synchronize changes from the PIM when model changes are made.

37. The Platform Independent Model The following diagram shows a simple PIM with three classes, showing the abstract properties and relationships between an Author, their Books and their Publisher. This PIM has no platform specific properties, but is truly an abstract representation.

38. Sample PIM

39. Select and Start the Transform Selecting the three classes in EA and choosing “Transform Elements” from the context menu provides the following dialog. Here you may choose the PIM elements to transform, the transformation to be invoked, and a target package, if necessary. You can select from the inbuilt transformations, create your own transformations, or use those supplied by third parties.

40. New Project Screen

41. Model Transformation Screen

44. Java Code public class Book { private String Title; private int Status; private String Name; private Publisher m_Publisher; public Book(){ } public void finalize() throws Throwable { } public Publisher getPublisher(){ return m_Publisher; } public void setPublisher(Publisher newVal){ m_Publisher = newVal; }

46. Packages Created During Example Transform For the EJB Session transform, this diagram shows the PSM packages created – one for each EJB Session bean created from the base PIM classes.

47. Example Bean Created from MDA Transformation The following diagram shows an example of the EJB Session Bean PSM. As a PSM is tightly bound to the target domain, Java and EJB specific properties, code and settings are included in the model. These are logically derived during the transform according to the rules of the transform template.

49. Automatic Code Generation From PSM As the PSM contains specific platform properties, the source code generated can be tailored to the target platform quite tightly. This results in high quality code requiring less manual work and output that is in line with your company’s coding standards.