Section 11.2. Stereotypes

11.2. Stereotypes

Stereotypes modify the intent of the elements to which they apply. They allow the differentiation of roles of an element within the model. For example, you can quickly differentiate classes stereotyped as Controller as having a different role in the system than those stereotyped as View.

Visually, UML allows graphical and textual representation of a stereotype. Graphics and text can be combined in various ways for node-type elements, as shown in Figure 11-3. The four elements that you see going across the top of the figure all represent the same combination of Form and key stereotypes but in different ways. Edge-type elements have only a textual representation, and thus you see «depends» on the dependency between Billing and Inventory.

Figure 11-3. Various representations of stereotypes

When displayed as text, a stereotype is enclosed in guillemots («»), as in «MyStereotype». Because the guillemots require an extended character set to display correctly, you may also use double angle brackets to show a stereotype in 7-bit ASCII, as in <<MyStereotype>>.

Graphical icons are neither defined nor standardized by UML. You can expect toolmakers to extend the graphics differently, including coloring or shading, at their discretion. Avoid graphical symbols for interchange of models between different tools. However, within the controlled environment of a compatible set of tools, specialized graphics and/or colors will likely have more visual impact.

While stereotypes have been around since the initial beta versions of UML, UML 2.0 has introduced significant changes to the 1.x versions:

• Elements may have zero, one, or more than one stereotype. The use and usefulness of stereotypes have become more and more evident. More toolmakers have incorporated them into their products. Modelers found it impossible to use otherwise complimentary tools because an element can have only one stereotype.

• Stereotypes may be nested. A specialized stereotype can build on the structure of a general stereotype. In the example provided later in this chapter, the EJBPrimaryKey stereotype extends the EJBCmpField stereotype, because all primary keys are ordinary fields as well.

• Tagged values are related through a stereotype rather than directly to the element. This avoids the possibility of name clashes with the introduction of multiple stereotypes per element.

You can tag an item in a UML model with more than one stereotype. Figure 11-4 shows multiple stereotypes as a list, with each stereotype enclosed in «guillemots».

Figure 11-4. A class and an attribute, with two stereotypes each