After you identify the classes and objects you want to use in your system, you can start thinking about what to call them. In this section, we provide some UML naming guidelines. (For general naming tips, see the sidebar, “Perfecting your names.”)
Every project may have its own guidelines for naming classes, but your class names also need to follow some commonly obeyed rules associated with UML. If you made a list of possible names (as we discuss in the section “Recognizing Classes and Objects”), you can start with a name from the list and whip it into shape by following the refinement process illustrated in Table 3-2.
Tip Follow your organization’s rules and style when naming your classes. You may want to use different style names during different phases of your projects. It’s common to put spaces between terms in the names during analysis but to make the names more code-like by dropping the spaces as you enter the design phase.
A good class name . . . | Revised example |
---|---|
Uses a noun or noun phrase | my modern crash dummies |
Is singular not plural | my modern crash dummy |
Avoids possessives | a modern crash dummy |
Doesn’t contain irrelevant adjectives | a crash dummy |
Is bold and is centered in its box | a crash dummy |
Uses initial capital letters | A Crash Dummy |
Doesn’t have spaces between words | ACrashDummy |
Doesn’t contain articles (a, an, the) pronouns | CrashDummy |
Since the goal of a good name is to convey information quickly and accurately, avoid anything that could be confusing or that might slow down interpretation. It’s good policy to avoid using any abbreviations in any name and make sure your spelling is correct.
Almost all abbreviations have multiple meanings and can be momentarily bewildering. Even a one tenth of a second delay adds up to be significant lost time over the life of a project. If you must use acronyms, make sure they come from a limited central list of allowable abbreviations. Likewise, avoid puns and double entendres. (Impress your fellow modelers with your UML skills, not your humor.)
Also remember that spelling counts. Don’t think for a moment otherwise. Misspelling a word brands you as careless, and even worse, interferes with the rapid recognition of the name. Models are made for accurate and quick communication, which won’t happen if your audience is laughing. Proofread carefully and correct all spelling and grammar mistakes.
Okay, some of you may say you entered the field of software because you loved math and hated Language Arts (especially spelling). Unfortunately, most UML tool support doesn’t provide diagram spell checking, but all is not lost. One approach is to export your diagrams or class definitions into a word processor, such as Microsoft Word, and then run the spell checker. While you’re there, run the grammar checker, too. Your output need not be literary, but it should definitely be literate.
Naming objects is just as easy. When an object is modeled, it’s typically a specific object that we know a lot about. If the object is one of our friends, a name like Max will do. Alternatively, you can use a noun phrase that describes a specific object. If the Rent-A-Crash Dummy system found it useful to name their dummies in order of acquisition, for example, some good names might be CrashDummy001 and CrashDummy002.
During the design or implementation phases, you’ll find that some objects require more generic names. This approach is appropriate when you’re dealing with an object that is really just a variable—a slot that’s waiting for someone to put one object in it at one time and a different object at another time. Name such objects with the class name preceded by a pronoun, adjective, or article prefix, as in the following examples:
myCrashDummy currentCrashDummy aCrashDummy thisCrashDummy
If the code loops over all the dummies to check their status, you can give the variable dummy a name to indicate that it’s holding the current object under consideration.