Understanding UML Terminology and Concepts

Over the years (if you’re like most of us) you’ve learned the wisdom of such phrases as “say what you mean, mean what you say” and “get to the point.” You’ve probably found that your best communication with other people happens when you say what needs to be said, no more and no less. The experts use their own special words to describe this common-sense principle; Table 2-1 (which uses an air-filter air exchange unit as an example) interprets what they mean.

Table 2-1: Keep It Simple: Word Interpretations
Expert’s Word	What They Really Mean	Example
Object	Refer to something useful that has identity, structure, and behavior.	The air-filter unit sitting in my living room is unique from all other air filters. It’s about 3 feet tall with an 18-inch-square base. The unit behaves nicely by cleaning the air for me.
Class	A family of objects with similar structure and behavior	You refer to my air-filter unit and the thousands of others manufactured just like it as the HEPA air-filter unit. All these similar units form a class of air-filter unit.
Abstraction	Describe the essence of an object for a purpose.	A circuit diagram of an air-filter unit describes the essence of the electrical wiring so you don’t electrocute yourself when you work on it.
Encapsulation	Just tell me what I need to know to use an object.	“You turn on the air-filter unit with the external three-speed knob, and you can’t get inside the unit to change the possible speeds of the motor.” This statement encapsulates all the details of how the electricity flows to the motor thus turning on the motor that moves the fan, which moves the air through the filters
Information hiding	Keep it simple by hiding the details.	Most people don’t need to know the three-speed switch’s part number, or the fact that it takes 120 volts AC power at 15 amperes
Aggregation 21	Just tell me about the whole object or tell me about the parts of the whole object	The air-filter unit (as a whole) pulls in air and expels filtered, cleaned air. The air-filter unit is composed of two filters, a fan, a fan motor, a three-speed switch, and some wire
Expert’s Word	What They Really Mean	Example
Generalization	Just tell me what is common among these objects	Every air-filter unit has a filter to clean the air and a fan to move the air.
.
Specialization	Just tell me what is different about this particular object.	The HEP43x air-filter unit is unique because it has a motion sensor to speed up the fan when extra dust is flying around.
Inheritance	Don’t forget that specialized objects inherit the common features of generic objects.	Since the HEP43x is an air- filter unit, it inherits the features of all air filter units—a filter and a fan

Abstracting away irrelevance

Ignoring unimportant details is a fundamental part of your life. Most of the time you are not even aware how much you take no notice of your surroundings. If you had to pay attention to everything around you all the time, you would have no time to do anything else. When you communicate your ideas about a system or the software you are developing, you ignore the trivial and focus on the important. The experts have a fancy word—abstraction—for this process of distilling the “important” information (needed for some clear purpose) out of the mass of surrounding details.

You use different degrees of abstraction at different times. For example, the picture of the air-filter unit in Figure 2-1 is an abstraction; this image is not the real air-filter unit. The picture describes the look of the unit without details such as color, physical dimensions, and actual size.

Sometimes you need different abstractions of the same thing. For example, the electrician may need to see a wiring diagram like the one in Figure 2-2. This diagram “abstracts away” everything about the air-filter unit except its electric circuitry—and even that isn’t what the actual wiring looks like. The symbols on the wiring diagram have special meanings; they indicate components or functions that would otherwise clutter up the diagram with distracting details. The symbol that looks like an upside-down triangle with three lines, for example, shows that the circuit is grounded at this point—exactly how that’s done isn’t important right now, and isn’t shown.

Remember UML diagrams have symbols that act as a shorthand notation. These symbols allow you to show what’s important by using the principle of abstraction, just as a circuit diagram shows the electricians what’s important to them.

Figure 2-1: Picture representation of an air-filter unit.

Tip When you use UML to make models—in particular, objects and classes, which are discussed in detail in Chapter 3—they make good abstractions of the physical world. A good model contains only the important aspects of an object, such as its identity, structure, behavior, and association with other objects. (Abstracting your real world objects—paring them down to the essentials—is also a great help when you map real-world stuff into object-oriented programs.)

Warning Don’t let someone use UML to describe lots of irrelevant detail. Apply the principle of abstraction—ignore the irrelevant and model what is important to you and fellow developers.

Encapsulating and hiding information

To help you enforce an abstraction, the experts have a couple of other fancy terms:

Encapsulation: When you summarize important features of your objects in one place, you are encapsulating them—your objects can make good abstractions of the real world by combining features such as identity, attributes, and behavior into a neat package. Everything an object needs to be itself—structure, identity, internal behavior—is close together so the object can be itself (function the way it wants to). The operations (behavior) of an object are like a wall between its internal workings and those of other objects. The wall of operations places a barrier that helps the object maintain its separation from other objects, which helps enforce the abstraction.

These walls prevent your intended abstraction from being violated. You turn an air-filter unit on and off. You cannot break the encapsulation of that object and change its internals to create a TV that you can also turn on and off.
Information hiding: Hiding the details of how an object performs its job helps prevent overloading the user with irrelevant details. The advantage is that if you hide internal information about an object from its users, then you can tinker with that object without affecting the users.

Manufacturers of air-filter units try hard to hide how the unit works from the users of these devices. The assumption is that the user doesn’t have to know anything about the operation of the unit except how to turn it on and off. If the manufacturer changes the internal workings of the unit without changing its controls—and it performs the same function—then its users don’t have to retrain themselves to use a new unit.

Encapsulation and information hiding are used in many branches of technology. For example, computer users sometimes complain that PCs—even today—still require the user to master too much detailed knowledge. The users—all of us—still have to know a lot about the internal workings of the computer before we can change a setting or get it to do a simple task. All those details tend to get in the way of performing a job. From the user’s point of view, the PC builders haven’t done enough information hiding or encapsulation.

click to expand
Figure 2-2: Electric circuit representation of an air-filter unit.

A little information hiding goes a long way

During the 1990s, software developers were obsessed with Y2K—the fear that software programs worldwide would be disrupted when the year changed from 1999 to 2000. The problem boiled down to a lack of (you guessed it) encapsulation and information hiding. Two digits were customarily used to represent the year attribute of a date: 98 for 1998, 99 for 1999, and 00 for—what? 1900 or 2000? Programs that needed accurate dates to function properly relied on those unencapsulated two-digit year attributes—big trouble. Companies and governments around the world spent in excess of $200 billion to solve the problem.

Now, suppose those dates were encapsulated into a date object and the year representation was hidden inside the date object. The software developers could have changed the internal representation of year from two to four digits and added a wall of behavior that would, if asked, provide the date with either two- or four-digit years. When a software developer needed to see whether one date preceded another, the developer would ask two date objects to compare themselves through a simple compare operation. If early software developers had encapsulated all dates in the first place—and hidden the representation of year—then the Y2K scare would have never happened.

Remember You use encapsulation and information hiding together when developing object-oriented systems and software. By hiding an object’s structure and internal methods of behavior behind a wall of operations, you enforce your abstraction and—in effect—help keep the object intact.

Warning Don’t make the structure of your objects public. Doing so breaks the principle of encapsulation and information hiding. For openers, public attributes often attract tinkerers who make unauthorized modifications, and that makes your job of enforcing an abstraction difficult.

Separating the whole from its parts

Aggregation is, in effect, pulling together the parts of an object to make up the actual object. For example, when we say “air-filter unit” we’re talking about a whole object that hides many other objects that we call its parts. The fan, motor, filter, switch, and wires are the internal objects/parts of an air-filter unit. You aggregate the hidden parts to form the whole air-filter unit.

You use aggregation to hide the internal parts of a complex object from the outside world. Aggregation is a form of encapsulation and information hiding. The whole or aggregate object hides many complex internal objects or parts.

If an object is especially complex, you can ignore its internals by focusing on relationships between the whole object and other external objects. We don’t have to talk about the internal parts of an air-filter unit to tell you how to use it. We communicate the relationships between you, the air-filter unit, and the air that gets cleaned and moved throughout the room. In my communication with you we tell you just what you need to know.

If you must maintain the air-filter unit by replacing the filter, we tell you about that specific internal part of the unit. Nobody has to yak on and on about the unit’s relationship with air, the room, and the user. Again, we tell you only what you (as maintainer) need to know.

Tip Whenever you need to hide the internal parts of an object, use UML aggregation notation to isolate the internal complexity of a whole object from outside interactions with other objects.

Composition is another word for a strong form of aggregation. The experts needed a different word to help distinguish between two different situations:

Composition: When the parts of an object are completely bound up in the life of the whole object, the whole object is composed of them. If you take a whole air-filter unit and crush it (end the life of the whole thing), then all its parts are crushed too (the life of each part is bound to the life of the whole).
Aggregation: Some parts of a whole object exist beyond the life of the whole. For example, a subsidiary of a holding company is part of the whole company. However, if the holding company were to go bankrupt and cease to exist, the subsidiary’s life would continue as a standalone company. The relationship between the subsidiary and the holding company is simple aggregation, not composition.

Remember You manage complexity by hiding it. Suppose we build a black box and tell you how to hook up to the black box. If all you worry about is the hook up to the box and not the insides of the black box, then we have successfully hidden any complexity from you. UML classes hide complexity by forcing you to use their public operations (publicly accessible behavior). UML components with internal parts hide complexity by forcing you to use their public interfaces.

Generalizing and specializing

Like most people, UML experts prefer not to repeat themselves when communicating with others. They follow the principle of saying something once. When you hear the following words this is what they mean:

Generalization: You look at a group of objects, extract the features they have in common—their attributes (structure) and their operations (behavior)—and use those features to define a generic class of objects. That way, you refer to these common features whenever you mention the class—and you only have to do so once.
Specialization: Specialization is the opposite of generalization. To specialize a group of objects, you look at a group of objects and identify groups of objects with unique features not shared with other groups of objects. Then, you create a class for each group of objects with their own unique features.

The same is true of any object—especially of any machine. There are lots of different kinds of air-filter units, from no-frills to fancy. Figure 2-3 shows the type of air-filter unit you see above a stove. A more elaborate, whiz-bang air-filter unit, bristling with gizmos, is shown in Figure 2-4. These units share common features—internal fan, On/Off switch, replaceable air filter—that you can find in various types of filter units. When you consider all possible filter units that have these basic features, you’re generalizing.

click to expand
Figure 2-3: This stove-top air-filter unit has a light so you find the oregano.

To help you see the spaghetti sauce you’re cooking, the stovetop unit in Figure 2-3 has a light to illuminate the cooking surface below. None of the other air-filter units have this, so stovetop air-filter units make up a more specific class of objects.

The fancy unit in Figure 2-4 has an ultraviolet light and a motion sensor. Since we’ve already included it in the general class of air-filter units, we can assume that it also has an On/Off switch, an internal fan, and an internal filter— even though there’s no stovetop light.

click to expand
Figure 2-4: Air-filter unit with ultraviolet light. (Do dust motes glow in the dark?)

Inheriting features and performing the same behaviors differently

Okay, air filters in general have the features common to all air filters—so when we speak of a particular air-filter unit, we can focus on its specific features. By doing so, we assume you already understand that the unit has the features listed in the generic description. We’re “reusing” the generic features that all air-filter units have in common.

This leads us to two more terms that the experts use to confuse us:

Remember Inheritance: You notice that when we talk about a specific kind of air-filter unit, we assume you understand that the specific unit has the same features of any generic air-filter unit. The experts like to say the specific object inherits the features of the generic object.

Through the principle of inheritance, you “reuse” the features of a generic object when talking about or modeling specific objects.
Polymorphism: Of course, everybody studies classical Greek these days, right? So here it is again—poly meaning many, and morph meaning form. It’s when objects have the same behavior but perform it differently. For example, all air-filter units can perform the operation of turning on—but each type of unit performs that operation differently.

In this example, you notice there is a difference between the operation of the object and the method the object uses to perform the operation. In the object-oriented world, objects invoke the operations (behavior) of another object. The second object then performs some internal method (steps in a process) as a result. When you (the first object) invoke the operation of turning on the air filter unit (the second object), the air filter unit performs an internal method (it passes electricity through a switch to the fan).

The idea of polymorphism is to hide the exact method of operation behind the operation itself. You invoke the operation of an object without worrying about how the operation is performed. So when you step up to an air-filter unit, you just turn it on. The method inside the unit does the rest.

Tip When you use UML to describe general and specific objects, use the Principle of Least Surprise. You place an attribute or an operation in whatever class—generalized class or specialized class—is least likely to surprise the user.