This article was originally published in the Fall 2003 issue of Methods & Tools
Understanding the Model Driven Architecture (MDA)
Sinan Si Alhir, http://home.comcast.net/~salhir
Introduction
The systems engineering discipline focuses onan elegant universe we call reality wherein the two dimensions of time and spaceestablish the landscape for the intertwining dance between the two naturalforces of change and complexity. It is within this arena that the keyingredients of teams and people, methodologies and processes, and tools andenabling technologies converge to bridge the chasm between vision and reality.However, throughout our system development endeavors, the more complexity weattempt to address, the more change that occurs, and the more change thatoccurs, the more complexity we breed -- it is a vicious circle. Within theinformation 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 aproblem-solving process where requirements maybe considered problems occurringwithin a domain, systems that address the requirements may be consideredsolutions residing within an environment, and problem solving involvesunderstanding 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 applyingthese activities, however every approach must confront the forces of change and complexity.
Figure 1 shows a conceptual view of the systemdevelopment lifecycle process. The domain and environment are shown as circles.The problem and solution are shown as solid-outline rectangles within thecircles. The problem-solving process is shown as a solid-line path from theproblem to the solution, and each perspective is shown as a dashed-line pathfrom 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 arcson the two sides, and models are shown as solid-outline rectangles. When anactivity uses a model as input, a dashed arrow is shown from the model to theactivity. When an activity produces or updates a model as output, a dashed arrowis shown from the activity to the model. Because the requirements modelrepresents the problem and the implementation model represents the solution, adashed 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 otherassociated standards from the Object Management Group (OMG) attempt to confrontthe force of complexity by raising the level of abstraction using models.
A model is a description or representation ofsystem. For example, a Java program is a model of the instructions that a JavaVirtual Machine (JVM) executes. Such models raise the level of abstraction byallowing us to work with more semantically rich Java language instructions thatare more conducive for human consumption rather than Java byte-code instructionsthat are more conducive for JVM consumption. Furthermore, the Java byte-codeinstructions themselves abstract another semantically less expressive levels ofabstraction, and this decomposition by levels of abstraction may continue untilthe 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 languageor collection of modeling techniques for specifying, visualizing, constructing,and documenting the artifacts of a system-intensive process. Within the systemdevelopment lifecycle process, the UML readily enables communication andfacilitates specifying, visualizing, understanding, and documenting problems;capturing, communicating, and leveraging knowledge in solving problems; andspecifying, visualizing, constructing, and documenting solutions. The UML isbroadly applicable to different types of systems (software and non-software),domains (business versus software), and approaches and processes. The UMLenables and promotes (but does not require nor mandate) a use-case-driven,architecture-centric, iterative and incremental and parallel, andrisk-confronting process that is object-oriented and component-based. The UMLemerged from the unification that occurred in the 1990s within the informationsystems and technology industry. Rational Software Corporation and the ThreeAmigos (Grady Booch, James Rumbaugh, and Ivar Jacobson) led the unificationeffort. The UML gained significant industry support from various organizationsvia the UML Partners Consortium and was submitted to and adopted by the OMG as astandard (November 1997). Currently, UML 2.0 is proliferating in the industry.
The Model Driven Architecture (MDA)
The Model Driven Architecture (MDA) and otherassociated standards from the OMG attempt to confront the force of change byseparating and relating platform-independent models and platform-specific modelsusing transformation techniques. A platform-independent model is a model of asystem that does not have any technology-specific implementation information. Aplatform-specific model is a model of a system that has technology-specificimplementation information. For example, a "generic" description of asystem is a platform-independent model, and a description of the system usingJava or Microsoft .NET technology is a platform-specific model. Transformationtechniques convert platform-independent models that specify the operations ofsystems to produce platform-specific models that specify the details of howthose 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 ourunderstanding of the system. Furthermore, transformations between models canrepeatedly occur until a model reaches its targeted platform, whether it is a software or hardware platform.
The MDA is an open and vendor-neutralarchitectural framework that leverages associated OMG standards (and modelsspecifically) within the systems development lifecycle across various domainsand technologies. The MDA broadly supports different types of applicationdomains and technology platforms. The MDA enables transforming or convertingplatform-independent models to produce platform-specific models using mappings.Within the system development lifecycle process, the MDA appliesplatform-independent models and platform-specific models to sustain and leverageinvestments in requirements, technologies, and the lifecycle that bridges thegap between them as they independently change. Such an approach generally leadsto long-term flexibility of implementations, integration, maintenance, testingand simulation as well as portability, interoperability and reusability. The MDAemerged 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 DomainTechnology Committees (DTCs) focus on vertical markets such as Healthcare,Finance, Telecommunications, Manufacturing, Transportation, and so forth tocapture standard domain-specific models that form the foundation forplatform-independent models. Various Platform Technology Committees (PTCs) focuson horizontal technologies such as Web Services to capture standardtechnology-specific models that form the foundation for platform-specificmodels. And the OMG has an Architecture Board (AB) that oversees thestandardization 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 collectionof elements organized together for a specific purpose. A model of a system is adescription or specification of the system and its environment for a specificpurpose, which may be presented graphically and textually. A model-drivenapproach 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, includingfunctionality provided through interfaces and usage patterns. Platforms may begeneric (such as object oriented or batch processing), technology specific (suchas the Java platform), or vendor specific (such as the Microsoft .NET platform).A platform model describes a platform, including its parts and the services itprovides. A pervasive service is a service that is available in a wide range ofplatforms. For example, file services, security services, and so forth. Anapplication refers to some functionality provided by a system. A system is acollection of applications supported by a collection of platforms. Animplementation is a specification that contains all of the information forconstruing and putting a system into operation. For example, a storefront systemmay be a collection of Java programs that provide financial transactionapplications supported by the Java platform, which is described by the JVM Specification platform model.
Figure 2, relative to Figure 1, shows that aplatform corresponds to an environment, a system and its applicationscorresponds to a solution, and an implementation corresponds to an implementation model.
Architecture, Viewpoints, Views, and Models
The architecture of a system involves whatelements make up the system and how they work together to provide thefunctionality of the system, including what parts and connectors make up thesystem and how the parts interact using the connectors. A viewpoint on a systeminvolves a perspective focusing on specific concerns regarding the system, whichsuppresses details to provide a simplified model having only those elementsrelated to the concerns of the viewpoint. A view (or viewpoint model) of asystem is a representation of the system from the perspective of a viewpoint.For example, a security viewpoint focuses on security concerns and a securityviewpoint 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 (ortransformation specification), including rules and other information, fortransforming 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 oftransformation using parameterized models or patterns of model elements that areused as rules in model type mappings and model instance mappings. Figure 3 showsthat marks are used for marking a PIM to produce a marked PIM and that mappingsare used for mapping a PIM or marked PIM to produce a PSM.
Transformations
A model transformation is a process ofconverting a PIM, combined with other information, to produce a PSM. The MDAdefines 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 amarked PIM, and a transformation may ask a practitioner for mapping decisions inthe course of a transformation. A PSM may be an implementation, provideinformation for manually constructing the system, or may act as a PIM forfurther transformation to a PSM. For example, a PIM of a storefront system maybe marked and transformed to produce a PSM for the Java platform and a PSM forthe Microsoft .Net platform. Figure 3 shows how marking and mapping are involvedin transformations. A model type mapping is shown using a PIM while a modelinstance mapping is shown using a marked PIM.
Conclusion
Unequivocally, people are and will remain the"original ingredient" necessary for success. However, with the UML’smodeling techniques and the MDA’s architectural framework, individuals andteams are further empowered not only to simply address change and complexity,but leverage change and complexity for a competitive advantage by capturing andleveraging knowledge encoded in models. Furthermore, it is experience,experimentation, and application of the UML, MDA, and other associated standardsand technologies that will enable us to realize their benefits.