Naming Your Associations
When you name an association, use a verb phrase that best describes what these two classes do with (or to) each other. If you consider the classes at either end of an association along with the association name, then the whole thing can be read as a sentence, such as, “A client rents a crash dummy.”
Tip Try to find an active verb phrase that relates the two classes. This enables others to understand your diagrams more easily.
Although associations have meaning in both directions, the name you choose should be readable from left to right or from top to bottom when someone is looking at your diagram. When you build class diagrams with many classes and associations, however, you cannot avoid having some of your association names running in the wrong direction. If you must use an association name that reads from right to left or bottom to top, then use a small arrowhead—the name-direction arrow (as in Figure 4-3)—to help the reader. Considered as a sentence, the association in Figure 4-3 reads like this: “Test equipment monitors a crash dummy.”
Figure 4-3: Use of arrowheads for reading association names.
Warning Some UML modeling tools (software that helps you draw UML diagrams and may generate code as a result) don’t have the directional-arrowhead feature that UML requires. In such cases, we use the keyboard symbols in Table 4-1 as substitutes for the arrowheads. If possible, however, we recommend using name-direction arrows (if your UML modeling tool provides them) to help other developers know exactly what you mean.
| Symbol | Keyboard Keys | Purpose |
|---|---|---|
| < | Shift+, (comma) | Read association from right to left |
| ^ | Shift+6 | Read association from bottom to top |
| > | Shift+. (period) | Read association from left to right |
| v | Lowercase v | Read association from top to bottom |
Tip We highly recommend that you name your associations. Names emphasize relationships instead of data flow (more about that in the sidebar, “Noname associations”); they also increase the readability of your diagrams by leaps and bounds. After all, UML is all about effective communication with other developers. When we return to a class diagram months after we put it together, the association names help us remember what we had in mind months earlier.
 |
Watch out for class diagrams with lots of classes and associations that have no names. This indicates the modeler is not thinking about objects interacting together—and may be trapped in thinking about getting data from one place to another.
When they program, many expert developers use a functional mindset—worrying about the data that must be poured into each function, constantly working to get data from one function to another. They speak of “data flow.” When these functional programmers start using object-oriented techniques and languages, they want the data to flow from one object to another just as if it were moving from one function to another.
So why does someone create a class diagram with “noname” associations? Well, some developers start by drawing a few classes with attributes and operations. Then they focus on one of the classes and think about the data it needs. Next, they see that another class has an attribute with the right data. Finally, they draw a line (association) from the class with the data to the class that needs the data—but they don’t bother to name the association. If you ask them to read the association in the recommended way (class name, verb phrase, class name) so it describes how the two classes relate, they can’t come up with a good verb phrase. They haven’t really thought about the nature of the interaction between the two objects—just the data flow.
For example, suppose we need to route the data about a crash dummy after a bumper test—say, from the test equipment to a TV monitor. But object-oriented programs are about getting objects to interact in different ways to accomplish particular tasks or functions—they’re not about data flow. The crash dummy is not really associated with the TV monitor; the test equipment has that association. The test equipment monitors the data about the state of the dummy; the TV receives the summarized results from the test equipment. We would model this situation by drawing one association between the crash dummy and the test equipment, and another association between the test equipment and the TV monitor.
Remember, one object can ask another object for information. The second object can in turn ask a third object for that information, and then return the result to the first. This is done all the time in the real world. For example, our bosses are always asking us for stuff. We just turn to the Internet, get an answer, and turn it around to the boss—who has no direct relationship to all the things we used to get the information.
So, to avoid getting stuck in the functional mindset, associate classes that really interact—and give those associations accurate, natural-sounding names. Don’t worry about data flow.
|
EAN: 2147483647
Pages: 193