Addressing Problems with Model Driven Architecture

The software development processes have improved dramatically over the last ten years as a result of the release of the Unified Modeling Language (UML). UML is well established as the means to construct, communicate and manipulate the analysis of applications. In conventional practice, a UML model would be used as a guide for the hand-coding of an application by developers. However, organizations still face significant software development challenges when they implement a UML domain model over a software infrastructure:

• Middleware platforms proliferation: The middleware platforms that are most visible today are Enterprise JavaBeans, .NET/COM+, message-oriented middleware and XML/SOAP. Over the past decade or so, the middleware landscape has shifted continuously and shows no signs of ending. It's next to impossible for enterprises to standardize on a single middleware platform. Enterprises have applications on different platforms that simply must be integrated even though this process is time-consuming and expensive. Furthermore, middleware platforms continue to evolve and, in spite of the advantages (sometimes real, sometimes imagined) migration is expensive and, almost all the time, disruptive. Portability and interoperability between middleware platforms is one of the major challenges facing software development in large organizations.
• Business domain evolution: The business objects representing the business domain are in perpetual evolution because business requirements change over time. New business opportunities appear; mergers or acquisitions create and evolve business rules. Letting business requirements and technology evolve at their own pace is another challenge facing application development.
• UML model complexity: This complexity is the result of evolving from a UML analysis model to a detailed UML design model. The analysis model contains only business objects while the detailed design model contains a large set of UML element related to architecture issues. These architectural issues, such as persistence, transactions, and security, are not clearly encapsulated in UML models, making it difficult to abstract architectural concerns and reuse them for different platforms.
• UML model maintenance: When software architecture is modeled in UML, its evolution and maintenance require tedious, repetitive, manual intervention. The architect must ensure that the UML model reflects changes for each instance in which an architecture pattern or decision is used. There is no systematic approach to ensure that the code associated with the architecture implementation is synchronized with the UML model.
• UML model implementation: While there are several benefits to object-oriented programming and UML, these advances do not by themselves eliminate the time-consuming and error-prone tasks of manually mapping a UML model to platform-specific code. Developers may still spend considerable time during the coding phase performing numerous nearly repetitive manual operations. Architects cannot enforce the architecture in platform-specific code unless code reviews are done. Even code reviews are time-consuming and usually can only cover a very small portion of the code.

What is the Model Driven Architecture (MDA)?

The Model Driven Architecture (MDA) initiative from the Object Management Group seeks to create a specification to protect the UML investments made during business domain modeling and to provide adequate agility to encompass the challenges facing implementation of a UML domain model over a software infrastructure. As shown in Figure 1, this goal is accomplished by differentiating between the platform independent model (PIM) and platform-specific models (PSMs).

Figure 1: OMG's Model Driven Architecture

MDA defines an approach whereby you can separate the system functionality specification from its implementation on any specific technology platform. This way, you can have an architecture that will be language, vendor and middleware neutral. For creating MDA-based applications, the first step will be to create a Platform Independent Model (PIM), which you should express in UML.

The PIM represents the logical view in which the composition and behavior of all components (but not their implementation) are fully specified. The PIM serves a function that is similar to that of a refined analysis model. Since the PIM, by definition, does not contain technology details, it is envisaged that the PIM will be mapped to one or more platform-specific models (PSMs). The PSM serves the function of a refined physical model to target platforms such as Microsoft .NET (COM+), Enterprise JavaBeans (EJB) or the CORBA Component Model (CCM). The PSM represents the source code or its UML representation. There will be as many PSMs as there are different implementations of a given PIM.

What are the benefits of MDA?

• Enhanced portability and interoperability between platforms;
• Business models and technologies that evolve at their own pace;
• Improved productivity for architects and programmers;
• Lower cost of application development and management;
• Reduced application time to market by allowing independent reuse of business domain code from platform specific code;
• Lowered risk associated with technology and business requirements evolution.

Who should adopt MDA?

In the long term, because of MDA's benefits, every large enterprise will adopt MDA principles. However, early adopters will be organizations that have strong experience with UML modeling and large enterprises that are starting new projects. You do not start implementing MDA in the middle or at the end of a project. They will implement MDA at early stage for one of two reasons: either because they need to develop applications requiring portability and interoperability between different middleware platforms or because they need business domain code that is loosely coupled with platform specific code in order to gain the flexibility and agility to evolve business requirements independently from technology.

What are the challenges of implementing MDA?

In order to realize the benefits of MDA, a PIM has to be mapped to one or more code PSMs. As well, the one-to-one relationship between a UML PSM and its related code PSM has to be mapped. With the reverse engineering feature of some UML modeling tools, the one-to-one relationship between UML PSM and its related code PSM are already satisfied. Currently, however, there is a gap between the PIM and the code PSM. The current integration of UML modeling tools with integrated development environments (IDEs) does not fulfill that need. In order to close the remaining gap, architects need tools that make it possible to define, view, evolve, enforce and document an application's architecture specification and its architecture implementation.

These tools, which make it possible to model the platform specific issues and to specify how the issue implementation will be linked with the business domain UML elements, are now appearing on the market. One key benefit of these tools is that they do not require programmers to hand-code the PSM code. Rather, they utilize the architecture specification and implementation information to automatically generate 100% of the architectural code associated with a specific platform. The only hand-coding task remaining for the developers is the value-added code related to the business domain (PIM).

What are the impacts of MDA on the software process?

MDA has no significant impact during the Requirement and Analysis phase. However, MDA has a significant impact during the Design and Implementation phase.

During the Design phase, architects must ensure that they do not populate the analysis UML model representing the PIM with platform-specific information. They must create a new UML PSM to model the architecture specification and implementation and document how this new model maps with the UML elements of the PIM. This is a strong challenge if you try to do this task manually with only the help of UML modeling tools because you are not working at the appropriate level of abstraction. However, an MDA-compliant code generation tool will ease the process by providing the necessary tools to specify, document and map the architecture with the PIM. The result of this work will be the detailed design model.

During the Implementation phase, if you use an MDA-compliant code generation tool, the result of the design phase will be used by architects or developers to produce, during the implementation phase, the architectural patterns that will generate the code PSM.

Conclusion

The OMG's MDA initiative can bring major benefits to application development, especially in terms of ROI for UML investment and time to market for software development. In turn, these benefits require efficient architecture management and code generation and open a path to round-trip engineering. However, realizing this potential will require powerful and innovative tools.

About the authors

Michel Brassard is the CTO and founder of Codagen Technologies, the maker of the industry's first MDA-compliant code-generation tool to automate development of enterprise applications from UML models. In this position, Mr. Brassard sets the company's strategic direction and leads its technology vision in product development. Prior to founding Codagen, Mr. Brassard spent 12 years at IBM. Mr. Brassard has authored two patents on code generation and co-authored two books; VisualAge and Transaction Processing in a Client/Server Environment and AD/Cycle Integration: A Re-engineering Case Study. Mr. Brassard holds a Bachelors Degree in Computer Sciences/Mathematics from Laval University in Quebec, as well as a Quebec Securities Commission Degree.

Mario Cardinal is the vice-president, Research and Development, of Codagen Technologies, the maker of Codagen Architect, the MDA-compliant code-generation tool that makes use of XML dynamic templates. In this position, Mr. Cardinal sets the company's operational R&D direction and leads its technology vision in product development. Mr. Cardinal obtained a Bachelor's degree in Computer Engineering as well as a Master's degree in Management of Technology from the Ecole Polytechnique in Montreal, Quebec. He also holds the titles of Microsoft Certified Solution Developer (MCSD) and Microsoft Certified Trainer (MCT).