Understanding the Model Driven Architecture (MDA)

Sinan Si Alhir

Introduction

The systems engineering discipline focuses on an elegant universe we call reality wherein the two dimensions of time and space establish the landscape for the intertwining dance between the two natural forces of change and complexity. It is within this arena that the key ingredients of teams and people, methodologies and processes, and tools and enabling technologies converge to bridge the chasm between vision and reality. However, throughout our system development endeavors, the more complexity we attempt to address, the more change that occurs, and the more change that occurs, the more complexity we breed - it is a vicious circle. Within the information systems and technology industry, the Unified Modeling Language (UML) and the Model Driven Architecture (MDA) are at the heart of confronting these challenges.

Systems Development

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution. Every system development lifecycle process involves the following types of lifecycle activities:

• Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
• Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
• Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
• Testing activities to verify that a system satisfies its requirements.
• Deployment activities to make the system available to its users.

Furthermore, there are many types of approaches or lifecycle models (iterative, waterfall, and so forth) for applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process. The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles. When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents.

Figure 1: Systems Development Lifecycle Process

The Unified Modeling Language (UML)

The Unified Modeling Language (UML) and other associated standards from the Object Management Group (OMG) attempt to confront the force of complexity by raising the level of abstraction using models.

A model is a description or representation of system. For example, a Java program is a model of the instructions that a Java Virtual Machine (JVM) executes. Such models raise the level of abstraction by allowing us to work with more semantically rich Java language instructions that are more conducive for human consumption rather than Java byte-code instructions that are more conducive for JVM consumption. Furthermore, the Java byte-code instructions themselves abstract another semantically less expressive levels of abstraction, and this decomposition by levels of abstraction may continue until the level of abstraction of the software reaches the hardware platform.

The UML is an evolutionary general-purpose, broadly applicable, tool-supported, and industry-standardized modeling language or collection of modeling techniques for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process. Within the system development lifecycle process, the UML readily enables communication and facilitates specifying, visualizing, understanding, and documenting problems; capturing, communicating, and leveraging knowledge in solving problems; and specifying, visualizing, constructing, and documenting solutions. The UML is broadly applicable to different types of systems (software and non-software), domains (business versus software), and approaches and processes. The UML enables and promotes (but does not require nor mandate) a use-case-driven, architecture-centric, iterative and incremental and parallel, and risk-confronting process that is object-oriented and component-based. The UML emerged from the unification that occurred in the 1990s within the information systems and technology industry. Rational Software Corporation and the Three Amigos (Grady Booch, James Rumbaugh, and Ivar Jacobson) led the unification effort. The UML gained significant industry support from various organizations via the UML Partners Consortium and was submitted to and adopted by the OMG as a standard (November 1997). Currently, UML 2.0 is proliferating in the industry.

The Model Driven Architecture (MDA)

The Model Driven Architecture (MDA) and other associated standards from the OMG attempt to confront the force of change by separating and relating platform-independent models and platform-specific models using transformation techniques. A platform-independent model is a model of a system that does not have any technology-specific implementation information. A platform-specific model is a model of a system that has technology-specific implementation information. For example, a "generic" description of a system is a platform-independent model, and a description of the system using Java or Microsoft .NET technology is a platform-specific model. Transformation techniques convert platform-independent models that specify the operations of systems to produce platform-specific models that specify the details of how those systems use the capabilities of their platforms to provide their operations.

By keeping these models separate but related, we can work with the model from the perspective that is most conducive to our understanding of the system. Furthermore, transformations between models can repeatedly occur until a model reaches its targeted platform, whether it is a software or hardware platform.

The MDA is an open and vendor-neutral architectural framework that leverages associated OMG standards (and models specifically) within the systems development lifecycle across various domains and technologies. The MDA broadly supports different types of application domains and technology platforms. The MDA enables transforming or converting platform-independent models to produce platform-specific models using mappings. Within the system development lifecycle process, the MDA applies platform-independent models and platform-specific models to sustain and leverage investments in requirements, technologies, and the lifecycle that bridges the gap between them as they independently change. Such an approach generally leads to long-term flexibility of implementations, integration, maintenance, testing and simulation as well as portability, interoperability and reusability. The MDA emerged from the efforts of the OMG and its constituent members to culminate in 2000. Currently, MDA 1.0 is proliferating in the industry.

The OMG has various Technology Committees (TCs) for providing standardization guidance and recommendations. Various Domain Technology Committees (DTCs) focus on vertical markets such as Healthcare, Finance, Telecommunications, Manufacturing, Transportation, and so forth to capture standard domain-specific models that form the foundation for platform-independent models. Various Platform Technology Committees (PTCs) focus on horizontal technologies such as Web Services to capture standard technology-specific models that form the foundation for platform-specific models. And the OMG has an Architecture Board (AB) that oversees the standardization in order to ensure coherence and consistency of the standards.

Foundation

Figure 2 shows the foundational concepts of what generally constitutes the MDA.

Figure 2: Foundational Concepts of the MDA

Systems, Models, and Model-Driven Approaches

A system (or physical system) is a collection of elements organized together for a specific purpose. A model of a system is a description or specification of the system and its environment for a specific purpose, which may be presented graphically and textually. A model-driven approach focus on models to work with systems, including understating, designing, constructing, deploying, operating, maintaining, and modifying them. Figure 2, relative to Figure 1, shows that the MDA's model-driven approach corresponds to problem solving.

Platforms, Applications, and Implementations

A platform is a set of technologies, including functionality provided through interfaces and usage patterns. Platforms may be generic (such as object oriented or batch processing), technology specific (such as the Java platform), or vendor specific (such as the Microsoft .NET platform). A platform model describes a platform, including its parts and the services it provides. A pervasive service is a service that is available in a wide range of platforms. For example, file services, security services, and so forth. An application refers to some functionality provided by a system. A system is a collection of applications supported by a collection of platforms. An implementation is a specification that contains all of the information for construing and putting a system into operation. For example, a storefront system may be a collection of Java programs that provide financial transaction applications supported by the Java platform, which is described by the JVM Specification platform model.

Figure 2, relative to Figure 1, shows that a platform corresponds to an environment, a system and its applications corresponds to a solution, and an implementation corresponds to an implementation model.

Architecture, Viewpoints, Views, and Models

The architecture of a system involves what elements make up the system and how they work together to provide the functionality of the system, including what parts and connectors make up the system and how the parts interact using the connectors. A viewpoint on a system involves a perspective focusing on specific concerns regarding the system, which suppresses details to provide a simplified model having only those elements related to the concerns of the viewpoint. A view (or viewpoint model) of a system is a representation of the system from the perspective of a viewpoint. For example, a security viewpoint focuses on security concerns and a security viewpoint model contains those elements that are related to security from a more general model of a system.

Figure 2, relative to Figure 1, shows the following viewpoints:

• A computation independent viewpoint (CIV) focuses on the requirements of a system and its environment. The CIV corresponds to the conceptualization perspective.
• A platform independent viewpoint (PIV) focuses on the operation of a system independent of any platform and thus does not change from one platform to another. The PIV corresponds to the specification perspective's analysis activities and model.
• A platform specific viewpoint (PSV) focuses on the operation of system based on a specific platform and thus does change form one platform to another. The PSV corresponds to the specification perspective's design activities and model.

Figure 2, relative to Figure 1, shows the following models:

• A computation independent model (CIM) of a system, from the CIV, describes the domain and requirements of the system. A CIM might consist of a model from the informational viewpoint, which captures information about the data of a system. The CIM corresponds to the conceptualization perspective's requirements model.
• A platform independent model (PIM) of a system, from the PIV, describes the operation of the system independent of any platform. A PIM might consist of a model from the informational viewpoint, which captures information about the data of a system, and a model from the computational viewpoint, which captures information about the processing of a system, independent of any platform. A platform independent model is one that is independent of the features of any specific platform. To achieve platform independence, a model may target a technology-neutral virtual machine. A virtual machine is a collection of parts and services that are independent of any specific platform and may be realized on multiple specific platforms, but the virtual machine remains independent and unaffected by any underlying platform. The PIM corresponds to the specification perspective's analysis model.
• A platform specific model (PSM) of a system, from the PSV, describes the operation of the system as it uses one or more specific platforms. A PSM might consist of a model from the informational viewpoint, which captures information about the data of a system, and a model from the computational viewpoint, which captures information about the processing of a system, based on a specific platform. As a PSM targets a specific platform, it uses the features of the specific platform specified by a platform model. The PSM corresponds to the specification perspective's design model

Application

Figure 3 shows the application concepts of how one generally applies the MDA.

Figure 3: Application Concepts of the MDA

Mappings

A mapping is a specification (or transformation specification), including rules and other information, for transforming a PIM to produce a PSM for a specific platform. The MDA defines the following types of mappings:

• A model type mapping specifies a mapping based on the types of model elements. It specifies mapping rules for how different types of elements in the PIM are transformed to different types of elements in the PSM. For example, if a PIM element is of type entity, it maps to an Enterprise Java Bean (EJB) entity for the Java platform, otherwise it may map to a Java class.
• A model instance mapping specifies how specific model elements are to be transformed in a particular manner using marks. PIM elements are marked to indicate how they are to be transformed. A mark from a PSM is applied to a PIM element to indicating how that element is to be transformed. A PIM element may also be marked several times with marks from different mappings and is therefore transformed according to each of the mappings. A PIM is marked to form a marked PIM that is then transformed to a PSM. For example, if a PIM element is marked as an entity, it indicates that the element is transformed using some rules, perhaps related to an EJB entity for the Java platform, otherwise it may map to a Java class.

A template specifies a particular kind of transformation using parameterized models or patterns of model elements that are used as rules in model type mappings and model instance mappings. Figure 3 shows that marks are used for marking a PIM to produce a marked PIM and that mappings are used for mapping a PIM or marked PIM to produce a PSM.

Transformations

A model transformation is a process of converting a PIM, combined with other information, to produce a PSM. The MDA defines the following types of transformations based on the types of mappings:

• A transformation for a model type mapping is a process of converting a PIM to produce a PSM by following the mapping.
• A transformation for a model instance mapping is a process of converting a marked PIM to produce a PSM by following the mapping.

A practitioner may mark a PIM to produce a marked PIM, and a transformation may ask a practitioner for mapping decisions in the course of a transformation. A PSM may be an implementation, provide information for manually constructing the system, or may act as a PIM for further transformation to a PSM. For example, a PIM of a storefront system may be marked and transformed to produce a PSM for the Java platform and a PSM for the Microsoft .Net platform. Figure 3 shows how marking and mapping are involved in transformations. A model type mapping is shown using a PIM while a model instance mapping is shown using a marked PIM.

Conclusion

Unequivocally, people are and will remain the "original ingredient" necessary for success. However, with the UML's modeling techniques and the MDA's architectural framework, individuals and teams are further empowered not only to simply address change and complexity, but leverage change and complexity for a competitive advantage by capturing and leveraging knowledge encoded in models. Furthermore, it is experience, experimentation, and application of the UML, MDA, and other associated standards and technologies that will enable us to realize their benefits.

More Unified Modeling Language UML Knowledge

• Software Architecture & Unified Modeling Language Zone
• UML Tools

Back to the archive list

This article was originally published in the Fall 2003 issue of Methods & Tools