UML was originally developed with the idea of promoting communication and
productivity among the developers of object-oriented systems, but the readily
apparent power of UML has caused it to make inroads into every type of
system and software development.

Appreciating the Power of UML

UML satisfies an important need in software and system development.
Modeling - especially modeling in a way that's easily understood - allows
the developer to concentrate on the big picture. It helps you see and solve
the most important problems now, by preventing you from getting distracted
by swarms of details that are better to suppress until later. When you model,
you construct an abstraction of an existing real-world system (or of the system
you're envisioning), that allows you to ask questions of the model and get
good answers - all this without the costs of developing the system first.

After you're happy with your work, you can use your models to communicate
with others. You may use your models to request constructive criticism and
thus improve your work, to teach others, to direct team members' work, or
to garner praise and acclamation for your great ideas and pictures. Properly
constructed diagrams and models are efficient communication techniques
that don't suffer the ambiguity of spoken English, and don't overpower the
viewer with overwhelming details.

Abstracting out the essential truth

The technique of making a model of your ideas or the world is a use of
abstraction. For example, a map is a model of the world - it is not the
world in miniature. It's a conventional abstraction that takes a bit of training
or practice to recognize how it tracks reality, but you can use this abstraction
easily. Similarly, each UML diagram you draw has a relationship to your reality
(or your intended reality), and that relationship between model and reality
is learned and conventional. And the UML abstractions were developed as
conventions to be learned and used easily.

If you think of UML as a map of the world you see - or of a possible world you
want - you're not far off. A closer analogy might be that of set of blueprints
that show enough details of a building (in a standardized representation with
lots of specialized symbols and conventions) to convey a clear idea of
what the building is supposed to be.

The abstractions of models and diagrams are also useful because they suppress
or expose detail as needed. This application of information hiding allows you
to focus on the areas you need - and hide the areas you don't. For example,
you don't want to show trees and cars and people on your map, because
such a map would be cumbersome and not very useful. You have to suppress
some detail to use it.

You'll find the word elide often in texts on UML - every field has its own
jargon. Rumor has it that elide is a favorite word of Grady Booch, one of
the three methodologists responsible for the original development of UML.
Elide literally means to omit, slur over, strike out, or eliminate. UML uses
it to describe the ability of modelers (or their tools) to suppress or hide
known information from a diagram to accomplish a goal (such as simplicity
or repurposing).

Chapter 2 tells you more about using these concepts of information hiding
and abstraction during development.

Selecting a point of view

UML modeling also supports multiple views of the same system. Just as you
can have a political map, a relief map, a road map, and a utility map of the
same area to use for different purposes - or different types of architectural
diagrams and blueprints to emphasize different aspects of what you're
building - you can have many different types of UML diagrams, each of
which is a different view that shows different aspects of your system.

UML also allows you to construct a diagram for a specialized view by limiting
the diagram elements for a particular purpose at a particular time. For example,
you can develop a class diagram - the elements of which are relevant things
and their relationships to one another - to capture the analysis of the problem
that you have to solve, to capture the design of your solution, or to capture
the details of your implementation. Depending on your purpose, the relevant
things chosen to be diagram elements would vary. During analysis, the elements
that you include would be logical concepts from the problem and real world;
during design, they would include elements of the design and architectural
solution; and during implementation, they would primarily be software
classes.

A use case diagram normally concentrates on showing the purposes of the
system (use cases) and the users (actors). We call a use case diagram that
has its individual use cases elided (hidden) a context diagram, because it
shows the system in its environment (context) of surrounding systems
and actors.

Choosing the Appropriate UML Diagram

UML has many diagrams - more, in fact, than you'll probably need to know.
There are at least 13 official diagrams (actually the sum varies every time we
count it) and several semiofficial diagrams. Confusion can emerge because
UML usually allows you to place elements from one diagram on another if
the situation warrants. And the same diagram form, when used for a different
purpose, could be considered a different diagram.

In Figure 1-1, we've constructed a UML class diagram that sums up all the
major types of UML diagrams (along with their relationships), using the
principle of generalization, which entails organizing items by similarities
to keep the diagram compact. (See Chapter 2 for more information on
generalization.)

In Figure 1-1, the triangular arrows point from one diagram type to a more
general (or more abstract) diagram type. The lower diagram type is a kind-of
or sort-of the higher diagram type. Thus a Class Diagram is a kind of
Structural Diagram , which is a kind of Diagram . The diagram also uses a
dashed arrow to indicate a dependency - some diagrams reuse the features
of others and depend on their definition. For example, the Interaction
Overview Diagram depends on (or is derived from) the Activity Diagram
for much of its notation. To get a line on how you might use UML diagrams,
check out the summary in Table 1-1.

Slicing and dicing UML diagrams

There are many ways of organizing the UML diagrams to help you understand
how you may best use them. The diagram in Figure 1-1 uses the technique of
organization by generalization (moving up a hierarchy of abstraction) and
specialization (moving down the same hierarchy in the direction of concrete
detail). (See Chapter 6 for more on generalization and specialization.) In
Figure 1-1, each diagram is a subtype of (or special kind of) the diagram it
points to. So - moving in the direction of increasing abstraction - you can
consider a communication diagram from two distinct angles:

After you get some practice at creating and shaping UML diagrams, it's
almost second nature to determine which of these perspectives best fits
your purpose.

This general arrangement of diagrams that we used in our Figure 1-1 is
essentially the same as the UML standard uses to explain and catalog UML
diagrams - separating the diagrams into structural diagrams and behavioral
diagrams. This is a useful broad categorization of the diagrams, and is
reflected in the categorizations in Table 1-1:

Because UML is very flexible, you're likely to see various other ways of
categorizing the diagrams. The following three categories are popular:

You can employ UML diagrams to show different information at different times
or for different purposes. There are many modeling frameworks, such as
Zachman or DODAF (Department of Defense's Architecture Framework) that
help system developers organize and communicate different aspects of their
system. A simple framework for organizing your ideas that is widely useful is
the following approach to answering the standard questions about the system:

Automating with Model-Driven
Architecture (MDA)

Model-driven architecture (MDA) is new way to develop highly automated
systems. As UML tools become more powerful, they make automation a real
possibility much earlier in the process of generating a system. The roles of
designer and implementer start to converge. UML provides you with the keys
to steer your systems and software development toward new horizons utilizing
model-driven architectures.

In the past, after the designer decides what the system would look like - trading
off the design approach qualities such as performance, reliability,
stability, user-friendliness - the designer would hand the models off to the
developer to implement. Much of that implementation is difficult, and often
repetitious. As one part of an MDA approach to a project, UML articulates the
designer's choices in a way that can be directly input into system generation.
The mechanical application of infrastructure, database, user interface, and
middleware interfaces (such as COM, CORBA, .NET) can now be automated.

Because UML 2 works for high-level generalization or for showing brass-tacks
detail, you can use it to help generate high-quality, nearly complete implementations
(code, database, user-interface, and so on) from the models.

In MDA, the Development Team is responsible for analysis, requirements,
architecture, and design, producing several models leading up to a complete,
but Platform-Independent Model (PIM). Then UML and MDA tools can generate
a Platform-Specific Model (PSM) based on the architecture chosen and
(after some tweaking) produce the complete application.

This approach promises to free the development team from specific middleware
or platform vendors. When a new architecture paradigm appears - and it
will - the team can adopt it without going back to Square One for a complete
redevelopment effort. The combination of UML and MDA also promises to
free development teams from much of the coding work. Although the required
UML models are much more specific than most organizations are used to,
their use will change the way developers make systems.

With the advent of MDA and its allied technologies, UML becomes a sort of
executable blueprint - the descriptions, instructions, and the code for your
system in one package. Remember it all begins with UML.

Continues...

---

Excerpted from UML 2 For Dummies
by Michael Jesse Chonoles James A. Schardt
Copyright © 2003 by Michael Jesse Chonoles, James A. Schardt.
Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---