OMG

1
OMGs 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)
• 3 million COBOL Programmers
• 1.6 million VB Programmers
• 1.1 million C/C Programmers
• Operating systems
• Unix, MacOS, Windows(3.1-gtXP),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

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?

9
OMGs Milestones
OMG is founded
CORBA 2.0
CORBA 1.0, IDL
MDA
UML, MOF, XMI, CWM
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
• 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

16
PSM an example
17
MDA metamodel
18
MDA in a Snapshot
Vertical Domains
Core Technologies
Pervasive Services
Core Target Platforms
19
3. Developing in MDA
20
System Development Lifecycle and the MDA approach
PIM to PIM mappings
PSM to PSM mappings
UML MOF CWM
Time
PIM to PSM mappings (projection on a specific
platform)
21
Developing in MDA Step 1the 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 1the PIM (2/2)
Pervasive Services Model
PIM
Calls
Domain Facilities Model
Calls
23
Developing in MDA Step 2the 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 2the PSM (2/2)
PIM
Maps to
Maps to
Maps to
CORBA Model
Java/EJB Model
Other Model

25
Developing in MDA Step 3Generating
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 3Generating
Application (2/2)
PIM
Maps to
Maps to
Maps to
CORBA Model
Java/EJB Model
Other Model

Maps to
Maps to
Maps to

CORBA
Java/EJB
Other
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 Ive seen since UML
• (Paul Harmon, Senior consultant and Market
  Analyst, CUTTER consortium, 2001)

30
Early Adopters

• Interactive Objects Software GmbH
• ArcStyler
• Kennedy Carter
• iUML, iCCG
• Kabira
• Adaptive Realtime Infrastructure
• Secant technologies
• Model-Driven Infrastructure

• Suns 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 OMGs 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 Carters xMDA
• F-16 Modular Mission Computer Application
  Software, Lauren E.Clark et al.

37
Webliography

• MDA documentation
• http//www.omg.org/mda
• ArcStyler
• http//www.io-software.com/as
• Kennedy Carters iUML and iCCG
• http//www.kc.com
• NetBeans
• 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)

• OMGs 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
43
Example the Relational Metamodel
44
CWM correspondances between models
Metadata
Data
Area
Class
Package
Attribute
Object
Extent
DataValue
Catalog/Schema
Table
Column
RowSet
Row
Column Value
RecordFile
Field
RecordDef
RecordSet
Field Value
Record
Schema
Attribute
ElementType
Document
Element
DataValue
45
MOF (Meta Object Facility)

• OMGs 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
• 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
• 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
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 OMGs 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

• ATT
• 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
IoSoftwares 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 KCs 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 KCs iUML tool and more recently
  iCCG (intelligent Configurable Code Generator) to
  specify an Ada code generator which can
  automatically generate 100 of the implementation