3.2 UML-F tags - standard UML tagged values and stereotypes unified

3.2 UML-F tags standard UML tagged values and stereotypes unified

If UML did not provide built-in extension mechanisms, then it would be necessary to include countless additional concepts to the core UML in order to satisfy various requirements imposed on UML. This would result in a UML even more complex than the current standard, which might well render it useless in practice.

Let us roughly compare UML, which is a software modeling language assisted by computer tools, with an ordinary programming language. An ordinary programming language defines a small set of core concepts, and libraries provide additional functionality. The most important feature of a programming language is the ability for a programmer to extend its vocabulary, and therefore its expressiveness, through the introduction of new names for methods, classes, functions, modules, and so on. In an analogous way, UML supports vocabulary extension through the introduction of new modeling elements, such as specific classes, associations, and methods. These elements can be regarded as first class elements. In addition, UML provides two extension mechanisms stereotypes and tagged values for describing specific properties of these elements. However, these two kinds of extensions are second class elements, because they apply on a 'meta' level. They do not represent phenomena of the system directly, but constrain or describe phenomena of the UML model.^[1]

^[1] Meta-modeling is comparable to the meta-programming (or reflective programming) that is provided by some programming languages such as Java. Although UML meta-modeling is a powerful concept and has great appeal for some purposes, it has a number of inherent problems and should be avoided. Therefore, we don't go into a discussion on meta-modeling in this book.

UML-F provides an enhanced mechanism that unifies stereotypes and tagged values: the UML-F tag. The standard UML stereotype and tagged value mechanisms are discussed first.

3.2.1 Stereotypes

Figure 3.2 shows a standard use of UML stereotypes and tagged values attached to a class. Stereotypes are normally written enclosed in guillemets.^[2]

^[2] Tools sometimes provide specific styles of representation for stereotypes. For example, icons may be used.

Figure 3.2. Stereotype (a) in comparison to tagged value (b)

The stereotype ActionListener attached to class AccountWindow in Figure 3.2 denotes that this class implements the ActionListener interface, as provided by the Java Swing library. This stereotype acts as a shortcut for a representation with an implementation relationship from the interface ActionListener to the class AccountWindow.

Stereotypes can be used for several purposes. A stereotype is often used to classify (mark) model elements in order to impose certain additional properties or constraints on these model elements. The property or constraint is defined informally, because UML itself does not provide a language mechanism to introduce a stereotype explicitly and bind a certain property to it.^[3] In the UML 1.4 standard, a technique based on tables is proposed to introduce new stereotypes. This technique is further elaborated in Section 3.6.

^[3] The use of OCL on the meta level (this is, on the abstract syntax of UML represented by a meta-model) is an attempt in that direction.

Some of the uses of stereotypes are as follows:

• A stereotype deals with the properties of the piece of software, for example a class, that the stereotype model element annotates. For example, stereotype ActionListener expresses that an interface ActionListener is implemented.

• The stereotype may deal with the representation of a model in a view. UML-F introduces the marker ' ' that can be regarded as a stereotype whose intention is to express that a set of elements is shown completely in the model.

• A stereotype can also describe a certain constraint. For example, persistent may express that instances of a class are storable, without prescribing how that property is implemented.

• A stereotype can also describe a methodological relationship between two modeling elements. For example, an association that is refined through an association class can have a refine connection to this class.

• A stereotype can express an intention of the modeler that any user of a model element should understand. For example, a class can be marked as adapt-static to indicate that it is a good candidate to be extended and adapted by subclasses.

• Finally, a stereotype can describe the role of a class in a collaboration pattern. This allows a compact description of the participants of particular patterns.

There is certainly overlap between these various uses of stereotypes. Furthermore, the above classification of stereotypes is probably not exhaustive as future applications of the stereotype mechanism cannot be foreseen.

3.2.2 Tagged values

Tagged values represent another UML extension mechanism. A tagged value is a pair consisting of two elements a name and a value. As with stereotypes, tagged values can be attached to any modeling element. They can describe certain properties, such as:

• an initial value of an attribute, as in Figure 3.2(b)

• the name of the creator of a class

• the version number or the date of its last change

• a string value containing a comment or a constraint on the model element

• a policy for storage or transmission over a network

• an icon for graphical representation in a case tool.

Tagged values are written in brackets in the form {tag-name = value} and are attached to model elements. Although it could be useful to build an explicit system of types on the tagged values, this has not yet been incorporated into standard UML. Even though nothing is said in the UML standard, it is a reasonable assumption within the UML-F profile that tagged values are typed for example, numbers identify the versions of a system: {version=2.0} ; and strings represent names: {created-by = Tom }

3.2.3 UML-F tags for describing properties

The usage of tagged values and stereotypes is quite similar. Indeed, the border between the mechanisms is not sharp and sometimes confusion arises as to which concept to use. Since stereotypes do not have values, tagged values in general provide more descriptive power. To overcome this restriction, the UML standard suggests attaching tagged values to stereotypes as well. Unfortunately that further complicates the use of these extension mechanisms. This gives us enough reason to adapt the usage of stereotypes and regard them as a restricted form of tagged values of type Boolean. In particular, the stereotype stereotype-name is regarded as a shortcut for the Boolean tagged value {stereotype-name = True} .

The standard UML also offers a shorthand for Boolean tagged values if the value is True: {tagged-value-name} .

In the rest of this book, a stereotype is treated as a synonym for a tagged value (or tag for short), and for a Boolean tag it is equivalent to write:

• name

• name = True

• {name}

• {name = True} .

A tag with a value of a type different from Boolean for example, a version number may be written in the equivalent forms:

• name = value

• {name = value} .

With this enhancement and unification of UML's extension mechanisms, it is now possible to attach any number of tags to a model element.^[4] Of course, not all combinations of tags are allowed and tools should therefore detect inconsistent use of tags.

^[4] We expect future versions of UML to adopt this unification of stereotypes and tagged values.

To further enhance the expressiveness of tags, UML-F allows combining tags in the form of enumerated lists, for example name1=value1; name2=value2 , provided that they are applied to the same model element. In addition, UML-F introduces another shortcut. If the type of the tag is a string, then name is a shortcut for attaching a tag with an empty string: name= . This allows us to apply a tag of type string omitting the string if it is not of interest in a certain situation. As strings are often used as values, we also find it convenient to write name:value instead of name= value , and name1,name2:value as a shortcut for attaching the same string value to several tags: name1= value ; name2= value . Figure 3.3 illustrates the use of UML-F tags.

Figure 3.3. Sample UML-F tags