3.3 Extensions
One of the key capabilities of the UML is that it can be customized and tailored as needed with a number of extension mechanisms. Extensions aren't just a means of localizing the UML to provide a dialect for a project or organization. They also provide a means of cautiously evolving the language.
Extensions can be added to the language as a whole as an informal solution to a general need, and later (possibly) being translated into a full and distinctive member of the language. For example, Framework is currently handled by means of an extension, rather than having the full blessing associated with being a ModelElement, the way Model and Subsystem are handled.
There are three extension mechanisms currently available, and one way of packaging extended dialects of the UML in standardized form. The following is a basic introduction.
3.3.1 Tagged Values
Tagged values are properties of elements that are explicitly defined. They are information about the model or model element, not the system itself. The tag and its associated value are defined using the following form:
{tag = "value"}
For example:
{modeler = "L. DaVinci"}
with braces surrounding the tagged value. The tagged value can be placed inside a container or in close proximity to the model element being tagged. There are some predefined tags in the UML, such as invariant, precondition, and postcondition, which can be used (for example) to support the use of contracts.
3.3.2 Constraints
Constraints are semantic restrictions on a model element—essentially, rules or conditional statements. They can be user-defined or part of the UML generally. Like tagged values, they appear within braces, typically contained within the model element they relate to, or appear close by. For example:
{age >= 21}
There are a substantial number of UML-provided constraints.
3.3.3 Stereotypes
Stereotypes are the most powerful and used of the extension mechanisms. They provide the means to specialize existing ModelElements—in effect, by creating new ones. This way, limitations or special needs can be addressed without having to get an official change to the UML itself (although, as with tagged values and constraints, the UML includes a number of official stereotypes, and local stereotype generation needs to be handled with caution).
Currently, for example, framework is a stereotype of package, and actor is a stereotype of class. A stereotype is expressed by adding the name of the stereotype to the model element being extended. The name is enclosed in guillemets. Therefore, the framework looks like Figure 3.1.
){kind=link}
Figure 3.1 A package stereotyped as a framework.
3.3.4 Profiles
The UML provides a mechanism called a profile to act as a way of packaging a predefined set of stereotypes, tagged values, constraints, and notation icons to customize the UML for a specific domain or process. Because they are extensions, profiles don't alter the basic UML. Instead, they are intended to help in the creation and management of dialects that can be more or less local.
Two samples are included in the 1.3 Specification; one for the RUP (referred to as the Unified Process), and Business Modeling a la the Three Amigos: Ivar Jacobson, Grady Booch, and James Rumbaugh. Others have been proposed, notably for workflow and process modeling, and to handle persistence.
Although not intended this way, an organization or process profile might also be a way to document which of the UML's copious supply of formal constraints, tags, stereotypes, and keywords are legal—providing a filtering capability as well as an extending capability. A profile would then be included as part of the documentation of the architectural style for a development effort.