UML 2: a model-driven development tool.

INTRODUCTION

The early part of the 1990s saw heightened interest in the object paradigm and related technologies. New programming languages based on this paradigm, such as Smalltalk, Eiffel, C++, and Java **, were defined and widely used. These were then accompanied by a prodigious and confusing glut of object-oriented software design methods and modeling notations. For example, in his very thorough overview of object-oriented (OO) analysis and design methods (covering over 800 pages), Ian Graham lists over 50 seminal OO methods. (1) Given that the object paradigm consists of a relatively compact set of core concepts, such as encapsulation, inheritance, and polymorphism, there was clearly a great deal of overlap and conceptual alignment across these methods, much of it obscured by notational and other differences of little or no consequence. This caused much confusion and needless fragmentation, which, in turn, impeded adoption of this extremely useful paradigm. Developers were forced to make difficult and binding choices between mutually incompatible languages, tools, methods, and vendors. The fragmentation also made it very difficult to find experts who were sufficiently fluent in the language chosen, leading to additional training costs.

For this reason, when the Unified Modeling Language ** (UML **) initiative was announced by

Rational * Software, the reaction by the software development community was overwhelmingly positive. UML started as an amalgamation of the two most popular OO methods of the time: the OMT method of Rumbaugh et al. (2) and the Booch method. (3) The primary authors of these two methods, Jim Rumbaugh and Grady Booch, were later joined by Ivar Jacobson, whose OOSE method was noted for its seminal contribution to requirements-driven software construction processes, based on the now familiar notion of use cases. (4) Following this initial effort, which provided a homogenous conceptual and notational framework, a number of leading methodologists and thought leaders were invited to critique and to contribute to UML. Particularly notable was the contribution of David Harel, whose statechart formalism (5) was adapted and then adopted as one of the core elements of the language.

The intent behind UML was not invention but consolidation. The result was a synergistic blending of the best features of the various OO languages, methods, and notations into a single vendor-independent modeling language and notation. This open quality is one of the main reasons why UML very quickly became a de facto standard and, following its adoption by the Object Management Group (OMG **) in 1996, a bona fide industry standard. (6-8)

Since then, UML has been widely adopted and is supported by the majority of major modeling tool vendors. It has also been incorporated as an essential part of the computer science and engineering curricula in universities throughout the world and in various professional training programs. Last but not least, it is being used extensively by academic and research communities as a convenient lingua franca and is itself the subject of significant research.

UML has also helped raise general awareness of the value of software modeling as a means for coping with the complexity of modern software. Although this highly useful technique is almost as old as software itself (flowcharts and finite state machines are early examples of software modeling), the majority of practitioners have generally been slow in accepting it as anything more than a minor power assist. Because this is still the dominant attitude, model-based development methods are encountering a great deal of resistance.

Even though some of this can be ascribed to an irrational fear of change, there are some valid reasons why practitioners doubt the value of models. Probably the most important is that experience has shown that software models are often wildly inaccurate, sometimes obscuring fatal design flaws behind fancy but ambiguous graphics. Clearly, the practical value of any model increases with its accuracy. If a model cannot be trusted to tell us what we need to know about the software system that it represents, then it can be even worse than useless because it can lead to the wrong conclusions. The key, then, to increasing the value of software models is to narrow the semantic gap between them and the systems they are modeling. However, as we shall explain later, it turns out that this is far easier to do with software than with any other engineering medium.

Much of the inaccuracy of software models is due to the extremely detailed and sensitive nature of current programming languages. Minor lapses and barely detectable coding errors, such as misaligned pointers or uninitialized variables, can have enormous but generally unpredictable consequences. For instance, there is a well-documented case where a single missing 'break' statement in a C program resulted in the loss of long-distance telephone service for a large part of the United States. The economic damage this caused was estimated to be in the hundreds of millions of dollars. (9) This "chaotic" nature of modern software technologies, where a seemingly minute defect can have major effects on the overall system, makes it very difficult to model software systems accurately. After all, the essence of modeling lies in abstraction or the removal of unessential detail. Because it is difficult to predict which fragment of software is unessential, how is it possible to have a model of software that is accurate and yet abstract enough to be useful?

One very effective solution to this dilemma is to formally link a model with its corresponding software implementation through one or a series of automated model transformations. Perhaps the best and most successful exemplar of that approach is the compiler, which automatically translates a high-level language program into an equivalent machine language implementation. In this case, the "model" is the high-level language program, which, like all useful models, hides irrelevant detail such as the idiosyncrasies of the underlying computing technology (e.g., internal word size, word orientation, the number of accumulators and index registers, the details of arithmetic and logic unit (ALU) programming).

Few if any engineering media other than software can provide such a tight coupling between a model and its corresponding engineering artifact. A model of any kind of physical artifact (automobile, building, bridge, etc.) inevitably involves an informal step of abstracting the physical characteristics into a corresponding formal model, such as a mathematical model or a scaled-down physical model. Similarly, implementing an abstract model with physical materials involves an informal transformation from the abstract into the concrete. The informal nature of this step can lead to inaccuracies that, as noted above, can render the models ineffective or even counterproductive. When it comes to software, however, the elements that are being modeled typically come from the world of ideas and are generally unfettered by intricate physical detail or constraints. By judicious selection of software abstractions and through the precise definition of their semantics, the transition from an abstraction to its software realization (and vice versa) can be automated without loss of accuracy. In this sense, software is an engineer's dream material, in which the model and its realization can be perfectly coupled to each other.

This potent combination of abstraction and automation has inspired a set of modeling technologies and corresponding development methods collectively referred to as model-driven development (MDD). (10,11) The defining feature of MDD is that models have become primary artifacts of software design, shifting much of the focus away from program code. Models serve as blueprints from which programs and related models are derived by various automated and semiautomated means. The degree of automation being applied today varies from simple skeleton code derivation all the way through to complete automatic code generation (comparable to traditional compilation). Clearly, the greater the levels of automation, the more accurate the models and the greater the benefits of MDD. However, there are many factors that must be considered when selecting an optimal level of automation for a given project. This includes, for example, the availability of appropriate expertise and tools, the specific nature of the application, the amount and characteristics of legacy code, and so on.

Model-driven methods of software development are not particularly new and have been used in the past with varying degrees of success. The reason they are receiving more attention now is that the supporting technologies have matured to the point where automation can be used in practical applications to a much larger extent. This is because the new technologies are much more scalable, more efficient, and much more easily integrated with existing tools and methods than was the case in the past. The degree of maturity of these technologies has reached a point where many of their aspects can be standardized--resulting in a commoditization of much MDD tooling.

To that end, OMG, the industry consortium that first standardized UML, has launched an initiative to develop a body of standards that support MDD. Called Model-Driven Architecture ** (MDA **), the initiative involved standards for modeling languages, such as UML, (7) standards for defining modeling languages like the Meta-Object Facility or MOF **, (12) standards for defining automated model transformations, standards for defining model-based software processes, and so on.