Figure 1. Indicating stereotypes.
- Name Stereotypes in <> and <> format.
- List Stereotypes Last. In Figure 1 the second version of the Customer class lists the stereotypes for its operations after the operation signature, not before it.
- Don’t Indicate Assumed Stereotypes. In Figure 1 I dropped the <> stereotype because it is common practice to assume that unless marked otherwise that a class is a business domain one.
- Prefer Naming Conventions over Stereotypes. For example, instead of applying the stereotype <> on an operation, you could simply start all getters with the text get. This simplifies your diagrams and increases the consistency of your source code. Normally would have ditched <> in Figure 1 but I left it there for the discussion of Tagged Values Follow Stereotypes.
- Tagged Values Follow Stereotypes.
- Center Classifier Stereotypes. The stereotype for a classifier, such as the Customer class in Figure 1 should be centered (as should the name itself).
- Introduce New Stereotypes Sparingly.
- Apply Stereotypes Consistently.
- Apply Visual Stereotypes Sparingly. Figure 2 depicts a sequence diagram which includes the standard robustness diagram symbols which are commonly applied to UML communication diagrams.