The unification of object-oriented modeling methods became possible as experience allowed evaluation of the various concepts proposed by existing methods. Based on the fact that differences between the various methods were becoming smaller, and that the method wars did not move object-oriented technology forward any longer, Jim Rumbaugh and Grady Booch decided at the end of 1994 to unify their work within a single method: the Unified Method. A year later they were joined by Ivar Jacobson, the father of use cases, a very efficient technique for the determination of requirements.
Booch, Rumbaugh and Jacobson adopted four goals:
The authors of the Unified Method rapidly reached a consensus with respect to fundamental object-oriented concepts. However, convergence on the notation elements was more difficult to obtain, and the graphical representation used for the various model elements went through several modifications.
The first version of the description of the Unified Method was presented in October 1995 in a document titled Unified Method V0.8. This document was widely distributed, and the authors received more than a thousand detailed comments from the user community. These comments were taken into account in version 0.9, released in June 1996. However, it was version 0.91, released in October 1996, which represented a substantial evolution of the Unified Method.
The main modification was a change in the direction of the unification effort, so that the first objective was the definition of a universal language for object-oriented modeling, and the standardization of the object-oriented development process would follow later. The Unified Method was transformed into UML (the Unified Modeling Language for object-oriented development).
In 1996, it was clear that UML was perceived as a basic element in the strategy of several large corporations. A consortium of partners was then created to work on the definition of UML version 1.0; it included among others: DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI and Unisys. This collaboration gave birth to the description of UML version 1.0, which was submitted to the OMG (Object Management Group) for their consideration on January 17 1997.
However, UML 1.0 was only one response to OMG's request for proposals for modeling languages. During the course of the next few months, the UML partners collaborated with other respondents, resulting in the production of UML 1.1. This release cleared up some semantics and included some new contributions, and UML was re-submitted to the OMG on September 1, for likely standardization before the end of the year.
UML's creators take great care to point out that the notation forms an object-oriented modeling language, rather than an object-oriented method. The comments received about version 0.8 clearly showed that users expected a formalization of the development artifacts rather than a formalization of the deployment process of such artifacts. Therefore, the UML notation has been designed to serve as an object-oriented modeling language, regardless of the deployment method. The UML notation can therefore replace — without loss of information — the notations of methods such as Booch, OMT or OOSE (Object Oriented Software Engineering, also called Objectory).
UML is not a proprietary notation: it is accessible to everybody — tool manufacturers and training agencies can use it freely. Thanks to its openness, the richness of the notation and the precise definition of the semantics of its model elements, UML is a simple and generic notation that is clearly not simplistic.
The initial effort focused on the identification and definition of the semantics of fundamental concepts — the building blocks of object-oriented modeling. These concepts are the artifacts of the development process, and must be exchanged between the different parties involved in a project. To implement these exchanges, it was first necessary to agree on the relative importance of each concept, to study the consequences of these choices, and to select a graphical representation, of which the syntax must be simple, intuitive, and expressive.
To facilitate this definition work, and to help formalize UML, all the different concepts have themselves been modeled using a subset of UML. This recursive definition, called metamodeling, has the double advantage of allowing the classification of concepts by abstraction level, by complexity and by application domain, while also guaranteeing a notation with an expressive power such that it can be used to represent itself.
A metamodel describes formally the model elements, and the syntax and semantics of the notation that allows their manipulation. The added abstraction introduced by the construction of a metamodel facilitates the discovery of potential inconsistencies, and promotes generalization. The UML metamodel is used as a reference guide for building tools, and for sharing models between different tools.
A model is an abstract description of a system or a process — a simplified representation that promotes understanding and enables simulation. The term 'modeling' is often used as a synonym of analysis, that is, the decomposition into simple elements that are easier to understand. In computer science, modeling starts with the description of a problem, and then describes the solution to the problem. These activities are called respectively 'analysis' and 'design'.
The form of the model depends on the metamodel. Functional modeling decomposes tasks into functions that are simpler to implement. Object-oriented modeling decomposes systems into collaborating objects. Each metamodel defines model elements, and rules for the composition of these model elements.
The content of the model depends on the problem. A modeling language like UML is sufficiently general to be used in all software engineering domains and beyond — it could be applied to business engineering, for example.
A model is the basic unit of development; it is highly self-consistent and loosely coupled with other models by navigation links. As a rule, a model relates to a specific phase of development, and is built from model elements with their different associated representations.
A model is not directly visible by users. It captures the underlying semantics of a problem, and contains data accessed by tools to facilitate information exchange, code generation, navigation, etc. UML defines several models for representing systems:
Models are browsed and manipulated by users by means of graphical representations, which are projections of the elements contained in one or more models. Many different perspectives can be constructed for a base model — each can show all or part of the model, and each has one or more corresponding diagrams. UML defines nine different types of diagram:
Different notations can be used to represent the same model. The Booch, OMT, and OOSE notations use different graphical syntaxes, but they all represent the same object-oriented concepts. These different graphical notations are just different views of the same model elements, so that it is quite possible to use different notations without losing the semantic content.
At heart, then, UML is simply another graphical representation of a common semantic model. However, by combining the most useful elements of the object-oriented methods, and extending the notation to cover new aspects of system development, UML provides a comprehensive notation for the full lifecycle of object-oriented development.
© 1997 Editions, Eyrolles, Paris, France . All rights reserved.