The OMGs Model Driven Architecture

1
The OMGs Model Driven Architecture

• INFO3011 Software Architecture and Design

2
Why the MDA?

• The OMG specified the Object Management
  Architecture (OMA) in 1990
• Specified the CORBA standards
• Since 1997 has specified a number of non-CORBA
  standards
• Unified Modeling Language (UML)
• XML/XMI (XML Metadata Interchange)
• Common Warehouse Model (CWM)
• MetaObject Facility (MOF)
• Rapid expansion of new technologies raises issues
  of integration

3
Aims of the MDA

• MDA aims to
• Support evolving standards in diverse application
  domains
• Embrace new technologies and changes in existing
  technologies
• Address the complete lifecycle of
• Designing Applications
• Deploying Applications
• Integrating Applications
• Managing Applications
• while using open data standards

4
Basic Principles

• MDA separates the fundamental logic from behind
  a specification from the detail of the particular
  middleware that implements it
• The Architecture assures
• Portability
• Cross-platform interoperability
• Platform independence
• Domain specificity
• Productivity

5
Bottom-line Benefits

• Benefits claimed include
• Reduced cost throughout the application
  life-cycle
• Reduced development time for applications
• Improved application quality
• Increased return on technology investments
• Rapid inclusion of emerging new technologies

6
MDA

• Provides an abstract model of the middleware
  environment with the aim of bringing
  standardisation to application design
• Leverages existing OMG standards
• UML,MOF, CWM
• Platform-independent descriptions can be deployed
  in many technologies
• CORBA, J2EE,.NET etc.,
• Includes already specified pervasive services
• Enables creation of standard domain models

7
MDA Models

• MDA defines a model as
• Something that must be paired with a definition
  of a modelling language using semantics provided
  by the MOF
• Three categories of models
• Computationally Independent (CIM)
• E.g., business type model (problem space)
• Platform Independent (PIM)
• E.g., system type model (specification space)
• Platform Specific (PSM)
• Target technology specific (solution space)

8
Model Relationships

• Models are related by
• Abstraction
• Refinement
• Viewpoint
• i.e., the mappings can be vertical
  (abstraction-refinement) or horizontal

9
Example of Vertical Mapping

• The PIM version of Account specifies, say, an
  object class Account without saying anything
  about its implementation.
• A CORBA-specific implementation which conforms to
  this specification would be a PSM refinement of
  that abstraction

10
Vertical/Horizontal Mapping

• Viewpoints are projections (i.e., they are not
  necessarily disjoint). Therefore the same
  abstractions may appear in different viewpoints,
  but perhaps with different properties. Because
  they are at the same level of abstraction this is
  referred to as horizontal mapping.

11
Using UML to Model Relationships

• The MDA proposes modelling the mapping rules
  themselves as first class citizens. The EDOC
  profile is a UML profile that has already been
  established. Others will follow

In practice, the MDA is realized as a UML
Profile a meta-model of the middleware
environment
12
Automation of Mapping?

• An issue that arises and is critical to the
  discussion on Software Architecture is whether
  mappings between models can be abstracted and
  automated and reused in tools, or whether the
  various models are more important as reference
  points for creative design

13
Developing Using MDA (1)

• Development of the application in MDA starts with
  a first-level PIM
• With an aspiration to automatically generate all
  or most of the running application
• This base PIM expresses only business
  functionality and behaviour for client and server
• Built by business and modelling experts
• Appears, nevertheless, to be a systems view of
  business information (presumably a model of the
  business itself is expressed in a CIM)
• A second-level PIM adds some aspects of
  technology
• E.g., activation patterns(session, entity),
  persistence, transactionality, security levelling
  etc.

14
Developing in MDA (2)

• MDA application tools will contain
  representations of the Domain Facilities and
  Pervasive Services
• Any facility modelled in UML can be imported
• The PIM will model links to these services
• The PIM is stored in the MOF and input to the
  mapping step for producing the PSM
• UML Profiles give UML the ability to model both
  PIMs and PSMs
• Profiles are standard extensions for a particular
  domain consisting of UML stereotypes and tagged
  values

15
Developing in MDA (3)

• The MDA definition document specifies 4 ways of
  moving from a PIM to a PSM
• Transformation by hand, working with each
  application on a separate, individual basis
• Transformations by hand using established
  patterns to convert from the PIM to a particular
  PSM
• The established patterns define an algorithm
  which is selected in the MDA tool, producing
  skeleton code which is finished by hand
• The tool, applying the algorithm, generates the
  entire PSM
• Generate the application from the PSM

16
Issues for Software Architecture (1)

• From the Masterplan view of Software
  Architecture
• MDA extends the practical possibilities of
  blueprinting
• MDA has the aim to fully automate software
  development
• From UML PIMs to running application and back
• NB it is accepted that currently any changes in
  code would have to be handcrafted into the UML
  first
• Rigorous modelling of mapping rules provides
  scope for extending use of formal methods
• Focus is on transformation methods 3 and 4 in the
  list provided in the MDA Definition Document

17
Issues for Software Architecture (2)

• From the Piecemeal Growth viewpoint
• The classification of models validates the
  significance of a Problem Space
• The idea of standard mappings and patterns
  implies a base of shared knowledge
• MDA claims to support iterative development
• Focus is on transformation methods 1 and 2 in the
  list provided in the MDA Definition Document

18
Issues for Software Architecture (3)

• The MDA will provide a new framework in which the
  arguments of both camps can still be put forward
• The commercial interest in MDA tools will focus
  on abstraction/retrieval
• i.e., vertical mapping
• Fairly well understood notions of retrieval,
  existence of OCL etc., will boost this
• Relatively easy to automate
• Research interest may focus on horizontal mapping
• Developing PIMs from multiple, overlapping
  viewpoints
• Possibly not automatable at all

19
Summary

• The OMGs MDA provides a new framework for the
  ongoing debate on Software Architecture
• Key elements are the 3 classes of models
• CIMs, PIMs, and PSMs
• and the mappings between them
• Vertical (abstraction/refinement)
• Horizontal (viewpoint)
• and existing OMG standards
• UML, CWM, XML/XMI, MOF
• Pervasive Services, Domain Facilities
• The PIM-gtPSM transformation methods are where the
  future focus of masterplan v piecemeal growth
  will lie