The section below covers frequently asked questions about UML. Click on each question for detailed answers with diagrams.

GENERAL INFORMATION
Q: What is the Unified Modeling Language?
Q: Why did we create the Unified Modeling Language?
Q: What's the official name for the Unified Modeling Language?
Q: What's our schedule for the Unified Modeling Language?
Q: Where can I get more information?

OVERVIEW
Q: What is the intended scope of the Unified Modeling Language?
Q: What are the primary artifacts of the Unified Modeling Language?

METAMODEL
Q: What is the Unified Modeling Language metamodel?

NOTATION
Q: What is the notation for the Unified Modeling Language?

PROCESS
Q: What is the process associated with the Unified Modeling Language?

COMPARISONS
Q: How does the Unified Modeling Language compare to Booch, Objectory, and OMT?
Q: What are some of the new features of the Unified Modeling Language?

TRANSITIONS
Q: How does the Unified Modeling Language affect existing Booch, Objectory, and OMT users?
Q: When will tools support the Unified Modeling Language?
Q: What are the plans for making the Unified Modeling Language a standard?

ESOTERICA
Q: Where did Grady come up with those clouds?

GENERAL INFORMATION

Q: What is the Unified Modeling Language?
The Unified Modeling Language is a third-generation method for specifying, visualizing, and documenting the artifacts of an object-oriented system under development. The Unified Modeling Language represents the unification of the Booch, Objectory, and OMT methods and is their direct and upwardly compatible successor. It also incorporates ideas from a number of other methodologists, including Peter Coad, Derek Coleman, Ward Cunningham, David Embley, Eric Gamma, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs-Brock, and Ed Yourdon. We continue to solicit feedback from these and other methodologists and from the industry at large as we continue their work. Our goal is to make the Unified Modeling Language the basis for a common, stable, and expressive object-oriented development method.

Q: Why did we create the Unified Modeling Language?
Identifiable object-oriented methods first appeared in the late 1980s. In the years following--characteristic of almost every emerging discipline--there was an explosion of object-oriented methods as various methodologists experimented with different approaches to object-oriented analysis and design. Experience with a number of these methods grew, accompanied by a growing maturation of the field as a whole as more and more projects applied these ideas to the development of production-quality, mission-critical systems. By the mid-1990s, a few second-generation methods began to appear, most notably Booch '94, the continued evolution of OMT, and Fusion.

Given that the Booch and OMT methods were already independently growing together and were collectively recognized as the dominant object-oriented methods worldwide, Booch and Rumbaugh joined forces in October 1994 to forge a complete unification of their work. Both Booch and OMT had begun to adopt Ivar Jacobson's use cases, and thus it was natural that in the fall of 1995, Jacobson formally joined this unification effort.

As we began our unification, we established four goals to bound our efforts:

* To model systems (and not just software) using object-oriented concepts
* To establish an explicit coupling to conceptual as well as executable artifacts
* To address the issues of scale inherent in complex, mission-critical systems
* To create a method usable by both humans and machines

Devising a notation for use in object-oriented analysis and design is not unlike designing a programming language. First, the author must bound the problem: Should the notation encompass requirements specification? Should the notation extend to the level of a visual programming language? Second, the author must strike a balance between expressiveness and simplicity: Too simple a notation will limit the breadth of problems that can be solved; too complex a notation will overwhelm the mortal developer. In the case of unifying existing methods, the author must also be sensitive to the installed base: Make too many changes, and you will confuse existing users. Resist advancing the notation, and you will miss the opportunity of engaging a much broader set of users.

As the primary authors of the Booch, Objectory, and OMT methods, we were motivated to create a unified method for three simple reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, thus eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying these methods now, we could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature method and letting tool builders focus on delivering more useful features. Third, we expected that our collaboration would yield improvements in all three earlier methods, helping us to capture lessons learned and to address problems that none of our methods currently handled well.

Q: What's the official name for the Unified Modeling Language?
"The Unified Modeling Language" or UML for short.

At the start of our work, we called our effort simply "The Unified Method" because we needed a simple working title. We began a name search, but we never found a name that was cool (like Java) or right-on (like Fusion) that sounded good to us. We are still hoping to find a suitable name (suggestions are most welcome), although "The Unified Modeling Language" has entered such common usage that it may end up being the default name.

Q: What's our schedule for the Unified Modeling Language?
Jim and Grady began their unification efforts in October 1994. At OOPSLA '94, we promised to deliver a unified method for public review by OOPSLA '95. We achieved that goal with the release of the version 0.8 documenttation set of the Unified Modeling Language. Currently, Jim, Ivar, and Grady are working to incorporate Objectory's concepts into that early work, as well as to simplify the modeling language and address some advanced issues (namely, concurrency and distribution). We expect to produce a version 0.9 addendum to the original Unified Modeling Language document in the next couple of months, based on public feedback on our 0.8 document, the continuing unification with the Objectory semantics, and work with other methodologists. Late in 1996, we will present this work for standardization to the Object Management Group (OMG).

Q: Where can I get more information?
You can visit the UML page in our Tutorials section.

OVERVIEW

Q: What is the intended scope of the Unified Modeling Language?
First and foremost, the Unified Modeling Language fuses the concepts of Booch, Objectory, and OMT. It is our intention to produce a single, common, and widely usable modeling language for these methods and, working with other methodolgists, for other methods as well.

Second, the Unified Modeling Language pushes the envelope of what can be done with existing methods. In particular, we have targeted the modeling of concurrent, distributed systems, meaning that the Unified Modeling Language will contain elements that address these domains.

Third, the Unified Modeling Language focuses on a standard language, not a standard process. It is our experience that different organizations and problem domains require different processes. (For example, the Microsoft development process is an interesting one, but building shrink-wrapped software is vastly different from building hard-real-time avionics systems upon which lives depend.) Therefore, our efforts are concentrating first on a common metamodel (which unifies semantics) and second on a common notation (which provides a human rendering of these semantics). We will not necessarily standardize a process, although we will continue to promote an architecture-driven, incremental, and iterative development process.

Q: What are the primary artifacts of the Unified Modeling Language?
This question can be answered in two ways: first in terms of the artifacts that constitute the Unified Modeling Language (the inside view) and second in terms of the artifacts that users apply to model systems using the Unified Modeling Language (the outside view).

From the inside, the Unified Modeling Language consists of three things:

* A formal metamodel
* A graphical notation
* A set of idioms of usage

We began with a formal metamodel, using the notation of the Unified Modeling Language itself supplemented by English text. The purpose of the metamodel was to provide a single, common, and unambiguous statement of the syntax and semantics of the elements of the Unified Modeling Language. The presence of this metamodel has made it possible for us to agree on semantics, decoupled from the human factors issues of how those semantics would best be rendered. Additionally, the metamodel has made it possible for us to explore ways to make the modeling language much more simple by, in a sense, unifying the elements of the Unified Modeling Language. (For example, we have discovered commonality among the concepts of protocols and use cases.) We expect to make this metamodel even more precise by describing its dynamic semantics using formal logic. The graphical notation is the most visible part of the Unified Modeling Language, and it constitutes the graphical syntax that humans and tools use to model systems. Lastly, the Unified Modeling Language encompasses a set of idioms that describe common usage (by humans) and degrees of freedom (by tools).

From the outside, the Unified Modeling Language encompasses a number of models that can be rendered in a variety of projections:

* Use-case diagrams
* Class diagrams
* State-machine diagrams
* Message-trace diagrams
* Object-message diagrams
* Process diagrams
* Module diagrams
* Platform diagrams

Use-case diagrams are as found in Objectory, and they serve to organize the use cases that encompass a system's behavior. Class diagrams, derived from Booch and OMT, capture the static semantics of the classes that constitute a system. State-machine diagrams, derived from David Harel, capture the dynamic semantics of a class. Message-trace diagrams, object-message diagrams, and process diagrams, derived from Booch, OMT, and Fusion, capture the dynamic semantics of collaborations of objects. Module diagrams serve to model the development view of a system, whereas platform diagrams serve to model the physical computing topology upon which a system executes.

These are the primary artifacts that a modeler sees, although the method (and tools) provide for a number of derivative views.

METAMODEL

Q: What is the Unified Modeling Language metamodel?
A metamodel is a model of a model.

Think of it this way: Developers create things like class diagrams and object diagrams to model a system under development; this resulting model describes a system. A metamodel is a model of that model.

Metamodels are important, because they can provide a single, common, and unambiguous statement of the syntax and semantics of a model. We began our work on the Unified Modeling Language by starting with a metamodel, because it let us come to rapid agreement about the meaning of things (and the very things themselves) that were to constitute our unification. Thus, our metamodel includes some obvious things like classes and objects (which are isomorphic to the elements of the modeling language) and some nonobvious things like uninterpreted and nonclass decls (which are artifacts of the metamodel).

For most users, the metamodel is invisible (as it should be). It's valuable to us, because it lets us communicate our intended semantics to each other and to tool builders. It also gives us something to throw stones at as we try new modeling problems: If we can model something complex easily, then we know we are on the right path. Similarly, it gives us something to evolve. A large part of our latest work has been making the metamodel simpler (which is a very hard thing to do).

Currently, the metamodel for the Unified Modeling Language is described in a combination of English text and class diagrams using the Unified Modeling Language itself. For those purists out there: Yes, Godel's Theorem does apply, which means that there are theoretical limits to what we can express about the metamodel using the metamodel itself. However, we think our combination of text and diagrams strikes the right balance between expressiveness and readability.

Currently, we are working to make this model more formal, in two ways. First, we are writing a number of use cases against the metamodel, which lets us try out common and not-so-common modeling problems. Second, we are writing a number of use cases against the dynamic semantics of the metamodel, using formal logic. This is definitely not for the meek, but again it helps us be sure we are generating models that are self-consistent and precise.

NOTATION

Q: What is the notation for the Unified Modeling Language?
The Unified Modeling Language notation is truly a melding of the graphical syntax of Booch, Objectory, and OMT. It largely draws from the renderings of each one of these methods, with a number of symbols thrown out (because they were confusing, superfluous, or little-used) and with a few new symbols added.

From the outside, the Unified Modeling Language encompasses the following models:

* Use-case diagrams
* Class diagrams
* State-machine diagrams
* Message-trace diagrams
* Object-message diagrams
* Process diagrams
* Module diagrams
* Network diagrams

Use-case diagrams look pretty much as they do in Objectory.

Class diagrams look much like OMT class diagrams (classes are rendered as rectangles) but with most relationships drawn from Booch.

State-machine diagrams, as developed by David Harel, are the same as in Booch and OMT.

Message-trace diagrams were in all three methods (and have thus been unified). Object-message diagrams are derived from Booch (with the change that objects are no longer clouds, but structured clouds; we also adopt the numbering convention from Fusion). Process diagrams are a new invention, and module diagrams and network diagrams derive from Booch.

Thus, if you are a Booch user, you'll need to get over the use of clouds (rectangles are more space-efficient), but pretty much things look the same. If you are an OMT user, you'll see a number of niggling changes (such as the multiplicity balls replaced with more explicit expressions) but no fundamental changes (though there are a number of additions). If you are an Objectory user, you'll see new notation (because Objectory didn't deal with much graphical modeling postanalysis). For all three kinds of users, there will be new things to learn (such as stereotypes and properties) but nothing that a few minutes of reading won't do.

PROCESS

Q: What is the process associated with the Unified Modeling Language?
It's architecture-driven, and it's incremental and iterative.

Booch, Objectory, and OMT all have well-defined processes, and these are indeed sufficient for the Unified Modeling Language. Beyond that, we don't yet specify a process. Our focus first is on a common, standard modeling language. Processes by their very nature must be tailored to the organization, culture, and problem domain at hand. What works for one context (shrink-wrapped software development, for example) would be a disaster for another (hard-real-time, human-rated systems, for example).

This does not mean that we are blind to the importance of process. We do think we understand what such a process looks like, but it is unnecessary for us to bind the Unified Modeling Language to a particular process, because experience has shown that the modeling languages of Booch, Objectory, and OMT are amenable to a spectrum of different processes. Thus, we have kept in mind which artifacts are important for visualizing different aspects of a system under development and which artifacts are critical for controlling and measuring the progress of a development team. Doing so has been sufficient for us to know what to keep and what to throw out yet still permit diverse organizations to apply the Unified Modeling Language successfully.

COMPARISONS

Q: How does the Unified Modeling Language compare to Booch, Objectory, and OMT?
The Unified Modeling Language is simpler, more self-consistent, and more expressive. Furthermore, the Unified Modeling Language is a natural successor to Booch, Objectory, and OMT, and as such it is compatible with each.

It's simpler in that we've found a number of elements collapse into one. For example, Booch used the notion of active objects and persistent objects. We generalize this by denoting them as stereotypes or properties in the Unified Modeling Language--which also lets us express things like location for distributed systems. Similarly, Objectory used different kinds of classes in its models. This generalizes to the stereotype concept as well. OMT had data-flow diagrams, which are thrown out and replaced with, among other things, use cases.

It's more self-consistent in that the metamodel hangs together well. We've eliminated the confusion surrounding has relationships in Booch. Objectory's use cases have application in a number of places in the metamodel. OMT's semantics of associations have been cleaned up.

It's more expressive as well. The Unified Modeling Language lets you express the semantics of concurrent and distributed systems. We've introduced new elements, such as protocols, interfaces, and stereotypes. Also, we have a means of making the notation tailorable, through the use of properties, some of which we predefine and some of which we leave open.

For the Booch user, the new notation requires getting used to rectangles instead of clouds, plus learning a few new things. For the Objectory user, the new notation requires learning some new notation. For the OMT user, the new notation requires changing the icons for some things and adding a few new things. In all, we expect the learning curve for Booch, Objectory, and OMT users to be very, very small. Indeed, it's not hard to explain the changes from any of these three methods to an experienced user in an hour or less.

Q: What are some of the new features of the Unified Modeling Language?
The goals of our unification efforts were to keep it simple, to cast away elements of classic Booch, Objectory, and OMT that just didn't work in practice, and to add only new elements that let us address modeling problems that neither Booch nor Objectory nor OMT had yet addressed. Because we were in effect designing a new language (albeit a graphical one), we had to strike a proper balance between minimalism (everything is text and boxes) and overengineering (having an icon for every conceivable modeling element). To that end, we were very careful about adding new things, because we didn't want to make the unified method more complex. Along the way, however, we found some things that we genuinely needed to add, because they were useful in practice in other methods and previously had been handled only informally in either Booch or OMT.

Responsibilities are a good example of this. Responsibilities become first-class citizens in the Unified Modeling Language, reflecting the fact that responsibility-driven design is a proven technique that fits well with the Booch/Objectory/OMT philosophy. Now, it is possible to declare and manipulate the responsibilities of a class directly. This approach also gives us a better coupling to CRC card techniques.

Stereotypes are a slightly different issue--one that requires a bit of a background to explain. In our drive to make things simpler, Jim and Grady introduced the notion of properties, whereby every element in the Unified Modeling Language could have an open-ended set of properties, such as properties for code generation. This mechanism gave us a means of extending and tailoring the language without radically changing it. As it turns out, properties allowed us to simplify some previously orthogonal concepts. In Booch, for example, there were ways of showing the concurrency and persistency properties of a class. In the Unified Modeling Language, these are no longer independent concepts, but rather they are treated as just two of the predefined properties of a class. We plan to specify a number of predefined properties (such as a class being abstract, the multiplicity of a class, or designating the interface of a class) while leaving the specification of others to the tool and the project (thereby giving us extensibility). With this collapse of concepts into one mechanism (properties), we found that there was one property that stood out and warranted special treatment, and that's the notion of a stereotype, which is derived from the work of Rebecca Wirfs-Brock.

Basically, a stereotype is a metaclassification. For example, in C++, you can declare a hierarchy of classes that are used only as exceptions. From a language perspective, they are just plain, ordinary classes. However, from the architectural perspective, exceptions classes are different, for they are intended to be used in special ways. (You generally only throw and catch instances of these classes and no other classes.) We can specify these classes as being of the stereotype exception, which sets them apart visually and--more importantly--semantically, because the tools that manipulate these models can do special things knowing a class's stereotype. For example, a tool might enforce special semantic checks knowing that a class is an exception, preventing its use for anything other than throwing and catching. As it turns out, stereotypes are a generally useful concept for a number of other modeling problems, such as the modeling of classes that are extensible at runtime.

Distribution is handled quite nicely with properties (the location of an object is one of its properties), and thus we needed to add no special mechanism. This suggests that we selected the right primitive modeling elements in the Unified Modeling Language metamodel.

Threads and processes are a subject of ongoing work. We are toying with some approaches (again using properties and conventions with object-message diagrams), but we need a little more experience to make sure we have settled on the right constructs. We are considering treating threads and processes as first-class citizens (possibly warranting a special icon).

For the issues of both distribution and concurrency, we are particularly sensitive to the modeling needs of systems built with technologies such as CORBA and OLE/COM, as well the style of distribution found in Java applets. These are the target technologies that we want to be certain we can model well, because we expect that one of more of these approaches will become pervasive. This is not to say that we will settle on supporting only certain proprietary technologies; rather, we will be as general as we can be but pragmatic enough to realize that we can't be overly general. As it turns out, the fact that interfaces are treated as first-class citizens in the Unified Modeling Language (this is another important addition to the method) helps us deal with the publish/subscribe paradigm found in both CORBA and COM, So again, we think we are on the right path to address many of distribution and concurrency modeling problems without adding numerous special mechanisms to the method.

TRANSITION

Q: How does the Unified Modeling Language affect existing Booch, Objectory, and OMT users?
There are three parts to this answer.

First, it should be made clear that the Unified Modeling Language is not a radical departure from Booch, Objectory, or OMT, but rather the legitimate successor to all three. This means that if you are a Booch, Objectory, or OMT user today, your training, experience, and tools will be preserved, because the Unified Modeling Language is a natural evolutionary step.

Second, the Unified Modeling Language is more expressive yet simpler, cleaner, and more uniform than Booch, Objectory, or OMT. This means that there is value in moving to the Unified Modeling Language, because it will allow projects to model things they could not have done before.

Third, you need not wait for the Unified Modeling Language to get value out of object-oriented technology. It will take some time for the Unified Modeling Language to wind its way through the standards process; it will take some time for tools vendors to support the method. If you choose to use object-oriented stuff, then choose Booch. If you are construction-oriented, choose Objectory if your focus is more on business process reengineering (BPR), and choose OMT if your focus is more on analysis. The important point is that you will not make a wrong decision if you choose any one of these three, and the migration from any one of these methods to the Unified Modeling Language will be relatively painless.

Q: When will tools support the Unified Modeling Language?
Grady, Ivar, and Jim have explicitly invited every object-oriented analysis and design tool vendor we are aware of to learn about the Unified Modeling Language and to comment on its content. At OOPSLA '95, we even hosted a vendor meeting to unveil our work. Since that time, a number of tool vendors (including Rational) have pledged their support for the Unified Modeling Language. UML is already very well supported by Microgold's WithClass.

It is most likely that tools will stage their support for the Unified Modeling Language either by starting with use cases first, plus perhaps a few other things (like the cosmetics of the graphical syntax and possibly stereotypes and properties), or by supporting simple semantics first and then adding deeper semantic support later. Clearly, there won't be complete tools supporting the Unified Modeling Language until the method itself is finalized sometime early in 1997, but we expect that multiple sources of tool support will emerge very shortly thereafter.

Q: What are the plans for making the Unified Modeling Language a standard?
We are participating in the Object Management Group's (OMG's) call for information on object-oriented methods. Clearly, we can't just declare the Unified Modeling Language to be a standard: That status has to be earned and granted. We are thus doing all we can to be responsive to this proposal, and we will continue to work with the OMG. On the other hand, we will continue to make the Unified Modeling Language pervasive, by making the fruits of our work readily available as well as by encouraging other methodologists to work with us and other tool vendors and training organizations to adopt the Unified Modeling Language.

ESOTERICA

Q: Where did Grady come up with those clouds?
Back in 1982, Grady was starting to evolve his thoughts about object-oriented analysis and design. All the structured analysis folks had already used up all the good symbols (rectangles, circles, and so on), so he wanted to select something that represented the fact that this object-oriented stuff was different. Grady took a cue from Intel's 432, their take on an object-oriented microprocessor. The 432 never succeeded commercially (they could never get their yields up, and there were real problems in their process model), but they did use one cool idea: They used clouds in their documentation to represent objects. That's what Grady then used in his early papers, and the idea stuck.

In the Unified Modeling Language, clouds disappear. This was the Right and Noble Decision: Rectangles are easier to draw and more space efficient, although they are heavily overloaded. We preserve the concept in object diagrams, which use structured clouds (basically, vertically elongated hexagonal shapes). Jim's pointed out that when clouds crystallize, they form hexagons :-) so we probably made the right choice here.

For more information about CASE Tool support for UML, contact: Mike Gold
Send general questions and comments about the Unified Modeling Language or this FAQ to: techsales@microgold.com