Chapter 11. Tagged Values, Stereotypes, and UML Profiles

The UML described in the previous chapters allows you to understand any UML model. You can understand the analysis of a billing system, the implementation model of a CORBA system, a gaming system in C++, or an EJB e-commerce system.

Practitioners rarely work on such diverse systems at one time, however, and no UML model will represent more than one type of application. More commonly, a practitioner (that's you) works with colleagues on one system or a series of closely related systems exclusively. For example, you might design a series of gaming systems, or a series of .Net systems. And, as you might expect, the specific concerns of a gaming system differ profoundly from those of a .Net system.

UML allows toolmakers to create a dialect called a profile, tailored to a specific niche. Within a niche, a stereotype gives specific roles to elements, and records additional context-specific information in tagged values. Profiles also include constraints that ensure integrity of use.

A practitioner familiar with a profile will immediately grasp the meaning of a model developed using that profile, because of the unique stereotypes. Moreover, the model contains deeper meaning, because of the tagged values, and the model has a higher degree of integrity, because of the constraints. This gives a distinct advantage to practitioners and tools working in the niche. People and tools unfamiliar with the profile will process it only at a formal level, without any special understanding.

Profiles are the standard mechanism to extend UML. The profile mechanism exists within UML so models applying a profile are fully UML compatible. This contrasts sharply with implementors' extensions in loosely specified languages such as C++, in which the specification allows inline assembler and #pragma statements, making it virtually impossible to port C++ programs between processors or between different compilers. A UML model applying a profile is UML, and any UML tool can process it.

Although a plethora of dialects can fragment the universality of UML, a dialect makes UML more useful. And isn't that what it's all about?