Model-driven architecture has been around ever since modeling became a popular way of documenting and designing applications. However, the term and the concept itself received some formalization by the Object Management Group (OMG) sometime after 1997. (The OMG is a nonprofit software industry consortium whose charter includes providing a common framework for application development.)
As OMG puts it, "MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology or technologies in which it will be implemented. MDA divorces implementation details from business functions. Thus, it's not necessary to repeat the process of modeling an application or system's functionality and behavior each time a new technology (for example, XML or SOAP) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once."
Most MDA implementations are tied closely to unified modeling language (UML) as a means of describing the architecture. Initially, you develop a computation independent model (CIM), which is essentially a business model of the system. It's an abstraction of the system that shows it in the environment in which it will operate while hiding the details of the system's structure and leaving the processing details undetermined. Following this model is the platform-independent model (PIM), which describes the system in a lot more detail without being specific about platform or language. Finally, there's the platform-specific model (PSM), which is used to tie the description of the system in the PIM directly to the platform and language being used. This model can then usually be transformed directly into code and other supporting implementation artifacts.
For instance, at the CIM level, you may simply have an analysis component that's marked as a boundary object. At the PIM level, that boundary object is then transformed into a series of components labeled as persistence objects. Finally, at the PSM level (if you're using J2EE), the persistence objects are then transformed into EJB entity beans. With each transformation, the architect is free to mark objects as needed and change the structure of things, but the idea is that the changes are reflected both up and down the model chain and finally into executable code. At the highest level, the architecture comprises nothing but requirements, activity workflows, and high-level ideas of components and subsystems. This highest level hides all the complexities of architecture and the technologies that implement it. Thus, it lets users at a business level communicate with an architect directly about what they need and lets architects easily put these requirements into a framework in which they can then transform these high-level needs into concrete enterprise applications.
Automation is the Answer
This ability would all be for naught if there weren't tooling available to ease the work behind MDA. And that's where the term 'automated' MDA becomes so important both to facilitate the work of employing MDA as well as reducing the amount of manually introduced errors into the process. Many third-party vendors are now creating tools and transformations that do some or all of the PIM to PSM conversions for you. In addition, many of these tools keep a traceability log between the high-level ideas and the final executable components. Tie this methodology to an iterative development life cycle, and you have enterprise applications that are easy to define and deploy and will meet stakeholders' needs.
Although MDA isn't a new concept, it's only begun to become an important strategy for developing powerful enterprise applications. The introduction of automation to this methodology is the key to making it successful. On the one hand, you can keep the complexities inherent in your software; on the other, you can define your requirements and architecture without taking those complexities into account.
Automation offers mechanized transformations between the less complex, high-level models and low-level code. Although tweaking and business logic still needs to be completed at the code level, a lot of the work has already been done for you. In the end, it leaves you with a highly reusable enterprise application developed quickly while meeting the immediate needs of the business. Automation doesn't necessarily make enterprise development easier, but it sure makes it a little less painful.
Michael J. Hudson [[email protected]] is a software architect for Praxis Engineering Technologies in Annapolis Junction, Md. His current work includes developing enterprise architectural solutions for both commercial and government clients.