Pragmatic Guidelines: Diagrams That Work - Define Your Own UML with Stereotypes
(Page 6 of 8 )

We have seen stereotypes a lot in our models so far. Now it’s time to explore them a little more completely.

An important thing to realize is that the U in UML means Unified, not Universal (a common misconception). The UML authors recognized early on that a “universal” notation is an impossible dream: any attempt to make a universal notation was doomed to fall short, but would end up with a large, bloated notation that no one could use.⁸

So instead of striving for universal, the UML authors settled on extensible; and the primary extensibility mechanism they defined is stereotypes. A stereotype is a label applied to an existing element of UML notation that carries some extra meaning beyond the UML element itself. When you define a stereotype, you may also define a custom icon for that stereotype that replaces the standard icon for the base element. Then, when the stereotyped element appears in a diagram, you may show the stereotype either by using the custom icon (if any) or by listing the stereotype name in guillemets (« ») or double angle brackets.

In essence, stereotypes allow you to define your own “dialect” of UML: particular recurring modeling concepts that you want to express with a shorthand visual or text notation.

To define a new stereotype, first . . . well, first go read the Three Amigos’ The Unified Modeling Language User Guide and The Unified Modeling Language Reference Manual. Although not universal, the UML is huge. It contains many obscure notations for special needs. Then go read their Unified Software Development Process for some useful stereotypes that they recommend for business and process modeling. Review other sources and see if the stereotype you need already exists. Before you go reinventing the wheel, see if someone will give you one, one that other people may already recognize.

But after you’re sure that you need a new stereotype, find the UML element that comes closest to your new concept. Often this will be a class or actor; but it might be a use case, a component, or any other element of a UML model. Then define a stereotype named for the new concept. Document the new stereotype: what it means, why you need it, why it occurs often enough that a simple note won’t suffice, and why an existing UML element won’t suffice.

After that, you can apply your stereotype throughout your model. When someone asks what the stereotype means, point them to the documentation, and then answer their questions. The purpose of the stereotype is to make a simple way to communicate complex recurring concepts; but before you can use it, you have to make sure people understand the complex concepts.

Don’t get carried away with custom stereotypes. You need them occasionally, and they can really increase communication within your team; but there’s a risk that they will decrease communication with newcomers who do not yet know the stereotypes. For instance, I find that casual readers of Use Case Diagrams can get confused by actors, because they are depicted as stick figures even when they don’t represent people. Sometimes a reader will even ask, “Who is this person called ‘Mainframe’?” So I usually define the following custom stereotypes and icons in my designs:

    
                                                       

These should be familiar concepts that are obvious to anyone who reads the diagrams. If the intent of the diagram is communicated more clearly by using custom icons, use them! But this customization may be carried too far. For instance, this icon may connote a great deal of information to someone who knows the Kennel Management System, but not as much to other readers.

                                                         

Pet Worker is anyone who works with pets directly, as opposed to someone who works with the system but not with pets. So Care Giver might be a Pet Worker, but Accountant probably would not be. So this may be a useful stereotype for the Kennel Management System problem domain, but it may confuse someone outside that domain.

One final warning in regard to stereotypes: do not use them when you really need a superclass/subclass relationship, i.e., when you want to use inheritance (as described in Chapter 1). Stereotypes are about extending UML itself, not about relationships between classes in the code.

Stereotypes: A .NET Perspective

.NET has a few concepts that are not well represented in UML. For instance, .NET supports properties, which look like attributes to outside client code but behave like operations internally. These and other unique .NET features will be represented with stereotypes, as we’ll see in later chapters.

Next: Just Enough Modeling: Analysis, Not Paralysis >>
 

More Practices Articles
More By Apress Publishing

Comments On: Pragmatic Guidelines: Diagrams That Work

>>> Be the FIRST to comment on this article!

Buy this book...

This article is excerpted from chapter three of the book UML Applied: A .NET Perspective, written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872). Check it out at your favorite bookstore. Buy this book now.