| A group in Canaxia is looking to adopt the model-driven architecture (MDA) for some new development efforts. The group is composed of some software architects and modelers who are excited about applying this implementation-independent approach to technology. Myles Standish talks with a few of the software modelers in this group and reviews their plans to bring this methodology into the enterprise. The modelers are fairly up to date with the semantics for MDA, but they have found many of the tools necessary to translate these models into their implementations to be either buggy or unavailable yet for specific platforms. Though it is an excellent academic approach to technology solutions, Myles is not convinced that this approach is ready for Canaxia. A model-driven architecture defines an approach to modeling that separates the specification of system functionality from the specification of its implementation on a specific technology platform. In short, it defines guidelines for structuring specifications expressed as models. An MDA promotes an approach where the same model specifying system functionality can be realized on multiple platforms through auxiliary mapping standards or through point mappings to specific platforms. It also supports the concept of explicitly relating the models of different applications, enabling integration, interoperability, and supporting system evolution as platform technologies come and go. The MDA is based on the idea that a system or component can be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs). As the name implies, PIMs do not take technology-specific considerations into account, a concept that is equivalent to logical models in the structured methodologies and to essential models within usage-centered techniques. The CIBMs represent the business requirements and processes that the system or component supports, and the PICMs are used to model the logical business components, also called domain components. PSMs bring technology issues into account and are, effectively, transformations of PIMs to reflect platform-specific considerations, see Figure 5-3. Figure 5-3. MDA overview. 
The MDA is part of a collection of modeling-oriented standards from the Object Management Group (OMG). These standards include the following: XML Metadata Interchange (XMI). XMI is a standard interchange mechanism used among various tools, repositories, and middleware. XMI also can be used to automatically produce XML (DTDs) and XML schemas from UML and MOF models, providing an XML serialization mechanism for these artifacts. Unified Modeling Language (UML). UML defines the industry-standard notation and semantics for object-oriented and component-based systems. Common Warehouse Metamodel (CWM). CWM is the OMG data warehouse standard and is a good example of applying the MDA paradigm to an application area. Meta Object Facility (MOF). The MOF provides the standard modeling and interchange constructs that are used in the MDA. The common foundation of the MOF the UML and CWM are both MOF-based, enabling the potential model/metadata interchange and interoperability among tools. The MOF is the mechanism through which models are analyzed in XMI.
Other mappings among the various types of models describe a system/component: mappings that represent transformations. For example, there is a mapping between the CIBM and the PICM for a given system, and from the PICM to the PSM for a system. It is these mappings that provide the glue among the various representations of a system/component, mappings that a sophisticated development tool perhaps would be able to use to generate system code. The relationships among models in different systems/components are also a critical aspect of the MDA. For example, there are relationships among the CIBMs of each system, their PICMs, and their PSMs. These relationships support integration among the systems, and thus promote large-scale reuse within an organization. It's important to recognize that a CIBM, PICM, or PSM may be comprised of several artifacts. For example, a CIBM could include a collection of business rule definitions and a UML activity diagram used to describe the overall business process supported by the system/component. A PICM could be described via a UML component model and a collection of interface definitions. A PSM could be comprised of a UML class diagram, several UML sequence diagrams, several UML state chart diagrams, and a physical data model. Furthermore, you may decide to have several PSMs for any given system/component, one for each platform on which you intend to deploy it. Benefits and Shortcomings of the MDA The MDA has the following primary strengths: The MDA defines a coarse separation of views. When you are modeling, it is important to consider issues such as what the system should do and what processes the system should support, without having to worry about how it will support them because it enables you to consider a wide range of options. It can also be beneficial to consider the logical domain architecture separately from the physical implementation architecture because the logical architecture will change much more slowly than the underlying technologies, allowing you to reuse your logical model as the system evolves over time. The MDA defines a viable strategy for system integration. The MDA's explicit support for modeling relationships among systems and components can help to ease system integration, and hence can promote greater levels of reuse, within your organization. Legacy integration is a significant issue for most software development efforts. The MDA may motivate a new breed of modeling tools. The separation of views offers the potential for tools that automatically generate the next model down, in particular PSMs from PIMs, based on automated mappings. The MDA may support tool integration. Part of the overall vision of the OMG is to provide a set of standards for tool vendors to follow, and thereby to support integration of those tools.
Although the MDA is interesting, and in the near term will probably gain significant support from the OMG and its supporters, you should be aware of several potential challenges: There are other competing, and arguably better, strategies for system integration. The OMG isn't the only organization working on the issue of system integration. For example, there is the entire Web services strategy supported by technologies such as .Net and Sun ONE and various Internet standards bodies. Web services are something that developers understand and are eager to work with it, unlike the MDA. Common Object Request Broker Architecture (CORBA), another standard developed by the OMG, is also a viable option. Luckily for the MDA, developers will need tools and techniques to understand the interfaces to Web services and CORBA objects, something that the MDA may be well suited for. The wonder tools will prove elusive. The idea that you can (mostly) automate the creation of platform-specific models from your platform-independent models is theoretically sound. However, this will probably only occur within niche technical environments. The underlying technology changes too quickly and by the time the automated mappings are in place for a given platform, it will have changed or will no longer be in demand. Furthermore, there is a plethora of platforms. Both of these factors will force tool vendors to choose a subset of platforms to support. Tool integration will also prove elusive. Each tool vendor is compelled to support the MDA in their own way, if they support it at all. This can be attributed to the fact that vendors will not be interested in opening up their technologies to potential competitors . . . The MDA is complicated. The underlying premise of the MDA is that developers will have significant modeling skills. Although this is an ideal vision, it isn't realistic. Most developers struggle to create UML State Charts or use case models, if they even know what these models are. The MDA doesn't appeal to developers. When was the last time you heard a programmer say "I'd really like to work on an MDA project"? When was the last time you bumped into a programmer who even knew what the MDA was? The MDA might appeal to academics and professional modelers who haven't written a line of code in years, but that's about it. There is a bias toward object-and component-based technologies. Because the MDA is based on the UML, and the UML is used to model object- and component-based systems, there is an underlying assumption that components will be your underlying building blocks.
|
