![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In the two earlier companion articles, you learn how a model-driven development (MDD) approach can improve the business value and architectural integrity of your software solutions:
- Implement model-driven development to increase the business value of your IT system: Discover the advantages of using modeling tools from IBM Rational software discusses how MDD can deliver value.
- Combine patterns and modeling to implement architecture-driven development: Capturing your architectural decisions explicitly explains how MDD supports an architecture-driven approach to development.
In this article, MDD is discussed in the context of other related initiatives taking place in the industry. You learn about the role of the Object Management Group (OMG) industry standards body in MDD and see how the software factories approach compares with MDD. In addition, various techniques of visualizing development artifacts as models and executing models directly with an executable UML approach are examined.
Recapping model-driven development
In MDD, models are used not just as sketches or blueprints, but as primary artifacts from which efficient implementations are generated by the application of transformations. In MDD, application domain-oriented models are the primary focus when developing new software components. Code and other target domain artifacts are generated using transformations designed with input from both modeling experts and target domain experts.
OMG and model-driven architecture
The OMG is an open consortium that produces standards for interoperability in the enterprise application space. The OMG is responsible for the Unified Modeling Language (UML) that is central to MDD and is also driving the model-driven architecture (MDA) initiative. MDA is a formalization of an MDD approach, such as the one that Rational software has promoted for years. As defined by the OMG, MDA is a way to organize and manage enterprise architectures, supported by automated tools and services, for both defining the models and facilitating transformations between different model types.
The terms MDA and MDD are often used interchangeably. In this article, MDD refers to the activity that is carried out by software developers. MDA is reserved for its formal OMG definition that is more focused on creating a formal framework in which MDD can operate. The OMG's MDA guide describes MDA as having three primary objectives:
- Portability
- Interoperability
- Reusability
The goal is to achieve these objectives by separating the specification of the operation of a system from the details of the way the system is realized on a particular platform. MDA enables tools to help meet these objectives by doing the following tasks:
- Specifying a system independently of a platform
- Specifying platforms
- Choosing a platform for the system
- Transforming the system specification into a specification for a particular platform
The notion of platform is central to OMG MDA. A platform is a realization of interfaces and usage patterns by a set of subsystems and technologies that an application can use, without concern for the details of how the platform is implemented.
MDA defines three kinds of models:
- Computation-independent model (CIM)
- Describes the requirements for a system and the business context in which the system will be used. The model typically describes what a system will be used for, not how it is implemented. CIMs are often expressed in business or domain-specific language and make only limited reference to the use of IT systems when they are part of the business context.
- Platform-independent model (PIM)
- Describes how the system will be constructed, without reference to the technologies used to implement the model. This model does not describe the mechanisms used to build the solution for a specific platform. A PIM may be appropriate when implemented by a particular platform or it may be suitable for implementation on many platforms.
- Platform-specific model (PSM)
- Describes a solution from a particular platform perspective. It includes the details that describe how the CIM can be implemented and how the implementation is realized on a specific platform.
Transformation from a PIM to a PSM is at the heart of MDA. The process of transforming one model to another in the same system is called model transformation. Figure 1 shows the transformation of a PIM, possibly with additional information, into a PSM.
Figure 1. Transformation of a PIM to a PSM
MDA does not treat these models as fixed layers, but explains that PIMs and PSMs can be layered, with each model being a PSM with respect to a more abstract model, and a PIM with respect to a more concrete model. For example, you could have a high-level design model, a detailed design model, and an implementation model with two occurrences of the MDA pattern. At each level, you can introduce further assumptions regarding the implementation platform. The detailed-design model is a PSM, with respect to the high-level design model, and a PIM, with respect to the implementation model.
There is much discussion in the MDA community about whether a PIM should first be transformed into a non-code PSM and then to code, or whether it is permissible to generate code directly from a PIM (meaning that your PSM is the code). When working with the Java™ 2 Platform, Enterprise Edition (J2EE) and Java platform, Rational Software Architect (RSA) visualizes code artifacts as UML diagrams. This capability gives you the advantages of being able to visualize platform artifacts while avoiding the need for an extra level of transformation. In this article you model applications as PIMs and then transform those models into PSMs, which are captured directly as implementation artifacts.
Much of what is presented here is also appropriate for transitions between other modeling layers. For example, when following the Rational Unified Process (RUP), you can begin with an analysis model that is then transformed into an outline of a design model. You could also transform a WebSphere Business Modeler model into a PIM that acts as a specification for software development. Rational Software Architect includes such a transformation and can import WebSphere Business Modeler models.
The white paper, "An MDA Manifesto," articulates the IBM vision for MDA. It introduces the three basic tenets of MDA, as shown in Figure 2 and Figure 3.
Figure 2. Three basic tenets of MDA
The concepts of direct representation, automation, and open standards are at the core of the model-driven approach.
Figure 3. Basic tenets of the MDA manifesto (from IBM)
Software factories and domain-specific languages
A domain-specific language (DSL) is a software development language that has been developed for a particular problem domain. Examples of DSLs are spreadsheet macros and database query languages. DSLs have a long history in the software industry, but they have currently been gaining attention as part of the Software Factories initiative from Microsoft®.
A software factory is defined as:
...a software product line that configures extensible development tools like Visual Studio Team System with packaged content like DSLs, patterns, frameworks and guidance, based on recipes for building specific kinds of applications. For example, you could set up a software factory for thin-client customer relationship management (CRM) applications using the .NET® framework, C#, the Microsoft Business Framework, Microsoft SQL Server, and the Microsoft Host Integration Server. Equipped with this factory, you could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers. Better yet, you could use this factory to create an ecosystem by making it available to third parties, who could extend it to rapidly build CRM applications incorporating their value-added extensions.
There is an overwhelming similarity between MDD and the software factory approach. Both approaches advocate working with application domain concepts and introducing automation into the software life cycle. Both approaches emphasize the importance of visual modeling and capturing expertise through patterns. The main difference between the approaches is the emphasis that is put on open standards, particularly UML.
The MDD approach to creating DSLs is to introduce UML profiles that extend and constrain UML for a particular use. For example, there are UML profiles for software services (SOA), testing, and business modeling.
The role of UML is often explained in overly simplistic terms: MDD advocates the use of UML for all domain-specific modeling, while the software factory approach advocates that UML never be used. This is an incorrect statement of the positions of both approaches.
While the MDD approach treats UML, with customization, as the modeling language of choice for most application modeling, it also acknowledges the value of custom languages in certain specialized circumstances. This is the purpose of the OMG Meta-Object Facility (MOF) standard, which plays an important role in MDD. UML itself is defined using MOF, and there are MOF definitions of many other languages. The MDD approach acknowledges the value of non-UML DSLs as a technique to be applied judiciously.
The software factory approach does not reject UML entirely. It suggests that you use UML for developing sketches and documentation, whereas non-UML DSLs should be used for developing models from which code is generated. (Visual Studio 2005 Team System Modeling Strategy and FAQ provides more information.)
As you can see in Table 1, there are advantages and disadvantages to using UML as the basis for DSLs.
Table 1. Advantages and disadvantages of using UML profiles as DSLs
| Advantages | Disadvantages |
|---|---|
| UML is an open standard modeling language, with many available books and training courses. UML is a recognized and transferable skill for software developers. | UML profiles only permit a limited amount of customization. It is not possible to introduce new modeling concepts that cannot be expressed by extending existing UML elements. For example, UML is not a suitable basis for a DSL for designing electrical circuit diagrams. |
| UML profiles provide a lightweight approach that is easily implemented using readily available UML tooling. In the future, it may be possible to generate tooling for DSLs, but some customization is still likely to be needed. | Use of UML does require familiarity with modeling concepts. In some cases, domain experts may have knowledge that can be used for code generation, but they may not have the expertise to express these concepts using UML. |
| Models with UML profiles applied can be read by all UML tools, even if they don't have any knowledge of the profile. In some cases, the extensions introduced by the profile will be ignored. | |
| Basing all DSLs on UML creates a set of related languages that share common concepts. This makes new profiles more readily understandable and enables models expressed using different DSLs to be integrated easily. Having a set of models expressed using different DSLs replicates the middleware integration problem at the modeling level, which is clearly not desirable. | |
| UML can be used for high-level architectural models and detailed models from which code can be generated. Provides consistency throughout the software life cycle, enabling users to move seamlessly from modeling-in-the-large to modeling-in-the-small. Using UML only for sketches and documentation misses this opportunity for consistency. |
While UML is the appropriate basis for many DSLs, some cases need an alternative approach for parts of the MDD process. Try using the following techniques instead of, or in addition to, UML:
- MOF-based language
- In cases where a custom language is appropriate, use MOF to define a new language. The Eclipse Modeling Framework, an open source component included with Rational Software Architect, generates a Java implementation for working with a MOF-defined language and basic Eclipse tooling to create an instance of models in the language.
In the future it is likely that the generation of full graphical editors will be possible. This technique is the one to use to implement many of the languages that Rational Software Architect supports, including UML and XSD. Take care with this approach to ensure that the language is integrated with UML and other non-UML DSLs that are used in the same solution context.
- Custom user interface
- For some users, a visual modeling approach might not be appropriate for capturing their expertise. A custom tool with step-by-step guides and custom graphical elements might be more suitable for populating models. Clearly this approach has further cost associated with it, but it is a useful technique to apply in the right circumstances.
- Transformation from an existing format
- Information that is needed to drive an MDD tool chain may already be captured in an existing tool. It might be another software modeling tool, a business modeling tool, or a desktop tool such as Microsoft Excel. Any information that can be accessed can be transformed into UML models. Particularly for preexisting assets, use this approach to generate models rather than manually modeling the same information.
Visualization is the technique of viewing implementation artifacts as UML models. Such models are platform specific, but they hide some of the implementation detail that can detract from the overall architecture of an application.
Rational Software Architect supports visualization of Java and J2EE artifacts. This mode of working is a way of getting some of the benefits of modeling while using a code-centric approach. When using visualization, code is the primary artifact and models are generated from code. Models are not persisted (although their layout information is); they are simply visualizations of the code. Figure 4 shows a simple J2EE project and its corresponding UML visualization.
Figure 4. Visualization of an entity bean
The model is generated from the code, not the other way around. Visualization is made easier when a model, often in-memory, of the visualized artifacts is available so there is no need to parse a textual representation of the artifacts. This is an example of using non-UML models within an MDD tool chain.
Visualization provides some of the benefits of a model-driven approach:
- Some implementation detail can be hidden to allow a design-level view of a system.
- UML models and code are kept synchronized, avoiding mismatches between documentation and implementation.
Although visualization can be valuable, it can only raise the level of abstraction in a very limited way. When using visualization, we are restricted to hiding details of the concepts supported by the platform. There are two main ways in which visualization is used in model-driven development. Visualization is:
- A step toward MDD. In addition to having direct benefits of its own, visualization improves the familiarity of developers with UML modeling. This familiarity can ease the transition to an MDD approach.
- A useful technique for working with platform-specific UML models. Instead of maintaining an intermediate implementation model between the application models and the implementation artifacts, you can generate code directly but still have the benefit of visualizing the implementation model.
Executable UML does not refer to UML that has execution semantics. (UML has execution semantics, although they could certainly be strengthened and formalized in some areas, and UML 2.0 improved these semantics significantly.) Executable UML is normally associated with treating UML as a complete programming language, not just for the expression of high-level semantics, but for expressing complete executable models. Such models are executed either on a UML virtual machine or through compilation to a lower-level programming language.
The alternative to executable UML, and the current common practice in MDD, is to switch to a lower-level programming language to fill in the details. An executable UML approach has the advantage that developers do not need to learn multiple languages (UML and the target language or languages). All development and debugging is carried out at the modeling level.
UML does provide support for expressing detailed semantics through its actions and activities. However, the only notation provided for these constructs is a visual notation. It is generally agreed that a textual language is more efficient for capturing detailed semantics, such as mathematical algorithms and text processing.
A number of executable UML languages, including textual notations for actions, has been defined and currently an executable UML standard is under development at the OMG.
A further variant on this approach is to embed snippets of a lower-level programming language into UML models. This is the approach taken by the Rational Technical Developer tool (formerly Rational Rose Real-Time), which embeds Java or C++ snippets into an executable UML model.
In this article, you discovered how the OMG's MDA initiative is working to formalize the ideas of MDD and to provide standards in support of the approach. You explored the term MDD, which refers to a development approach that is broadly in line with the formal MDA under development at the OMG.
MDD also has much in common with other initiatives, such as Microsoft's Software Factories and domain-specific languages. Although there are important differences between these approaches, such as the significance of standards to MDD, they also have many similarities.
Visualization of existing artifacts as UML models can be a step toward adopting a UML approach. It achieves some of the benefits of model-driven development, but in a very limited manner.
An executable UML approach lifts development up completely to the modeling level. This approach has been successful in certain domains, but has yet to see widespread adoption.
Learn
- Implement model-driven development to increase the business value of your IT system:
Discover the advantages of using modeling tools from IBM Rational software (developerWorks, Jan 2006): Read this related article that explains the business drivers influencing current IT development and introduces you to MDD.
- Combine patterns and modeling to implement architecture-driven development:
Capturing your architectural decisions explicitly (developerWorks, Feb 2006): Read this related article to learn more about using patterns and MDD to reduce complexity in your work.
-
Get more details about Rational Unified Process.
-
Get more information about Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, by Greenfield; Short; Cook; Kent; Crupi. (John Wiley & Sons; August 2004. ISBN 0-471-20284-3)
-
Read the book titled, Model-Driven Architecture with Executable UML, by Raistrick; Francis; Wright; Carter; Wilkie. (Cambridge University Press; March 2004. ISBN 0-521-53771-1)
- Executable UML: A Foundation for Model-Driven Architecture, by Stephen Mellor and Marc Balcer. (Addison Wesley; May 2002. ISBN 0-201-74804-5)
- An MDA Manifesto: This article is part of an ongoing discussion in the pages of MDA Journal that lays out the high points of IBM's MDA vision.
-
Read the IBM Redbook, "Patterns: Model-Driven Development Using IBM Rational Software Architect."
- Search for Web services books at Safari Bookshelf.
-
Keep your skills and knowledge current with free
developerWorks
technical events and Webcasts.
Get products and technologies
-
Build your next modeling project with free trial downloads of
IBM
Rational Software Architect, IBM
Rational Software Modeler, and IBM
WebSphere Business Modeler, all available for download directly from developerWorks.
-
Check out additional
IBM
trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Get involved in the developerWorks community! Participate in developerWorks
blogs to collaborate and get help from your peers.
Dr. Tracy Gardner is a Solution Architect in the IBM Software Group Services in the U.K. She has more than five years of industrial experience in model-driven development. She has written and presented extensively on model-driven development. She holds a Ph.D. in software engineering from the University of Bath. Contact Tracy at tgardner@uk.ibm.com.
Larry Yusuf is a Solution Architect with Software Group Strategy and Technology, based at the Hursley Labs in the U.K. He has four years of experience in business integration and modeling, with an emphasis on business process management, event and solution management, and integration patterns. He has written and presented extensively on these topics. Contact Larry at yusuf@uk.ibm.com.
