Q. What does "object-oriented" mean to you?

Q. Can you name the four phases of the Unified Process?

A. Inception
Elaboration
Construction
Transition

Q. What can you tell us about the different phases of the

Unified Process?

Q. Talk about some OO/UML artifacts you have used. What did
they mean to you? How did you apply them to yout project?

Q. What is a "use case"?

A. A complete end-to-end business process that satisfies the needs of a
user.

Q. What are different categories of use cases?

A. Detail Level: - High level / Expanded
Task Level: - Super / Sub (Abstract; Equal Alternatives; Complete v.
Partial)
Importance: - Primary / Secondary (use Secondary for exceptional
processes)
Abstraction: - Essential / Real
Q. What is the difference between a real and essential use
case?
A. essential - describes the "essence" of the problem; technology
independent
real - good for GUI designing; shows problem as related to technology
decisions
Q. What is polymorphism?
A. Different objects reacting to the same message differently.

Q. In a System Sequence Diagram, what is a System Event?

A. It is from the expanded use case. It is an actor action the system
directly responds to.

Q. Give an example of a situation which a State Diagram could

effectively model.
A. Think of a cake and its different stages through the baking process:
dough, baked, burned.

Q. For what are Operations Contracts written?

A. System Events.
Q. In an Operations Contract's postconditions, four types of
activities are specified. What are they?
A. They are:

instances created
associations formed
associations broken
attributes changed
Q. What does an Operations Contract do?
A. Provides a snapshot of the System's state before and after a System
Event. It is not interested in the Event's specific behavior.

Q. What does a Collaboration Diagram (or Sequence Event,

depending on the process) model?
A. A System Event's behavior.

Q. How does one model a class in a Collaboration Diagram? An

instance?
A. A box will represent both; however, a class is written as MyClass
whereas an instance is written as myInstance:MyClass.

Q. What are the three parts of a class in a Class Diagram?

A. Name, Attributes, Methods.

Q. In Analysis, we are interested in documenting concepts

within the relevant problem domain. What is a concept?
A. A person, place, thing, or idea that relates to the problem domain.
They are candidates for objects.

Q. Does a concept HAVE to become a class in Design?

A. No.

Q. In a Class Diagram, what does a line with an arrow from one

class to another denote?
A. Attribute visibility.

Q. What are the four types of visibility between objects?

A. Local, parameter, attribute, global.

Q. Have you ever used any Design Patterns?

Q. When do you use inheritance as opposed to aggregation?

A. An aggregation is a "has a" relationship, and it is represented in the
UML by a clear diamond. An example of an aggregate relation is Table
of Contents and Chapter. A Table of Contents "has a" Chapter.
Q. When would I prefer to use composition rather than
aggregation?
A. Composition is a stronger form of aggregation. The object which is
"contained" in another object is expected to live and die with the
object which "contains" it. Composition is represented in the UML by a
darkened diamond. An example of a composite relation is a Book and
Chapter. A Book "has a" Chapter, and the Chapter cannot exist without
the Book.

Q. Is the UML a process, method, or notation?

A. It is a notation. A process is Objectory, Booch, OMT, or the Unified
Process. A process and a notation together make an OO method.

Q. What are two uses for inheritance?

A. specialization - "IS A KIND OF" relationship
abstraction - pull a common concept out to a higher level to make it
more generic
Q. When would you use an abstract base class
A. When you need to enforce a particular interface, but are not able or
do not need to define behavior at the base class level.

Q. All containers are pretty well templatized now. Can you

think of any current "example" (e.g., an algorithm) which is
implemented via inheritance but might be more efficiently
implemented using templates?

Q. Can you tell us some good principles to use in OOA&D?

A. NOTE: This is not a complete list, by any means, but we have listed
the GRASP Patterns here for examples (these help assign
responsibilities between objects):

Low coupling
High cohesion
Controller
Creator
Don't Talk to Strangers
Pure Fabrication
Indirection
Polymorphism
Expert

Q. What are some practicle benefits we can gain from a well-

designed OO system?

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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 document 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).

--------------------------------------------------------------------------------
Where can I get more information?

You can visit the UML page in our Tutorials section.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.
--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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
"With Class" version 3.1, and will be supported even further in version 4.0.

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------

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.

--------------------------------------------------------------------------------