Appreciating the Power of UML | UML 2 For Dummies

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.

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