MDA Overview
OMG members voted to establish the MDA as the base architecture
for our organization's standards in late 2001. Software
development in the MDA starts with a Platform-Independent Model
(PIM) of an application's business functionality and behavior,
constructed using a modeling language based on OMG's
MetaObject
Facility (MOF). This model remains stable as
technology evolves, extending and thereby maximizing software ROI.
MDA
development tools, available now from many vendors, convert the
PIM first to a Platform-Specific Model (PSM) and then to a working implementation on
virtually any middleware platform: Web Services, XML/SOAP, EJB,
C#/.Net, OMG's own CORBA, or others. Portability and
interoperability are built into the architecture. OMG's
industry-standard modeling specifications support the MDA: The
MOF;
UML,
now at Version 2.0; the Common
Warehouse Metamodel (CWM); and
XML
Metadata Interchange (XMI). OMG Task Forces organized around
industries including Finance, Manufacturing, Biotechnology, Space
technology, and others use the MDA to standardize facilities in
their domains.
Top
The Genesis and History of MDA
In late 2000, OMG members first reviewed the
document entitled
"Model
Driven Architecture" and decided to form an architecture
team to produce a more formal statement of the MDA. This formal
but still incomplete definition of the MDA was set out in the 2001
document "Model
Driven Architecture - A Technical Perspective", by the OMG
Architecture Board MDA Drafting Team. (This is the same document
that is also linked under "White Papers" on the
Papers
page.). Voted by members in September, 2001, to be the group's
base architecture, the MDA was immediately used by many Domain
Task Forces to define and adopt standards on multiple middleware
platforms.
In mid-2003, members adopted the interim
"MDA
Guide Version 1.0.1" as a more detailed definition of the
architecture. Authors expect to complete the final version around
mid-2005, based on this recent
MDA
Foundation Model.
Top
MDA Specification Support
-
Specifications define the MDA and the MDA Development
Environment:
The most recent OMG statement of MDA architecture and direction
is this MDA
Foundation Model. It states that "Models in the context
of the MDA Foundation Model are instances of MOF metamodels and
therefore consist of model elements and links between them."
This required MOF compliance enables the automated transformations
on which MDA is built. UML compliance, although common, is not a
requirement for MDA models. (This means, for example, that a suitable
development process based on OMG's
Common
Warehouse Metamodel can be MDA-compliant, since CWM is based
on MOF.)
The
MDA
Guide, Version 1.0.1,
just mentioned, defines the
MDA. OMG members expect to replace this interim version with an
update, based on the Foundation Model also just mentioned, around
mid-2005.
Additional OMG specifications, listed on this page, populate the
architecture.
Development tools, provided by vendors, implement
these supporting standards. Working together, these tools
constitute the working MDA modeling and development environment
where architects and developers create MDA applications.
-
Specifications are defined in the MDA:
Facilities and services defined in the MDA and
standardized by OMG take advantage of the MDA's stability and
platform-independence. This includes both the
Pervasive
Services and the Domain Facilities in
about a dozen different industries.
Top
The Meta-Object Facility (MOF™)
In the MDA, models are first-class artifacts, integrated into
the development process through the chain of transformations from
PIM through PSM to coded application. To enable this, the MDA
requires models to be expressed in a MOF-based language. This
guarantees that the models can be stored in a MOF-compliant
repository, parsed and transformed by MOF-compliant tools, and
rendered into XMI for transport over a network. This does not
constrain the types of models you can use - MOF-based languages
today model application structure, behavior (in many different
ways), and data; OMG's UML and CWM are good examples of MOF-based
modeling languages but are not the only ones.
Before you download the MOF spec and start reading, think about
why you care about MOF, and its versions: If you're an architect or
developer, you rely on your tools' MOF compliance when you
move a model from the tool to your corporate repository, or to a
transformation tool or code generator. If your tools don't conform
to the same version of MOF, you'll encounter trouble when you
attempt the transfer. Fortunately, you don't have to read or
understand the MOF spec in order to set up a compatible tool chain -
just know the version numbers, and make sure they're all the same.
(If you're using XMI for transfer, check the XMI versions too.) If
you're a tool builder/supplier, your situation is different: You
have to build MOF compliance into your products, and test for
interoperability by transferring models to and from other vendors'
compliant tools (probably using XMI). The MOF specs were written for
you, so Happy Reading!
The current version is
MOF
1.4, available here.
As you might expect, the foundation for UML 2.0 is MOF 2.0. MOF 2.0 is being adopted in several parts. These
adopted, pre-finalization versions are available to everyone for
free download; OMG members can access more recent versions and
working documents from OMG's work-in-progress
web page.
(There's a MOF 2.0/XMI specification also, which we've
discussed
separately here.)
Top
The Unified Modeling Language™ (UML®)
Each MDA-based specification has, as its normative base, two
levels of models: a Platform-Independent Model (PIM), and one or
more Platform-Specific Models (PSM). For many specifications, these will be defined in UML,
making OMG's standard modeling language a foundation of the MDA. (Use
of UML, although common, is not a requirement; MOF is the mandatory
modeling foundation for MDA.)
UML 2.0 is now the current official version. Tailored to MDA requirements, this
new release improves
Business, Architectural, Structural, and Behavioral modeling and is being done in four
parts. The UML 2.0
Superstructure Specification has been completed, and is available
for
free download here. The other three parts linked here are
finishing up OMG's finalization
maintenance process to fix inconsistencies and resolve
ambiguities. The maintenance process
is not allowed to make major changes, nor to add or delete features
or functionality, so you can get a good idea of what the official
specification will look like from these documents, even though
they don't reflect the final, official version. OMG members can download more recent documents
than the ones listed here by
following relevant links from the
Work
in Progress page, which requires an OMG username and password; non-members can download
somewhat older public
documents for:
To find out if your company is a member of OMG,
click
here. If it is, send email to request@omg.org
requesting your personal OMG username and password if you don't have
one already.
OMG maintains a public UML Resource and
Information Page here.
Several additional specifications help tailor the UML to
support MDA:
A human-usable
Textual Notation enables a new class of
model-editing programs
and enhances the way models (if they're built using a MOF-based
modeling language, of course) can be manipulated. Notation elements map one-to-one to the more verbose XMI,
but the syntax of the HUTN is much more
human-friendly.
A standard
Software
Process Engineering Metamodel defines a framework for
describing methodologies in a standard way. It does not standardize any
particular methodology, but enhances interoperability from one
methodology to another.
Top
UML Profiles
UML Profiles tailor the language to particular areas of
computing (such as Enterprise Distributed Object Computing) or
particular platforms (such as EJB or CORBA). There's a working
definition of UML Profile in
Section
6.2 of this RFP.
In the MDA, both PIMs and PSMs will be defined using UML
profiles; OMG is well along our way defining a suite of profiles that span
the entire scope of potential MDA applications. Profiles are
official OMG specifications,
available
for free download here. The current suite of profiles
includes:
The
UML
Profile for CORBA, which defines the mapping from a PIM to a CORBA-specific
PSM.
The
UML
Profile for CCM (the CORBA Component Model), OMG's contribution
to component-based programming. Enterprise JavaBeans (EJBs) are the
Java mapping of CCM; an initial take on a profile for EJB appears as
an appendix of the UML 2.0 Superstructure specification, linked
above.
The
UML
Profile for EDOC is used to build PIMs of enterprise
applications. It defines representations for entities, events,
process, relationships, patterns, and an Enterprise Collaboration
Architecture. As a PIM profile, it needs mappings to
platform-specific profiles. A mapping to Web Services is underway
now; additional mappings will follow.
The
UML
Profile for EAI defines a profile for loosely-coupled
systems - that is, those that communicate using either asynchronous
or messaging-based methods. These modes are typically used in
Enterprise Application Integration, but are used elsewhere as well.
The
UML
Profile for Quality of Service (QoS) and Fault Tolerance
defines frameworks for Real-time and high-assurance
environments.
The
UML
Profile for Schedulability, performance, and time supports precise modeling of
predictable - that is, real-time - systems, precisely enough to
enable quantitative analysis of their schedulability, performance,
and timeliness characteristics.
The
UML
Testing Profile provides important support for automated testing
in MDA-based development environments.
Top
XML Metadata Interchange (XMI™)
XMI defines an XML-based interchange format for UML and other
MOF-based metamodels
and models (since a metamodel is just a special case of a model), by
standardizing XML document formats, DTDs, and schemas. In so doing, it also
defines a mapping from UML to XML. Because one of OMG's XMI updates
reflects the incorporation of XML Schemas, while MOF point updates
were made periodically through OMG's established maintenance process,
numbering of XMI and MOF versions diverged. Here is a
table of corresponding MOF and XMI versions:
| MOF 1.3 |
XMI 1.1 |
| MOF 1.4 (current) |
XMI 1.2 |
| MOF 1.4 (current) |
XMI 1.3 (adds Schema support) |
| MOF 1.4 (current) |
XMI 2.0 (current; new format) |
| MOF 2.0 (in process) |
XMI 2.1 (in process) |
You can access the archived
MOF
1.3. here; it's also linked from the
Modeling
section of OMG's Specification Vault. The vault is also where
you'll find all of the archived
versions
of XMI. Check out our
Modeling Specifications
Catalog page for the current
MOF
1.4 Specification and
XMI
2.0 Specification.
Top
Common Warehouse MetaModel (CWM™)
The CWM standardizes a complete, comprehensive metamodel that
enables data mining across database boundaries at an enterprise and
goes well beyond. Like a UML profile but in data space instead of
application space, it forms the MDA mapping to database schemas. The
product of a cooperative effort between OMG and the Meta-Data
Coalition (MDC), the CWM does for data modeling what UML does for
application modeling.
OMG maintains a CWM Resource
Page here.
The CWM is a
formal
OMG specification and is available here.
A supplementary specification,
CWM
Metadata Interchange Patterns, defines patterns that smooth the
way to data modeling tool interoperability.
Top
CORBA®
Although MDA can target every middleware platform and will map to
all that have significant market presence, CORBA plays a key role as a
target platform because of its programming language-, operating
system-, and vendor-independence. The latest
CORBA
specifications, including the CCM, are available here. IDL
Mappings to the various programming languages are
listed
separately, here. And specialized CORBA specifications for
Real-time, embedded, and high-assurance systems are
listed
separately here.
Don't forget about the various CORBA-UML Profiles, listed
a
ways up this page.
Top
Writing Standards in the MDA
Applications and Frameworks (that is, parts of applications that
perform a particular function) can all be defined in the MDA as a
base PIM that maps to one or more PSMs and implementations. Standards
written this way enjoy two advantages:
- The base PIM is truly a business specification, defining
business
functionality and behavior in a technology-independent way.
Technological considerations do not intrude at this stage,
making it easy for business experts to model exactly the
business rules they want into the PIM.
- Once business experts have completed the PIM, it can be
implemented on virtually any platform, or on multiple
platforms with interoperability among them, in order to meet the
needs of the industry and companies that use it.
OMG Domain Task Forces, after years of writing specifications in
only CORBA, are now writing their base specifications in the
MDA to take advantage of these considerations.
OMG recognizes (based on analogy to the CORBA-based Object
Management Architecture) three levels of MDA-based specifications:
- The Pervasive Services, including
Enterprise necessities such as Directory Services, Transactions,
Security, and Event handling (Notification).
- The Domain Facilities, in industries
such as Healthcare, Manufacturing, Telecommunications,
Biotechnology, and others; and
- Applications themselves, perhaps
created and maintained by a software vendor or end user company
or enterprise using MDA tools to run an MDA-based methodology,
but not standardized by OMG.
Top
The Pervasive Services
This category will include at least
- Directory and Naming Services
- Event Handling/Notification Services
Additional Pervasive Services may be defined, either from the
list of CORBAservices
already standardized by OMG or from other suggestions from OMG
members. Transactions and Security, the other two most popular
CORBAservices, may or may not be part of this group - in the
Component world, transactionality and security are attributes of a
running system, rather than services that a program calls, because
of the way the Component Container or Application Server is set up to run transactionally
and securely as part of an application's environment.
OMG members are already taking the group's well-established
CORBAservice specifications and mapping them back to PIMs where they
can serve all platforms through the MDA development pathway.
Top
Domain Facilities
OMG's Domain Task
Forces started to write their specifications in the MDA in mid-2001,
led by the Life Science Research Domain Task Force, working in
Biotechnology, which was the first Domain Task Force to modify
its
Mission and Goals Statement to reflect its work in MDA.
All of our Domain specifications are
listed on this web page. In addition to the Life Sciences MDA
specifications, other notable MDA-based entries are the
Software-Defined Radio and Super Distributed (that is, ubiquitous)
Objects entries. Our Work in
Progress page lists 15+ ongoing processes adopting new
MDA-based specifications.
Top
MDA Applications
MDA-based development tools
are available now, and
enterprises everywhere around the world starting their application
development by building a PIM instead of writing code. A
representative twenty of them have
posted
their success stories here. Even now, MDA is being used for
large, mission-critical applications including the
F-16
fighter jet mission software and a
two-million-transaction
per day bank payment system. If you're not convinced of the
value of MDA already, look through these stories. We think you'll be
ready to try MDA by the time you've read just a few!
Top
Last updated on
06/27/2012 |
