Building solutions using model-driven architecture (MDA) methods requires changes to the development process. While our experience has been that many of the current best practices for enterprise software development are still applicable, a model-driven approach to the development process requires some important changes to those practices.
In this article, the third and final installment in a series of articles on MDA, we will explore those changes and MDA's application within a modern software development context. In Part I of this series, published in the February 2004 issue of The Rational Edge, we discussed how modeling is used in industry today and the relevance of MDA to today's systems. In Part II, published in April 2005, we examined model-driven development approaches from the perspective of the design and use of a toolkit for MDA at IBM. As we conclude this series with a focus on the development process, we will examine a well-known development process, the Rational Unified Process®, or RUP®, and consider the way that process is interpreted and executed on an MDA project.
A RUP overview
The Rational Unified Process is the de facto standard software engineering process in use today.1 The goal of RUP is to ensure the production of high-quality software that predictably meets the needs of its end users on schedule and within budget. It provides a disciplined approach to assigning tasks and responsibilities within a development organization and has been applied to projects of varying size and complexity, with small teams and large, and with durations lasting weeks to years.
Figure 1 illustrates the overall architecture of the RUP in two dimensions. The horizontal axis represents time and shows the lifecycle aspects of the process. The management perspective of lifecycle phases is shown across the top, and the software engineering and project management perspective of iterations is displayed along the bottom. The vertical axis represents disciplines grouped logically, showing the static aspect of the process -- how RUP is described in terms of process components, disciplines, activities, workflows, artifacts, and roles.
Figure 1. The RUP concepts of disciplines, phases, and iterations
At any point in time during a RUP-based project, there is activity taking place in a variety of disciplines. What distinguishes one lifecycle phase from another is not the total absence of a discipline, but the relative amount of contribution that discipline is making in the overall work streams. The mix of activities varies over time as the emphasis and priorities of the project change. For example, in early iterations you spend more time on requirements; in later iterations you spend more time on implementation.
RUP phases and iterations
From a management perspective, the RUP software lifecycle consists of four sequential phases, each concluded by a major milestone. An assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase. Briefly, the phases of a RUP lifecycle are:
- Inception: The goal of the Inception phase is to reach agreement among all stakeholders on the lifecycle objectives for the project. Typically, there are significant business and requirements risks that must be addressed before the project can proceed. For projects focused on small enhancements to an existing system, the Inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do. The Lifecycle Objectives Milestone is the primary exit criteria of Inception. It evaluates the basic viability of the project.
- Elaboration: The goal of the Elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. Elaboration produces an executable system that marries the essential business requirements with the technical architecture and demonstrates the viability of the technical approach chosen. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The Lifecycle Architecture milestone establishes a managed baseline for the architecture of the system and enables the project team to scale during the Construction phase.
- Construction: The goal of the Construction phase is clarifying the remaining requirements and completing the development of the system based upon the baselined architecture. The Construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense, the management mindset undergoes a transition from the development of intellectual property during Inception and Elaboration to the development of deployable products during Construction and Transition. The Initial Operational Capability milestone determines whether the product is ready to be deployed into a user acceptance environment.
- Transition: The focus of the Transition phase is to ensure that software is available for its end users. The Transition phase can span several iterations; it includes testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine-tuning the product, as well as configuring, installing, and addessing usability issues; all the major structural issues should have been worked out much earlier in the project lifecycle. The Product Release Milestone is the point at which you decide if the objectives of the project were met, and if you should start another development cycle. From a software engineering and project management perspective, things happen day-to-day based on iterations. Phases consist of multiple iterations -- distinct sequences of activities with a base-lined plan and valuation criteria resulting in a release of artifacts (internal or external). Every phase of the lifecycle consists of a series of iterations and the character of the iterations differs depending on where you are in the lifecycle.
RUP and MDA
Currently, RUP provides no specific guidance on how to integrate an MDA style of software development into the overall process. This is not surprising; RUP reflects current industry best practice and typically does not codify approaches until they are well established within the field. MDA is a new and emerging approach, and significant best practice with MDA as applied to RUP projects is only now becoming available.
Our experiences, however, indicate a number of important ways in which we can enhance RUP with best practices for MDA projects. In particular, the backbone of RUP, an architecture-centric and iterative development process, is highly consistent with MDA concepts and offers an excellent basis for succeeding with MDA.
However, there are some areas where additional guidance on MDA is appropriate. Here, we indicate a number of the important aspects to consider in applying RUP to an MDA project.
- Elaboration is the main phase impacted by an MDA project. It is important to look at Elaboration activities and briefly describe MDA modifications.
- The Architect role is the main role in Elaboration that requires additional consideration. As a specialization of "Architect," the MDA Architect role is appropriate to many MDA projects. Essentially, this role defines specific MDA activities and artifacts, creates the transformations, and so on. Hence, the primary MDA artifacts from this role are mapping documents, transformations, and UML profiles.
- MDA is as much about model-driven automation as it is about model-driven architecture. This provides some guidance as to how to view MDA and RUP. Typically, MDA automates activities within RUP. Rather than change RUP activities, MDA augments them with additional tasks aimed at supporting automation of a number of the primary RUP activities.
- The application of MDA involves many RUP roles, but they typically will not require additional activities. Rather, the standard activities in each role will require details to be added regarding how those activities are automated using the specific tools and MDA techniques chosen. In RUP, we call these additional details RUP Tool mentors. For example, a team working on object-relational data mapping may be using a modeling tool with a set of MDA transformations. But at a high level their workflow related to "define design classes" will largely remain the same.
- More pervasively, the primary changes to RUP consist of a more subtle change of perspective on the development process. MDA encourages architects and developers to work at higher levels of abstraction than typically expected in non-MDA projects. This is most apparent during construction where the code automation aspects of MDA significantly change the emphasis of the implementation tasks. Developers are able to continue to work with more abstract analysis and design models as inputs to MDA transformations. They find that they work less with actual implementation models and source code, and more with designs for the appropriate business-focused workflow of the solution. A smaller subset of developers will be implementing the model-to-code transformations themselves.
- MDA transformations are frequently constructed around pre-built solution frameworks (also called "Reference Architectures" or "Application Frameworks"). The MDA transformations augment these frameworks with domain-specific business logic. This approach of coupling MDA and solution frameworks makes a great deal of sense since the entire MDA approach is centered on automating a set of repeatable techniques and assets. However, it further changes the development process toward greater emphasis on reuse, management assets, and incremental delivery of solutions.
Using MDA to customize a solution framework
Today's enterprise software systems are rarely (if ever) developed from scratch, line-by-line, in an IDE. Rather, they are created by extending an existing solution framework with domain-specific business logic, by connecting to (and manipulating) information from different sources, and by designing context-rich user display and interaction services. Hence, the development approach that is followed is not the classic "waterfall" scenario, where requirements gathering is followed by analysis and design, leading to the implementation of the system. Rather, it is one of continual extension and refinement of an existing partial solution toward a desired goal through a set of iterations that add value to the solution.
These partial solutions that form the heart of a new system may come from one of several sources:
- An existing set of applications. The primary approach may be to take an existing solution and extend it in useful ways, as dictated by the business need. Hence, much of the design work involves understanding how those existing applications are architected, and where meaningful extensions can be added without compromising the qualities of the existing applications. In most cases, the process is complicated by the fact that the original applications were not designed with the goal of reuse in mind.
- A proprietary application framework used by the organization. Having built many kinds of similar solutions in a particular domain, some organizations have extracted core application capabilities as reusable proprietary services to be employed in future solutions. These services help to improve productivity of a family of systems that share common characteristics, and increase the predictability of future system development. An example is Accenture's General Reusable Netcentric Delivery Solution (GRNDS) Framework2 .
- An acquired application framework, whether open source or commercial in origin. Recognizing the consistent architectural patterns that are used in designing certain kinds of applications has led to a number of technologies to help organizations create solutions conforming to those patterns. The resulting application frameworks are available both commercially and in the open source community, and are delivered as standalone frameworks or bundled with tools that help create, manage, and extend those frameworks. Examples include the Struts and JSF frameworks for creating certain kinds of n-tiered J2EE solutions.
- A set of extensions and customizations to packaged applications. Many organizations acquire comprehensive solutions for key business processes from packaged application vendors. However, organizations typically need to customize those solutions to meet their needs. As a result, the packaged application vendors 1) have structured their solutions to support different kinds of extension and customization, 2) offer well-defined APIs to access internals of the packaged application, or 3) augment the packaged applications with detailed design documents, extension examples, and package-specific tools.
Given these possibilities, the primary task faced by many IT project managers is to create a clear understanding of their domain, to express that understanding in a platform-independent domain model supporting various kinds of analysis to ensure its correctness and consistency, and to map that domain model to a platform-specific implementation realized by extending the solution framework. Model-to-model transformations help in refining the domain, while model-to-code transformations map the domain model to the specific solution framework.
In model-to-code transformations, the solution framework plays a key role, because it constrains and guides the kinds of transformations that are meaningful. For example, if you're using a Struts-based application framework, the application being created has a well-understood structure, including well-known extension points where business logic will be realized. You can create a set of transformations based on that knowledge. Indeed, you can created wizard-driven tooling to automate creation of those transformations for domain models containing appropriate kinds of information. This is the way, for example, in which tools, such as IBM Rational Application Developer®, use domain-focused visual design tooling to automate code generation for Struts or Java ServerFaces (JSF)-based application frameworks. More generally, by using a solution framework as the basis for a system, the task of writing model-to-code transformations is significantly eased, and we gain greater efficiency, predictability, repeatability, and manageability of the resulting solutions.
In summary, we reiterate that software is rarely created from scratch, and that model transformations (to another model or to code) help leverage existing solution frameworks. As this approach of building on existing software increases, the role of MDA and its value increases by helping to automate how we extend and customize those frameworks. Some view this "custom automation" as the only viable option for creating systems of increasing complexity, and in response to the constraints placed on us by the components and technologies we deploy.
Summary and future directions
Model-driven approaches to software and system development have been in use for some time. More recently, the focus of attention has been on how to increase automation of model-driven technologies based on the OMG's MDA approach. MDA techniques enable organizations to construct custom automations for model-to-model and model-to-code transformations. Using these transformations, technical experts can share their expertise across a large development team. In particular, MDA offers a number of advantages over other approaches:
- Productivity of development is increased by helping to insulate a majority of developers from technical details that they do not need to consider to carry out their task of designing enterprise solutions to meet a business need. More time is spent focusing on their task at hand: implementing the business capabilities of the system.
- MDA improves quality by encouraging reuse of known patterns of behavior, building on existing architectural designs, and leveraging expertise more effectively. The use of automation also promotes consistency and improves the quality of the system design and implementation, particularly as the solution evolves through maintenance and upgrade.
- MDA's repeatable set of practices is well-suited to today's iterative development requirements, because MDA enhances predictability of the development process and the delivered solution itself. The use of automation speeds up development, particularly when many of the tasks of the developer are repetitive and cumbersome.
In this series of articles, we have explored many of the practical aspects of realizing an MDA approach based on our use of modeling techniques in general, and the design and use of a specific MDA Toolkit for IBM Rational XDE for Java. These experiences reveal that, while traditional design and implementation practices are relevant to MDA projects, there are a number of additional requirements that must be addressed to ensure that the approach is optimally applied. We have described many of these requirements and illustrated them with practical examples.
In Part 2, we distilled our key findings into 12 lessons for practical application of MDA. These lessons, however, are not specific to a single set of technologies. They have also been applied within other IBM Rational tools. Based on our experiences with existing technologies and practices, including those reported here, the latest set of solutions from IBM Rational support MDA development projects by providing capabilities we believe are essential. As a result, IBM Rational Tools provide a rich set of functionality for all types of automation, including predefined out-of-the-box transformations and tools for customizing transformations.3 The latest example of this support for MDA is seen in the IBM Rational® Software Architect product. This is an extensive workbench of design and construction services supporting various aspects of analysis, design, and implementation of enterprise systems, including sophisticated model authoring and management capabilities to support visual modeling in UML. Specific to MDA projects, the IBM Rational Software Architect product contains an extensive custom pattern authoring environment, and supports authoring of model-to-model and model-to-code transformations in several ways (depending on preferred style and design goals):
- Generic plugins (using the Eclipse plugin development environment)
- Pluglets (small, easily installable automation assistants useful for quick one time automation tasks)
- Transformations (a rules-based framework for structuring large and complex transformations)
Supporting these technologies is a set of best practices that assist organizations to adopt model-driven approaches. Integrated with the IBM Rational Software Architect product is context-specific process guidance for development using techniques based on RUP. Furthermore, this guidance can be augmented with project-specific additional practices and reusable assets available from online sources (such as IBM developerWorks).4
The work reported in this paper has been carried out by a number of people, and it is our pleasure to acknowledge their contribution. The ideas discussed here reflect the thinking of a broad team at IBM, including Grady Booch, Gary Cernosek, Jim Conallen, Pete Eeles, Sridhar Iyengar, Simon Johnston, Grant Larsen, Martin Nally, Jim Rumbaugh, and Bran Selic. We also thank Mike Perrow for his helpful reviews of the paper.
 J. Rumbaugh, G. Booch, I. Jacobsen, "The Unified Modeling Language Reference Manual," Second Edition, Addison-Wesley, 2004.
 P. Kruchten, "The Rational Unified Process: An Introduction," Addison-Wesley, 1998.
 P. Kroll and P. Kruchten, "The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP," Addison-Wesley, 2004.
 Evans Data Corp., "North American Development Survey: Volume 1," Response to question on "Use of UML in Application Design," Fall 2003.
 Codagen, www.codagen.com.
 ArcStyler, www.arcstyler.com.
 AndroMDA, www.andromda.org.
 openMDX, www.openmdx.org.
1 See, for example, P. Kruchten, "The Rational Unified Process: An Introduction," Addison-Wesley, 1998.
3 For more details, see http://www.ibm.com/rational/mda.
4 For more details, see http://www.ibm.com/developerworks/rational.