Section A.1. What Is MDA?

A.1. What Is MDA?

MDA is the natural evolution of UML, Object Oriented Analysis and Design (OOAD), code generators, and third millennium computing power. At the highest level, MDA envisions the day that UML models become the standard way to design and build software. Business software developers will build their systems through MDA tools. Development in 3GL languages such as Java or .Net will remain a toilsome necessity for the system level. For business applications, current languages will be too inefficient to be viable, used only by the most backward-looking organizations. As an analogy, consider the place of assembler and C (or even C++) in main-line business applications today.

MDA uses models to get the highest leverage out of software development. MDA isn't a development process. It isn't a specification. It isn't an implementation. It isn't a conformance suite. It doesn't have a reference implementation. The OMG, wisely, has avoided specifying how you go about leveraging software models. MDA has not matured, so each of the nearly 50 companies committed to MDA promote vastly differing visions. If you find this confusing, you aren't alone.

MDA defines a framework for processing and relating models. MDA tools transform pure business models into complete, deployable, running applications with a minimum of technological decisions. Modifying the pure business model behind an application require only updates in the dependent technological area(s). Technology decisions unrelated to the change remain, so the application can be regenerated in a matter of a few minutes.

An application has many concerns; some related to the business itself, some related to a particular implementation tier, some related to a particular implementation technology. MDA further separates the technological concerns of an application from the business; it separates high-level technical decisions from their technological implementation; it separates one technology from another. Web forms or database tactics don't complicate the business concepts of, say, Account and Customer. Transaction management decisions don't affect persistence. Messaging doesn't interfere with property management or security. Each technology can be replaced without recoding. In the extreme case, the business application can be redeployed on a completely different technology platform.

MDA keeps these separate concerns in different models, while at the same time keeping the system consistent and coherent as a whole. The concept of account, for example, permeates most or all of the models: business, web, database, persistence, business logic, business delegate, and code. Not only is any one model consistent within itself, but also the concepts from one model relate to the corresponding concepts in other models. Changes in the concept of account must affect all related models. This notion moves significantly ahead of current non-MDA modeling tools that either model everything in one model or require manual synchronization of separate models.

Although ultimately hoping to eliminate all programming languages, current MDA tools can't provide enough finesse to deliver varied and high quality systems without a hybrid approach of UML and 3GL. MDA allows handcoded extensions and other tweaking throughout the abstraction layers. It remembers the origins of these changes so that subsequent generations of the system respect them.

MDA tools are sophisticated systems. No offering has established itself as a leader. Most of the MDA offerings cater to niche markets. Most predate MDA, so they drag along baggage of a less well-defined approach, or of a well-defined but narrow proprietary approach. None manages highly abstract models and generates crack code and generates a variety of implementations, at least not yet. Though a one-size-fits-all offering doesn't exist, many offerings are very productive. The goal of MDA, while simple to voice, has yet to be fully implemented.