This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 What is the UML?
To quote:
-
The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems [OMG03a].
The word visual in the definition is a key point—the UML is the de facto standard diagramming notation for drawing or presenting pictures (with some text) related to software—primarily OO software.
This book doesn't cover all minute aspects of the UML, a large body of notation. It focuses on frequently used diagrams, the most commonly used features within those, and core notation that is unlikely to change in future UML versions.
The UML defines various UML profiles that specialize subsets of the notation for common subject areas, such as diagramming Enterprise JavaBeans (with the UML EJB profile).
At a deeper level—primarily of interest to Model Driven Architecture (MDA) CASE tool vendors—underlying the UML notation is the UML meta-model that describes the semantics of the modeling elements. It isn't something a developer needs to learn.
Three Ways to Apply UML
In [Fowler03] three ways people apply UML are introduced:
-
UML as sketch— Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual languages.
-
UML as blueprint— Relatively detailed design diagrams used either for 1) reverse engineering to visualize and better understanding existing code in UML diagrams, or for 2) code generation (forward engineering).
UML and "Silver Bullet" Thinking
There is a well-known paper from 1986 titled "No Silver Bullet" by Dr. Frederick Brooks, also published in his classic book Mythical Man-Month (20th anniversary edition). Recommended reading! An essential point is that it's a fundamental mistake (so far, endlessly repeated) to believe there is some special tool or technique in software that will make a dramatic order-of-magnitude difference in productivity, defect reduction, reliability, or simplicity. And tools don't compensate for design ignorance.
Yet, you will hear claims—usually from tool vendors—that drawing UML diagrams will make things much better; or, that Model Driven Architecture (MDA) tools based on UML will be the breakthrough silver bullet.
Reality-check time. The UML is simply a standard diagramming notation—boxes, lines, etc. Visual modeling with a common notation can be a great aid, but it is hardly as important as knowing how to design and think in objects. Such design knowledge is a very different and more important skill, and is not mastered by learning UML notation or using a CASE or MDA tool. A person not having good OO design and programming skills who draws UML is just drawing bad designs. I suggest the article Death by UML Fever [Bell04] (endorsed by the UML creator Grady Booch) for more on this subject, and also What UML Is and Isn't [Larman04].
Therefore, this book is an introduction to OOA/D and applying the UML to support skillful OO design.
-
If reverse engineering, a UML tool reads the source or binaries and generates (typically) UML package, class, and sequence diagrams. These "blueprints" can help the reader understand the big-picture elements, structure, and collaborations.
-
Before programming, some detailed diagrams can provide guidance for code generation (e.g., in Java), either manually or automatically with a tool. It's common that the diagrams are used for some code, and other code is filled in by a developer while coding (perhaps also applying UML sketching).
-
-
UML as programming language— Complete executable specification of a software system in UML. Executable code will be automatically generated, but is not normally seen or modified by developers; one works only in the UML "programming language." This use of UML requires a practical way to diagram all behavior or logic (probably using interaction or state diagrams), and is still under development in terms of theory, tool robustness and usability.
Agile modeling emphasizes UML as sketch; this is a common way to apply the UML, often with a high return on the investment of time (which is typically short). UML tools can be useful, but I encourage people to also consider an agile modeling approach to applying UML.
Note
agile modeling p. 30
Three Perspectives to Apply UML
The UML describes raw diagram types, such as class diagrams and sequence diagrams. It does not superimpose a modeling perspective on these. For example, the same UML class diagram notation can be used to draw pictures of concepts in the real world or software classes in Java.
This insight was emphasized in the Syntropy object-oriented method [CD94]. That is, the same notation may be used for three perspectives and types of models (Figure 1.6):
-
Conceptual perspective— the diagrams are interpreted as describing things in a situation of the real world or domain of interest.
-
Specification (software) perspective— the diagrams (using the same notation as in the conceptual perspective) describe software abstractions or components with specifications and interfaces, but no commitment to a particular implementation (for example, not specifically a class in C# or Java).
-
Implementation (software) perspective— the diagrams describe software implementations in a particular technology (such as Java).
)
Figure 1.6 Different perspectives with UML.
We've already seen an example of this in Figure 1.3 and Figure 1.5, where the same UML class diagram notation is used to visualize a domain model and a design model.
){kind=link}
){kind=link}
In practice, the specification perspective (deferring the target technology, such as Java versus .NET) is seldom used for design; most software-oriented UML diagramming assumes an implementation perspective.
The Meaning of "Class" in Different Perspectives
In the raw UML, the rectangular boxes shown in Figure 1.6 are called classes, but this term encompasses a variety of phenomena—physical things, abstract concepts, software things, events, and so forth. [1]
A method superimposes alternative terminology on top of the raw UML. For example, in the UP, when the UML boxes are drawn in the Domain Model, they are called domain concepts or conceptual classes; the Domain Model shows a conceptual perspective. In the UP, when UML boxes are drawn in the Design Model, they are called design classes; the Design Model shows a specification or implementation perspective, as desired by the modeler.
To keep things clear, this book will use class-related terms consistent with the UML and the UP, as follows:
-
Conceptual class— real-world concept or thing. A conceptual or essential perspective. The UP Domain Model contains conceptual classes.
-
Software class— a class representing a specification or implementation perspective of a software component, regardless of the process or method.
-
Implementation class— a class implemented in a specific OO language such as Java.
UML 1 and UML 2
Towards the end of 2004 a major new release of the UML emerged, UML 2. This text is based on UML 2; indeed, the notation used here was carefully reviewed with key members of the UML 2 specification team.
Why Won't We See Much UML for a Few Chapters?
This is not primarily a UML notation book, but one that explores the larger picture of applying the UML, patterns, and an iterative process in the context of OOA/D and related requirements analysis. OOA/D is normally preceded by requirements analysis. Therefore, the initial chapters introduce the important topics of use cases and requirements analysis, which are then followed by chapters on OOA/D and more UML details.