There are other built-in stereotypes that may prove useful in helping you define classes. These stereotypes are as follows:

• Two stereotypes differentiate between primary and secondary logic or control flow. The «focus» stereotype signifies that a class provides primary logic; the «auxiliary» stereotype signifies that a class supports one or more «focus» classes.  

Within Figure 1-24, the GLReport class contains logic for formatting and printing a report that contains information provided by the General Ledger class.

Figure 1-24.  Auxiliary and focus stereotypes

• Three stereotypes signify sets of values that have no identities and that can’t be changed by operations.

The «dataType» stereotype is the “parent” stereotype. Figure 1-25 shows two examples of user-defined data types.

Figure 1-25.  Data types

The «enumeration» stereotype signifies an ordered list of literals. Figure 1-26 shows an example of a user-defined enumeration.

Figure 1-26.  Enumeration

This enumeration might be a useful alternative to the BookAndAuthor class that appeared earlier in the chapter. If that class weren’t present, it’s likely that the Author class will have an AuthorRole attribute.

The «primitive» stereotype signifies a data type built in to the UML. There are four primitive types: Boolean, Int, String, and UnlimitedNatural. (The latter is equivalent to “real.”)

• The «utility» stereotype signifies that the attributes and operations that belong to a class all have class scope—in other words, the attributes and operations define data, or operate on data, for the class as a whole, as there are no instances of the class.

• Two stereotypes offer a way to differentiate classes when you start modeling implementation.

The «specification» stereotype signifies that a class specifies the characteristics of a set of objects without defining the physical implementation of those objects.

The «implementationClass» stereotype signifies that a class provides a static physical implementation of its objects. An implementation class is usually associated with a static class within a programming language, such as C++.

• You can use «stereotype» itself as a stereotype to signify that a class is itself a stereotype that can be applied to other elements of your model.

Within Figure 1-27, the class HTMLPage also serves as a stereotype that applies to FormPage and InformationalPage.

Figure 1-27.  Stereotype as stereotype

• The «metaclass» stereotype signifies that all instances of a class are them selves classes. For example, Class is the metaclass of classes you’ve seen to this point, such as HTMLPage. This is useful if you’re exploring more expansive ways to expand the UML. Unfortunately, metamodeling is beyond the scope of this book.

In Chapter 2, you look at the various kinds of relationships in which classes can be involved. The combination of classes and relationships forms the heart of the UML’s structural modeling constructs.

1 Scott Ambler, Agile Database Techniques: Effective Strategies for the Agile Software Developer (New York, NY: John Wiley & Sons, 2003).

2 David Bellin and Susan Suchman Simone, The CRC Card Book (Boston, MA: Addison-Wesley, 1997).

3 Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software (Englewood Cliffs, NJ: Prentice-Hall, 1990).

4 Doug Rosenberg with Kendall Scott, Use Case Driven Object Modeling with UML (Boston, MA: Addison-Wesley, 1999).

5 Jos Warmer and Anneke Klempe, The Object Constraint Language: Precise Modeling with UML (Boston, MA: Addison-Wesley, 1998).

6 Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Boston, MA: Addison-Wesley, 1995). Note that this group of authors is often referred to as the “Gang of Four.”