What Is Model Driven Architecture?
Model Driven Architecture (MDA) is a term defined by the Object Modeling Group (OMG—www.omg.org) as an approach to system development that increases the power of models. By being model-driven, the approach provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance, and modification. [OMG1]
MDA isn't a new concept, but it is gaining more acceptance as the standards for defining architectures and developing applications become increasingly stable. Standards such as XML, CORBA, WSDL, XMI, and others provide a mechanism for approved ways of interchanging information between systems and software. When combining standards with tools for the creation of applications, you can create applications driven from architectures designed independently of the deployment technology.
By creating transformations between models in the UML and development technology languages, such as Java, C++, Visual Basic, and C#, and using the standard technologies to bridge the differences, you can create applications based on architectural designs. With technologies such as XML being used as a transformation language, you can model an architecture in the UML without concerning yourself with the deployment platform. Then, development can transform the designs created by architects into code. That code can and most likely will need to be customized at some point, but essentially the architectures that were designed are out of the way, ensuring that if a good architecture was defined, it will be implemented in the same way.
 | The most common way to achieve Model Driven Architecture (MDA) is by creating UML models of the logical application, generating first-cut code from those models, and then creating stub classes and some basic method code. The application at this point will need a lot of hand coding to create the business logic and tie the overall application together. This type of MDA is not what everyone would consider as the mission of MDA, but it is the most common and the most easily implemented for organizations that are not yet ready to bite off the entire vision. It ensures that architectures are designed prior to writing code, which helps to eliminate some poor designs but still puts the power of the application in the developer's hands. Another way to implement MDA is by using a tool that enables you to model the overall application, including business logic, the base application, and the user interface, in a generic format, and then selecting a deployment platform to which it will generate. There are tools on the market today that can help you accomplish this tactic. They help organizations that do not have extensive technical knowledge but that need to generate applications using the latest technology. These tools raise the level of abstraction for the users so that you can model without a substantial knowledge of the deployment platform, and yet they enable you to build the application needed. When developing software using this type of tool, you can create a Java application the first time but then generate Visual Basic the second time because the level of abstraction is raised above deployment platforms. These are two examples of ways to implement MDA, but they are the extremes. The first drives part of the application from the model, and the second drives the entire application from the model. You can achieve MDA using other methods that fall between these two extremes. Although MDA is driven from a model and ends up with a running application, what sits between the model and application is what really drives the overall methodology: the standards. For example, having an XML model that is generic but mapped both to UML and the deployment environment enables the UML model to be transformed to XML and then transformed again to Visual Basic (for example), driving the full transformation from a generic model to a specific technology. |
|
