The OMG published a document called the "MDA Guide" during the summer of 2003. The table below provides the document's details:
The guide provides the most current description of the MDA approach. It gives details of how it should be used and information on the other standards adopted by the OMG that support it.
The contents of the MDA Guide have been treated as a set of requirements which have been slightly engineered to produce the table below:
| Reference | Heading | Statement |
| 1 | OMG Vision and Process |
| 1.1 | The OMG Vision | Most software continues to be written ignoring the realities of constantly shifting infrastructure and constantly changing requirements. |
| 1.2 | Enter Modeling | The interest in modeling data and applications has picked up significantly. |
| The promise of the MDA approach is to allow definition of machine readable application and data models. |
| The MDA allows for: a flexible implementation infrastructure in which a new technology can be integrated; automatically producing data integration bridges; making maintenance much simpler; and allows for flexible testing and simulation. |
| 1.3 | Modeling is Evolutionary | The MDA is really just another evolutionary step in the development of the software field. |
| The magic of software automation from models is truly just another level of compilation. |
| Compilers exist that translate data and application models defined in UML to high level languages and to platforms that implement existing and any future systems. |
| 1.4 | The Object Management Group | The OMG was formed to help hasten the introduction of software applications by managing complexity and reducing costs. |
| The OMG is accomplishing this goal through the introduction of the MDA architectural framework with supporting detailed specifications. |
| The OMG is an international trade association incorporated as a nonprofit corporation in the United States with affiliate organizations around the globe. |
| 1.5 | The OMG Process | The OMG Board of Directors (BoD) approves standards on a technology-by-technology basis. |
| Each Technology Committees (TC) provide technical guidance and recommendations to the BoD. |
| The Platform Technology Committee (PTC) focuses on horizontal standards such as MOF and UML. |
| Domain Technology Committee (DTC) generates standard models in vertical markets. |
| An Architecture Board (AB) ensures coherence and consistency of the standards. |
| 1.6 | Conclusion | The goal of interoperability for existing and future systems can be achieved by agreeing on models and how to translate between them. |
| 2 | Introduction to MDA |
| 2.1 | Introduction |
| 2.1.1 | Background | In about 1995 the OMG adopted the UML standard. |
| In 2001 the OMG adopted the MDA framework. |
| The MDA is an approach to using models in software development. |
| 2.1.2 | Overview | The MDA provides an approach that separates the specification of the operation of a system from the details of the way that it uses the capabilities of its platforms. |
| The goals of MDA are portability, interoperability and reusability through architectural separation of concerns. |
| 2.2 | The Basic Concepts |
| 2.2.1 | System | In the MDA approach, a system may include anything; discussion tends to focus on software within the system. |
| 2.2.2 | Model | A model of a system is a description or specification of that system and its environment for some certain purpose. |
| A model is often presented as a combination of drawings and text. |
| The text may be in a modeling language or in a natural language. |
| 2.2.3 | Model Driven | The MDA approach provides a means for using models to direct the course of understanding and design. |
| 2.2.4 | Architecture | The architecture of a system is a specification of the parts and connectors of the system and the rules for their interaction. |
| The MDA prescribes certain kinds of models and how they relate. |
| 2.2.5 | Viewpoint | A viewpoint on a system is a technique for abstraction in order to focus on particular concerns within that system. |
| Abstraction is the process of suppressing selected detail to establish a simplified model. |
| Concepts and rules may be considered to form a viewpoint language. |
| The MDA specifies a computation independent viewpoint, a platform independent viewpoint and a platform specific viewpoint. |
| 2.2.6 | View | The view of a system is a representation of that system from the perspective of a chosen viewpoint. |
| 2.2.7 | Platform | A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented. |
| 2.2.8 | Application | An application refers to functionality being developed. |
| A system is described in terms of one or more applications supported by one or more platforms. |
| 2.2.9 | Platform Independence | The platform independence of a model is the degree to which that model is independent of the features of a platform of any particular type. |
| 2.2.10 | MDA Viewpoints |
| 2.2.10.1 | Computation Independent Viewpoint | The computation independent viewpoint focuses on the environment of the system and the requirements for the system. |
| 2.2.10.2 | Platform Independent Viewpoint | The platform independent viewpoint focuses on the operation of a system while hiding the details necessary for a particular platform. |
| A platform independent view may use a general purpose modeling language or a language specific to the area in which the system will be used. |
| 2.2.10.3 | Platform Specific Viewpoint | The platform specific viewpoint combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system. |
| 2.2.11 | The Computation Independent Model (CIM) | A computation independent model is a view of a system from the computation independent viewpoint. |
| A CIM is sometimes called a domain model. |
| 2.2.12 | Platform Independent Model (PIM) | A platform independent model is a view of a system from the platform independent viewpoint. |
| A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type. |
| A common technique for achieving platform independence is to target a PIM for a technology neutral virtual machine platform. |
| A virtual machine is defined as a set of parts and services which are defined independently of any specific platform. |
| 2.2.13 | Platform Specific Model (PSM) | A platform specific model is a view of a system from the platform specific viewpoint. |
| A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform. |
| 2.2.14 | Platform Model | A platform model provides a set of technical concepts representing different kinds of parts, services and elements. |
| A generic platform model can amount to a specification of a particular architectural style. |
| 2.2.15 | Model Transformation | Model Transformation is the process of converting one model to another model of the same system. |
| The PIM and other information are combined by the transformation to produce a platform specific model. |
| Transformations are not necessary for PIMs based on virtual machines. Instead, it is the PIM of the virtual machine itself that needs to be transformed to a PSM for a particular platform. |
| 2.2.16 | Pervasive Services | Pervasive services are services available in a wide range of platforms. |
| MDA will provide common platform independent models of pervasive services. |
| 2.2.17 | Implementation | An implementation is a specification that provides all the information needed to construct a system put it into operation. |
| 3 | How is MDA Used? | Model transformations form a key part of MDA. |
| 3.1 | CIM | A CIM is sometimes called a Business Model. |
| A CIM describes the situation in which the system will be used and provides a source of a shared vocabulary for use in other models. |
| CIM requirements should be traceable to PIM and PSM constructs. |
| A CIM consists of one or more UML models. |
| 3.2 | PIM | A PIM information model is different from a CIM information viewpoint model. |
| A PIM will be suited for one or more architectural styles. |
| 3.3 | Platform Model | A PSM will be expressed in UML and OCL. |
| 3.4 | Mapping | A MDA mapping provides specifications for transformation of a PIM into a PSM. |
| 3.4.1 | Model Type Mappings | Model type (object) mappings specify mappings from types specified in the PIM to types specified in the PSM. |
| Mappings may also specify mapping rules in terms of instance values. |
| 3.4.1.1 | Metamodel Mappings | A metamodel mapping is a specific example of a model type mapping. |
| The types of model elements in the PIM and the PSM are both specified as MOF metamodels. |
| The metamodel mapping results in the generation of instances of types in the PSM metamodel. |
| 3.4.1.2 | Other Type Mappings | The types available to model the PSM or PIM may not be specified as a MOF metamodel when expressed in other languages, including natural language. |
| 3.4.2 | Model Instance Mappings | Map PIM model elements to PSM model elements. |
| 3.4.2.1 | Marks | An element of the PIM is marked to indicate how it is to be transformed to a concept in the PSM. |
| Marks are not part of the PIM or PSM. |
| 3.4.3 | Combined Type and Instance Mappings | Most type and instance mappings will be used in combination. |
| Marks can be used to indicate non-functional or stylistic characteristics of the PSM independently from the PIM. |
| 3.4.4 | Marking Models | Marks may come from model types and roles, UML profile stereotypes, MOF model elements, or a metamodel. |
| A mark may provide a requirement on the transformation to a PSM. |
| Marks may be structured, constrained or modelled. |
| Some marks may need one or more parameters. |
| A set of marks may be specified by a mark model, which can used with different mappings. |
| The mark model may be supplied with a UML profile. |
| 3.4.5 | Templates | A mapping may also include templates, which are parameterized models that specify particular kinds of transformations. |
| Templates can be used in model type mappings to transform a pattern of PIM elements into another pattern of PSM elements. |
| Marks can be used indicate instances in a PIM which should be transformed according to a template. |
| Marks can be used to specify which values in a PIM fill the parameters in a template. |
| 3.4.6 | Mapping Language | A transformation description may be in natural language. It may also be an algorithm in an action language or model mapping language. |
| Model mappings will be specified in the MOF Query/Views/Transformations standard. |
| 3.5 | Marking a Model | Several PIM elements can be marked to indicate their roles in a mapping. |
| An element of the PIM may be marked one or more times to indicate its role in several mappings. |
| When an element is marked several times, it will be transformed according to each of the mappings and accumulate features in the PSM. |
| In model type transformations where rules are applied to automatically generate a PSM, there may be insufficient information in the mark model. The user will be asked for additional mapping information that is recorded in the mark model. |
| 3.6 | Transformation | Transformations produce a PSM from the mapping and a marked PIM. |
| 3.7 | Direct Transformation to Code | A tool might transform a PIM directly to code without producing a PSM. |
| 3.8 | Record of Transformation | The record of transformation details the mapping of elements from the PIM to the corresponding elements of the PSM and also which parts of the mapping were used in the transformation. |
| A MDA modeling tool that keeps a record of transformation may keep a PIM and PSM in synchronization when changes are made to either. |
| 3.9 | PSM | The PSM produced by the transformation is a model of the same system specified by the PIM. |
| The PSM specifies how a system makes use of the chosen platform. |
| A PSM will be an implementation if it provides all the information needed to build a system. |
| A PSM may act as a PIM that is used for further refinement to a PSM. |
| A PSM that is an implementation provides information that may include program code and configuration specifications. |
| 3.10 | Model Transformation Approaches | There are several approaches that can be used for transforming models. |
| 3.10.1 | Marking | A mapping for a platform is prepared which includes a set of marks. |
| The marks are used to mark elements of the model. |
| The marked PIM is transformed using the mapping to produce the PSM. |
| 3.10.2 | Metamodel Transformation | The mapping is specified by selecting concepts in the metamodels. |
| A PIM is prepared using the UML platform independent profile specified by a metamodel. |
| A PSM is prepared using the UML platform specific profile specified by a metamodel. |
| The transformation specification in terms of a mapping between metamodels is prepared. |
| The mapping guides the transformation of the PIM to produce the PSM. |
| 3.10.3 | Model Transformation | Types specified in models are used for the mapping. |
| A PIM is prepared using platform independent types specified in a model. |
| The elements in the PIM are subtypes of the platform independent types that declare generic capabilities and features. |
| The elements in the PSM are subtypes of the platform specific types. |
| A specification of a transformation for a platform is prepared. |
| The transformation specification is in terms of a mapping between the platform independent types and the platform dependent types. |
| 3.10.4 | Pattern Application | The model and metamodel mapping approaches can be extended to include patterns in addition to the platform independent types. |
| Both the types and patterns can be mapped to platform specific types and patterns. |
| The metamodel mapping approach can also use patterns. |
| The marked model approach can be extended to include patterns. |
| The PIM is marked with the names of design patterns that are specific to a platform. |
| 3.10.5 | Model Merging | There are several MDA approaches that are based on merging models that produce a PSM from a PIM. |
| 3.11 | Additional Information | Additional information can be supplied to guide the transformation from PIM to PSM. |
| Information can be added to produce the marked PIM. |
| More information can be added when the marked PIM is further transformed to produce the PSM. |
| 4 | MDA Transformations | The PIM is transformed to be a PSM specific to a particular platform. |
| 4.1 | Degrees and Methods of Model Transformation | Transformations can use different mixtures of manual and automatic transformation. |
| There are different approaches to putting into a model the information necessary for a transformation from PIM to PSM. |
| 4.1.1 | Manual Transformation | Design decisions are considered and taken in the context of a specific implementation. |
| The MDA approach adds value by explicitly distinguishing between a PIM and the transformed PSM and recording the transformation. |
| 4.1.2 | Transforming a PIM Prepared Using a Profile | A PIM may be prepared using a platform independent UML profile. |
| This model may be transformed into a PSM expressed using a second, platform specific UML profile. |
| The transformation may involve marking the PIM using marks provided with the platform specific profile. |
| A UML profile enables the specification of a transformation by supplying rules using operations. |
| 4.1.3 | Transformation Using Patterns and Markings | A mapping specification includes patterns and marks. The marks correspond to elements of the patterns. |
| In model instance transformations, marks are used to prepare the marked PIM. |
| The marked elements of the PIM are transformed according to the corresponding pattern to produce the PSM. |
| Several patterns may be combined to produce a new pattern. A new mark is specified for use with the new pattern. |
| In model type transformations, rules will specify that all elements in the PIM which match a particular pattern will be transformed into instances of another pattern in the PSM. |
| Marks will be used to bind values in the matched part of the PIM to the appropriate slots in the generated PSM. |
| In this usage the target patterns can be thought of as templates for generating the PSM, and the use of marks as a way of binding the template parameters. |
| 4.1.4 | Automatic Transformation | There are contexts in which a PIM can provide all the information needed for implementation, and there is no need to add marks or use data from additional profiles, in order to be able to generate code. |
| Mature component-based development is a context where middleware provides a full set of services and where the necessary architectural decisions are made once for a number of projects, all building similar systems. |
| These decisions are implemented in tools, development processes, templates, program libraries, and code generators. |
| In such a context, it is possible for an application developer to build a PIM that is complete as to classification, structure, invariants, and pre and post conditions. |
| The developer can then specify the required behavior directly in the model, using an action language. |
| This makes the PIM computationally complete. The PIM contains all the information necessary to produce computer program code. |
| The tool interprets the model directly or transforms the model directly to program code. |
| 4.2 | Kinds of Input to Transformation |
| 4.2.1 | Patterns | Generic transformation techniques can work with patterns supplied by the architect. |
| Different patterns may be chosen by the architect or by a transformation tool using supplied selection criteria. |
| When specifying type based transformations, patterns describe groups of concepts in the PIM that correspond to a concept or group of concepts in PSM. |
| Tools can be made responsible for matching the patterns in the PIM and using the patterns in the PSM as templates. |
| 4.2.2 | Technical Choices | Technical choices are made by the architect to guide the transformation. |
| Technical choices might also be made by the analysis tools during transformation. |
| Choices in most transformation approaches will be made by both the architect and the tool. |
| 4.2.3 | Quality Requirements | A range of quality of service requirements can be used to guide transformations. |
| Transformation choices will be made according to the particular qualities required at each conformance point in the model. |
| 5 | Other MDA Capabilities |
| 5.1 | Multi-Platform Models | Many systems are built on more than one platform. |
| A transformation can use marks from several different platform mappings to transform a PIM into several PSMs. |
| 5.2 | Federated Systems | A PIM can specify a system with several parts, each under separate control. |
| The transformation of that PIM to a PSM can be made recognizing that the system is federated. |
| That PIM can also be transformed into different PSMs for use by different parts of the system. |
| This approach will require the identification of bridges between the platforms. |
| If a generic interoperability mechanism is available, the PIM will allow generation tools to create the bridges. |
| 5.3 | Multiple Applications of the MDA Pattern | The MDA pattern includes a PIM, a class of platforms and a PSM which is specific to the class of platforms. |
| What counts as a PIM depends on the class of platform that the MDA user has in mind. |
| The MDA pattern can be applied several times in succession. |
| A PSM resulting from one application of the pattern will be a PIM in the next application. |
| 5.4 | General Model to Model Transformations | The same approaches that enable transformation of a PIM to a PSM can be used to transform any model into another related model. |
| 5.5 | Reuse of Mappings | Mappings may be reused in several ways. |
| 5.5.1 | Extension | Extension adds to the properties of a base mapping to create a derived mapping by incremental modification. |
| Mappings can be arranged in an inheritance hierarchy according to derived base mapping relationships. |
| Inheritance is multiple if mappings can have several base mappings. |
| Inheritance is strict if the suppression of properties from the base mappings is prohibited. |
| 5.5.2 | Combination | Combination uses two or more mappings to create a new mapping. |
| The ways in which mappings may be combined include sequential combination and concurrent combination. |
| 5.6 | Enabling Interoperability | An interoperability mapping uses mappings for two different platforms. |
| These are combined to create a mapping to transform a PIM into a PSM in which some objects are on one platform and others on the second. |
| This mapping is then extended further to include connectors that bridge between the two platforms and specifications for the use of these connectors in a transformation. |
| The resulting mapping is used to transform a PIM into a PSM of a system that makes use of both platforms and provides for the interoperability of the subsystems on the different platforms. |
| 6 | Using the MDA Pattern | The MDA pattern may be applied more than once. |
| An original PIM is an application model which is represent by a rectangle divided into three. |
| A platform is represented by a bent horizontal line with two vertical bent lines joined near the ends. |
| Depending on the viewpoint taken, lower level platforms may be hidden and considered to be part of the implementation of higher level platforms. |
| A platform goes all the way down to a complete implementation. |
| A PSM is not required to include all details necessary to implement the platform because it may make implicit or explicit reference to the specifications of those platform capabilities it uses. |
| Either these specifications are available to complete the PSM or actual platforms are available which will provide the support required to complete the implementation. |
| If a PSM does not include a detailed model of a platform it may either make reference to other models that provide the details or it is an abstract model that hides the details. |
| A model is not a PSM unless it can be used to produce an implementation. |
| What counts as a platform depends on the kind of system being developed and is relative to the purpose of the modeler. |
| A PIM of a middleware system appears to be a PSM from the point of view of an original PIM application developer. |
| 7 | MDA and Standards |
| 7.1 | The MDA Technology Base | The MDA approach is enabled by a number of technologies that have been adopted by the OMG. |
| OMG specifications for these technologies are available here. |
| 7.1.1 | UML | The Unified Modeling Language (UML) is a standard modeling language for visualizing, specifying and documenting software systems. |
| Models used with MDA can be expressed using UML. |
| 7.1.2 | MOF | The Meta Object Facility (MOF) technology provides a model repository that can be used to specify and manipulate models. |
| The MOF encourages consistency in manipulating models in all phases of the use of MDA. |
| 7.1.3 | MOF Models | The Common Warehouse Metamodel (CWM) is a MOF model. |
| 7.1.4 | Profiles | A profile is a UML extension mechanism that applies to the language specification. |
| A UML profile specifies a new modeling language by adding new kinds of language elements or restricting the language. |
| The UML profile may be used to build a model. |
| The new or restricted language elements defined in a UML profile may be applied to specific elements of an existing model. |
| Any number of profiles can be applied to an existing model by extending or restricting elements of that model. |
| The application of a profile to a model can be removed, leaving the model as it was before the profile was applied. |
| 7.1.5 | Platforms | The OMG has adopted a number of specialized platform technologies. |
| 7.2 | Examples of an Adopted MDA Technology | The UML Profile for EDOC specification is an example of the application of MDA. |
| The EDOC profile defines a set of modeling constructs that are independent of specific middleware platforms. |
| The modeling constructs may be used as marks. |
| The UML Profile for EDOC define PSMs for some specific middleware platforms such as EJB. |
| Mappings from a EDOC profile to middleware models are also defined to facilitate the transformation of a EDOC defined PIMs into corresponding PSMs. |
| Transformation is enabled either by using a model mapping approach where the models are prepared following the EDOC specification or by using a marking approach where a generic UML PIM is marked according to the EDOC profile. |
| Any model is platform independent or platform specific only relative to some particular class of platforms. |
| 7.3 | What OMG Adopts |
| 7.3.1 | The Adoption Process | OMG adopts specifications by explicit vote on a technology-by-technology basis. |
| The specifications selected each satisfy the architectural vision of MDA. |
| OMG bases its decisions on both business and technical considerations. |
| Once a specification is adopted by OMG it is made available to all. |
| 7.3.2 | What Is Adopted | OMG technology adoptions include a PIM and at least one transformation specification that produces a PSM and an implementation of the same for at least one platform. |
| Specifications may also include the PIM to PSM mapping used and the record of the transformation that produced the PSM. |
| OMG adopts specifications that are expressed in terms of models that exploit the MDA pattern. |
| 7.3.2.1 | Service Specifications | These are domain-specific, cross-domain or middleware services where “Platform” usually refers to middleware. |
| “Platform Independent” means independent of middleware and “Platform Specific” means specific to a particular middleware platform. |
| The PSM may be expressed in a UML profile or MOF compliant language that is specific to the platform concerned. |
| Alternatively, the specification may express the PSM in the language that is native to the platform in question. |
| 7.3.2.2 | Data Model Specifications | A PIM is independent of a particular data representation syntax. The PSM is derived by mapping a PIM onto a particular syntax. |
| 7.3.2.3 | Language Specification | The abstract syntax of the language is specified as a MOF compliant metamodel. |
| 7.3.2.4 | Mapping Specifications | These contain one or more transformation models or textual correspondence descriptions. |
| 7.3.2.5 | Network Protocol Specifications | The MDA pattern can be used to specify network protocols by viewing network transport layers as platforms. |
| 7.3.3 | Domain Models | The many OMG domain technology adoptions each have an implicit model that is partly expressed in an IDL specification. |
| Domain technologies adopted in the future can be expected to provide explicit normative PIMs expressed using UML augmented by normative PSMs. |
| 7.3.4 | Platform Independent Models | The OMG and vendors will prepare a generic library of reusable PIMs. |
| 7.3.5 | Platform Models | MDA platform models may be made available as UML models in MOF repositories, MOF models, UML profile models or languages specified using the MOF model. |
| 7.3.6 | UML Profiles | Work has started on UML profiles for CORBA, EDOC, enterprise integration and real-time platforms. |
| 7.3.7 | UML Family Languages | Extensions to the UML language will be standardized for specific purposes. |
| 7.3.8 | Model and Metamodel Mappings | The capability to specify model transformation mapping in complete detail are likely to be incorporated into future versions of UML. |
| Work is underway on transformation specification technology for MOF that facilitates model and metamodel mappings. |
| 7.3.9 | Architectural IDEs / MDA Tools | MDA envisions automatic transformation of a marked PIM into a PSM. |
| 7.3.10 | Conformance Testing | To support the MDA, the OMG must concentrate on conformance testing, certification and branding of products.
|
