1. OMG’s Model Driven Architecture Davide Buscaldi D.I.S.I.

2. Summary  1. Introduction  2. MDA Overview  3. Developing in MDA  4. MDA in the Practice  5. References

3. 1. Introduction

4. A heterogeneous world…  Programming languages: (see also: the DoD survey) (see also: the DoD survey) (see also: the DoD survey)  ~3 million COBOL Programmers  ~1.6 million VB Programmers  ~1.1 million C/C++ Programmers  Operating systems:  Unix, MacOS, Windows(3.1->XP),PalmOS  Embedded devices  Networks:  Ethernet, IP, USB, FireWire  Bluetooth, 802.11b, HomeRF

5. Where can we agree?  Hetereogenity hinders the development of enterprise distributed systems  There will not be consensus on  Hardware  Operating systems  Network protocols  Programming languages  We can agree at an higher level  Middleware  Hetereogenity hinders the development of enterprise distributed systems  There will not be consensus on  Hardware  Operating systems  Network protocols  Programming languages  We can agree at an higher level  Middleware

6. Middleware  A software layer that masks hetereogeneity  Placed between operating systems and application components

7. Middleware proliferation  Middleware itself has proliferated:  CORBA  COM / DCOM / MTS  Java / EJB  XML / SOAP  C# /.NET  None of them prevails over the others  The problem remains

8. The Object Management Group (OMG)  An open membership and no-profit consortium  Produces and mantains computer industry specifications for interoperable enterprise applications Who are OMG? Who are OMG?

9. OMG’s Milestones 1989 199119961997 2001 OMG is founded CORBA 1.0, IDL CORBA 2.0 UML, MOF, XMI, CWM MDA

10. 2. MDA Overview

11. What is the MDA?  An approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a particular technology platform platform  “Design once, build it on any platform”

12. Basic concepts of MDA  A model is a formal specification of the function, structure and/or behaviour of a system  Examples:  Source code is a model  An UML-based specification is a model  Models of different systems are structured explicitly into:  Platform Independent Models (PIM)  Platform Specific Models (PSM)

13. Platform Independent Model (PIM)  A “formal” specification of the structure and function of a system that abstracts away technical detail  Expressed using UML

14. PIM: an example

15. Platform Specific Model (PSM)  Specifies how the functionality specified in a PIM is realized on a particular platform  Expressed using UML extended with platform specific UML profiles UML profilesUML profiles

16. PSM: an example

17. MDA metamodel MOF Other languages UML Metamodel PIM Mapping techniques PSM Mapping techniques PIM PSM Infrastructure > > 1..n 1..n Refactoring from PSM to PIM > > 1..n 1..n Mapping from PIM to PIM 1..n Mapping from PIM to PSM 1..n Mapping from PSM to PSM 1..n > >

18. MDA in a Snapshot Core Technologies Core Target Platforms Pervasive Services Vertical Domains

19. 3. Developing in MDA

20. System Development Lifecycle and the MDA approach UML MOF CWM Time PIM to PIM mappings PIM to PSM mappings (projection on a specific platform) PSM to PSM mappings

21. Developing in MDA – Step 1: the PIM (1/2)  All MDA development projects start with the creation of a PIM  PIM at this level represents business functionality and behaviour, undistorted by technology details  MDA application-modeling tools contain representations of Pervasive Services and Domain Facilities allowing them to be used and/or incorporated in the application via a menu selection

22. Developing in MDA – Step 1: the PIM (2/2) PIM Pervasive Services Model Calls Domain Facilities Model Calls

23. Developing in MDA – Step 2: the PSM (1/2)  Once the first iteration is complete, the PIM is input to the mapping step which will produce a PSM  Code is partially automatic and partially hand-written  PIM can be mapped either to a single platform or to multiple platforms

24. Developing in MDA – Step 2: the PSM (2/2) PIM CORBA Model Maps to Java/EJB Model Maps to Other Model… Maps to

25. Developing in MDA – Step 3: Generating Application (1/2)  An MDA tool generates all or most of the implementation code for the deployment technology selected by the developer  Re-integration on new platforms can be done by reverse engineering the existing application into a model and redeploy

26. Developing in MDA – Step 3: Generating Application (2/2) PIM CORBA Model Maps to Java/EJB Model Maps to Other Model… Maps to CORBAJava/EJBOther … Maps to

27. 4. MDA in the Practice

28. MDA Adoption Status  Adoption of MDA is at an early stage  UML profiles underway:  CORBA (adopted)  EJB (adopted)  SOAP/XML (in process) .NET (to be started)  UML 2.0 in process

29. Future Trends  “A market for MDA will be created as OO modeling and development tool vendors incorporate MDA into their offerings”  “It will be two or three years before mature MDA tools emerge”  “This is the most exciting enterprise software initiative I’ve seen since UML” (Paul Harmon, Senior consultant and Market Analyst, CUTTER consortium, 2001)

30. Early Adopters  Interactive Objects Software GmbH  ArcStyler ArcStyler  Kennedy Carter  iUML, iCCG iUML, iCCG iUML, iCCG  Kabira  Adaptive Realtime Infrastructure  Secant technologies  Model-Driven Infrastructure  Sun’s NetBeans was added to this list on May 7th 2002  …stay tuned!

31. Conclusions (1/2)  Abstracting out the structure and behaviour of a system in the PIM makes easier:  To validate the correctness of the model  To produce implementations on different platforms  The application of tool supported solutions

32. Conclusions (2/2)  The major drawback is that MDA does not provide a standard for the specification of mappings  Different implementation of mappings can generate very different code or models  This can create dependencies between the software and the mapping solution used

33. 5. References

34. Bibliography (1/3)  MDA Specification:  Model Driven Architecture specification, OMG Architecture board, July 2001  Introduction and overview of MDA:  Model Driven Architecture: An introduction, R.M. Soley  Model Driven Architecture, Richard M.Soley (OMG CEO), November 2000  CWM and MOF definitions:  Model-Driven Architecture: Vision, Standards and Emerging Technologies, John D.Poole, ECOOP April 2001

35. Bibliography (2/3)  CWM examples:  Enterprise CORBA 2001 – CWM, Pete Rivett  System Development Lifecycle in MDA:  Developing in OMG’s Model-Driven architecture, Jon Siegel, November 2001  Middleware definition:  Software Engineering and Middleware: A Roadmap, W.Emmerich  The DoD survey on PLs:  A survey of Computer Programming Languages Currently used in the DoD, A.Hook et al., 1995

36. Bibliography (3/3)  Conclusions and future trends:  Pratical experiences in the application of MDA, M. de Miguel et al.  MDA: An Idea whose time has come, Paul Harmon  Kennedy Carter’s xMDA:  F-16 Modular Mission Computer Application Software, Lauren E.Clark et al.

37. Webliography  MDA documentation:  http://www.omg.org/mda http://www.omg.org/mda  ArcStyler:  http://www.io-software.com/as http://www.io-software.com/as  Kennedy Carter’s iUML and iCCG:  http://www.kc.com http://www.kc.com  NetBeans:  http://www.netbeans.org http://www.netbeans.org

38. The End

39. Platform  Technological and engineering details that are irrelevant to the fundamental functionality of a software component

40. UML Profile  A standardized set of extensions (stereotypes and tagged values)  Defines an UML environment tailored to a particular use, such as modeling for a specific platform  UML profile for CORBA was standardized in 2000

41. Common Warehouse Metamodel (1/2)  OMG’s data warehouse standard  Enable easy interchange of  warehouse and business intelligence metadata between  warehouse tools  warehouse platforms and  metadata repositories  in distributed heterogenous environments.  Defined using MOF

42. Common Warehouse Metamodel (2/2)  Comprised of a number of constituent metamodels representing:  Data resources  Analysis  Warehouse management  Foundational components of a typical data warehousing/business intelligence environment  Drawn using UML profile for MOF More on CWM… More on CWM…

43. Example: the Relational Metamodel

44. CWM: correspondances between models Catalog/ Schema TableColumn Relational Record RecordFileFieldRecordDef XML SchemaAttributeElementType ClassPackage Object Oriented Attribute RowSetRow Column Value RecordSet Field Value Record DocumentElement ObjectExtent Data Value MetadataDataArea

45. MOF (Meta Object Facility)  OMG’s standard for defining metamodels  Provides standard modeling and interchange constructs used in MDA  UML and CWM are defined in terms of MOF constructs  The three main metadata modeling constructs provided by the MOF are:  Class  Association  Package

46. Mappings  Mapping is defined as a set of rules and techniques used to modify one model in order to get another model  Mappings are described using UML

47. Refining  Makes a model less abstract  Permits “zooming” in (and out of) a model:

48. PIM to PIM mapping  Used when models are enhanced, refined or filtered during the development lifecycle without needing any platform dependant information refined  Example: analysis to design models transformation

49. PIM to PSM mapping (1/3)  This transformation is used when the PIM is projected to the execution infrastructure infrastructure  Projection is based on platform characteristics  These characteristics should be described using a UML description (and eventually a profile for describing common platform concepts)  There are multiple ways to transform a PIM into a corresponding PSM More on mapping More on mapping

50. PIM to PSM mapping: techniques (2/3)  A human could study the PIM and:  Manually construct a platform-specific model  Utilize models of known refinement patterns to reduce the burden in constructing the PSM

51. PIM to PSM mapping: techniques (3/3)  An algorithm could:  Be applied to the PIM and create a skeleton of the PSM to be manually enhanced by hand  Create a complete platform specific model from a complete platform independent model, explicitly or implicitly recording the relation for use by other automated tools

52. PSM to PSM mapping  This transformation is needed for component realization and deployment  Generally related to platform dependent model refinement

53. PSM to PIM refactoring  This transformation is required for abstracting models of existing implementations in a particular technology into a platform independent model  Represents a “mining” process hard to be fully automated  Result of this transformation will match the corresponding PIM to PSM mapping

54. Infrastructure  A set of software or hardware pieces assumed to be already present by some stakeholders when he/she develops a software artifact

55. Core models  The core target platforms of the MDA:  CORBA  Java/EJB  C#/.NET  XML/SOAP  MDA provides UML profiles for these target platforms

56. Pervasive Services  Essential services for many applications  transactions  directory services  security  persistance  others…  OMG will define them at PIM level

57. OMG Domain Models  Standardization of services in specific vertical markets  They will be in the form of normative PIMs expressed using UML, augmented by normative PSMs for at least one platform  They are being developed by OMG’s DTFs (Domain Task Forces)

58. The DoD survey of programming languages  Report on programming languages used in the DoD (1995)  In 1995 there were more than 2500 PLs worldwide Total SLOC by gp third generation languages:

59. Some of the OMG members:  AT&T  BEA  Borland  Boeing  CA  Citigroup  Compaq  Ericsson  Ford  Fujitsu  Glaxo  HP  Hitachi  Hyperion  IBM  IONA  io Software  Kabira  KC  John Deere  Microsoft  MITRE  MSC Soft  NASA  NEC  NetGenics  NTT  OASIS  Oracle  Pfizer  Rational  SAGA  SAP  SAS  Secant  Siemens  Sprint  Sun  Unisys  Vertel

60. IoSoftware’s ArcStyler

61. ArcStyler Success Story  Deutsche Bank Bauspar AG used ArcStyler to embed existing COBOL mainframe application into modern web-based system  A customized Cartridge was created

62. The KC’s xMDA approach xMDA: eXecutable UML + MDA

63. xMDA Success story  Lockheed Martin used MDA to develop the F-16 Modular Mission Computing software  They used the KC’s iUML tool and more recently iCCG (intelligent Configurable Code Generator) to specify an Ada code generator which can automatically generate 100% of the implementation