Download (direct link):
64 Chapter 2
approach, since designing a component of a system in a way that is abstracted from implementation does in a sense defer detailed implementation decisions. However, in iterative development all levels of abstraction are revisited frequently, so abstraction is not really deferral in the XP sense.
There is also a danger that the practice of delaying design can be taken as a license to develop software without architecture. This may work for individual applications, but it does not scale up to developing enterprise-scale systems that encompass many applications and components.
Model driven approaches to database and GUI development have been entrenched in enterprise computing for some time. MDA builds on this and other gains made in enterprise computing by bringing a model driven approach to the intermediate tiers of enterprise systems and to EAI and B2Bi.
Major aspects of MDA's impact on enterprise computing include:
■ Raising the level of abstraction of the programming environment
■ Using formal models that drive code generators and also raise the bar of engineering discipline
■ Integrating metadata based on different specification languages
■ Encapsulating pattern knowledge in generators
■ Generating components on demand
■ Using Design by Contract to drive generation of assertion checking, exception handling, and testing harnesses
UML, UML profiles, and the Meta Object Facility (MOF) make up an extensible MDA modeling language environment. A mature model driven enterprise architecture must include properly positioned standardized and company-specific MDA-based languages. It also must include mappings from those languages to technologies of concern.
MDA extends Interactive Design's notion of putting interaction design in the hands of interaction experts. It does so by putting the specification of business semantics in the hands of business experts.
MDA is compatible with XP in many respects, although the two will diverge if XP is misused by an IT shop as an excuse to avoid defining a real enterprise architecture.
I Two I
The Base MDA Technologies
Several bodies are defining standards that form the base upon which MDA will be constructed and that are gradually being implemented in the industry. This part of the book looks at these technologies in some detail and provides some insights into how to use them effectively.
The Role of UML in MDA
This chapter provides an overview of the role that the Unified Modeling Language (UML) plays in MDA. Rather than provide a primer on the basics of UML, I refer the reader to the many books on the subject.1 However, subsequent chapters delve into specific UML topics that are particularly important for MDA.
Origins and Evolution
As object-oriented analysis and design (OOAD) techniques spread during the early 1990s, the OOAD industry balkanized into three camps, roughly corresponding to the followers of Grady Booch, Ivar Jacobson, and Jim Rumbaugh. Each had its own notation, methodological approaches, and tools.
In the late 1990s the camps merged to create UML. The merger began when Rational Software Corporation brought Rumbaugh and Jacobson into the company to join Booch. The three pioneers—now known as the "three amigos"—wrote the first UML specification. Later, they decided to submit UML to the Object Management Group (OMG) for standardization.
1 For an excellent and concise UML primer see [FOW 1997].
68 Chapter 3
UML has become a widely used standard for object-oriented modeling. UML tools are available from a number of vendors. The OMG now owns the UML trademark and logo and manages the standard's evolution.
As of this writing, the current version of UML is 1.4. There may be one more minor revision in the UML 1.X2 series before UML 2.0 takes shape. When this book refers to features of UML, the reference is to UML 1.X unless otherwise stated.
This section outlines some of the key features of UML that help support MDA.
Separation of Abstract Syntax from Concrete Syntax
Early versions of UML focused mostly on the graphical notation, specifying the semantics (meaning) of the various graphical shapes and lines. More recent versions include a formal model of UML's own semantics. This model defines the concepts that UML modelers use and associates them with an abstract syntax rather than with the syntax of the graphical notation. The graphical notation is a concrete syntax for expressing the abstract syntax. Other concrete syntaxes are possible.
This formal model of UML is referred to as the metamodel of UML. We can think of a metamodel as a model of a model. A model of a bank includes elements named Account, Customer, Fund, and so on because these are the things that make up a bank. A model of a model includes elements named Class, Attribute, Operation, Parameter, Association, and so on because these are the things that make up a model. A metamodel models those things that constitute models as shown in Figure 3.1, which is part of the abstract syntax for the UML metamodel. Notice that the abstract syntax looks like an ordinary UML class model, except for the fact that the names of the elements refer to UML concepts rather than user concepts such as accounts and customers.