MODEL DRIVEN ARCHITECTURE

                                  By Sameera Avilala


        The MDA is a new way of writing specifications, based on a platform-independent
model. A complete MDA specification consists of a definitive platform-independent base UML
model, plus one or more platform-specific models and interface definition sets, each describing
how the base model is implemented on a different middleware platform. The MDA model is
related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object
Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing
(EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse
Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not
refer to the architecture of the system being modeled, but rather to the architecture of the various
standards and model forms that serve as the technology basis for MDA.

MDA Approach:
         One of the main aims of the MDA is to separate design from architecture. As the
concepts and technologies used to realize designs and the concepts and technologies used to
realize architectures have changed at their own pace, decoupling them allows system developers
to choose from the best and most fitting in both domains. The design addresses the functional
(use case) requirements while architecture provides the infrastructure through which non-
functional requirements like scalability, reliability and performance are realized. MDA envisages
that the platform independent model (PIM), which represents a conceptual design realizing the
functional requirements, will survive changes in realization technologies and software

MDA Tools:

       An MDA tool is a tool used to develop, interpret, compare, align, measure, verify,
transform, etc. models or metamodels. In the following section „model‟ is interpreted as meaning
any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA
approach we have essentially two kinds of models: initial models are created manually by human
agents while derived models are created automatically by programs. For example an analyst may
create a UML initial model from its observation of some loose business situation while a Java
model may be automatically derived from this UML model by a Model transformation operation.
An MDA tool may be one or more of the following types:

      Creation Tool: A tool used to elicit initial models and/or edit derived models.
      Analysis Tool: A tool used to check models for completeness, inconsistencies, or error
       and warning conditions. Also used to calculate metrics for the model.
      Transformation Tool: A tool used to transform models into other models or into code and
      Composition Tool: A tool used to compose (i.e. to merge according to a given
       composition semantics) several source models, preferably conforming to the same
      Test Tool: A tool used to test models as described in Model-based testing.
      Simulation Tool: A tool used to simulate the execution of a system represented by a
       given model. This is related to the subject of model execution.
      Metadata Management Tool: A tool intended to handle the general relations between
       different models, including the metadata on each model (e.g. author, date of creation or
       modification, method of creation) and the mutual relations between these models (i.e. one
       metamodel is a version of another one, one model has been derived from another one by
       a transformation, etc.)
      Reverse Engineering Tool: A tool intended to transform particular legacy or information
       artifact portfolios into full-fledged models.

Modeling in MDA:

       The OMG's Model Driven Architecture initiative shifts the focus of software
development from writing code to modeling. The centerpiece of MDA is the Platform
Independent Model (PIM), modeled in UML. Many of the changes introduced in UML 2.0 are
directly to support MDA; notable among them is the Precise Action Semantics which can be
used to describe behavior. While the PIM is independent of technology, the platform specific
model (PSM) is where the „rubber hits the road‟. Vendors are expected to use mapping and
transformations to convert any given PIM into a PSM or indeed PSM‟s. MDA does not prescribe
how this should be performed, but indicates that typically the transformation will be model to
model, or meta-model to meta-model. In concrete terms, many vendors use tags or other
metadata to annotate the PIM such that the different PSM‟s may be generated.

                                      Fig1: MDA Layout

A PIM may give rise to multiple PSM‟s for two distinct reasons. First, there may be multiple
PSM‟s if the application in its entirety needs to run on different operating system platforms.
More to the point of PIM‟s and PSM‟s: if a new platform emerges during the lifetime of the
application, then a mapping can be defined to that platform and the application moved across.
Second, and as a consequence of supporting the first, MDA is suitable for developing distributed
systems that are made up of components running on different platforms/tiers. For example, there
may be web tier implemented on ASP.Net, but which talks to a middle-tier using EJB‟s, with a
back-end being a Sybase RDBMS. MDA can generate the software for the tiers, plus the code to
glue it all together.

MDA Concerns:
Potential concerns that have been raised with the MDA approach include:
      Incomplete Standards: The MDA approach is underpinned by a variety of technical
       standards, some of which are yet to be specified.
      Vendor Lock-in: Although MDA was conceived as an approach for achieving platform
       independence; current MDA vendors have been reluctant to engineer their MDA toolsets
       to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an
       MDA approach.
      Complexity: There is some complexity of mapping between the various layers.
      Specialized Skill sets: Practitioners of MDA based software engineering are required to
       have a high level of expertise in their field.
      Support in meta model to handle dynamic behavior.

                                     Fig2: MDA Overview
Model Driven Architecture provides an open, vendor-neutral approach to the challenge of
business and technology change. MDA separates business and application logic from
underlying platform technology. Platform independent models of an application or integrated
system‟s business functionality and behavior, built using UML and the other associated
OMG modeling standards can be realized through the MDA on virtually any platform, open
or proprietary, including Web Services, .NET, CORBA, J2EE and others. These platform
independent models document the business functionality and behavior of an application
separate from the technology-specific code that implements it, insulating the core of the
application from technology and its relentless churn cycle while enabling interoperability
both within and across platform boundaries.

1), “Conclusion for MDA”, Pg 1-2
2), “MDA Architecture and
   basics”, Pg 1-7
   “MDA Principles”, Pg 2-4
4), “MDA Tools”, Pg 1-2

To top