The UML Profile for Framework Architectures
3.6 The UML-F mechanism for defining new tags
Though standard UML provides stereotypes, tagged values, and constraints as extension mechanisms, together with a set of predefined stereotypes and tagged values, it does not offer a suitable way of defining additional stereotypes or tagged values. This is comparable with a programming language that allows calling methods of predefined libraries but does not conveniently allow the definition of new ones. Any language whether it is a natural language, a programming language, or a modeling language needs to provide a mechanism for extending its vocabulary. In natural languages, new vocabulary can be expressed through already-known words. Programming languages provide definition mechanisms for classes, methods, etc. However, the UML 1.4 standard suggests the use of tables to introduce new stereotypes. UML-F clarifies and extends this technique by using a template that provides a simple but sound mechanism to introduce new tags. The presented mechanism combines a rigorous though informal description that defines the new tag in a sufficiently precise manner. Table 3.10 suggests a template for defining a new tag. In some ways this template structure resembles the description of a pattern.
There are two primary reasons for defining additional tags:
The annotation of core construction principles and patterns in UML-F relies on tags. (The following chapters present these tags and their sample application.)
Framework-specific tags can often be useful. Core abstractions in frameworks are good candidates for framework-specific tags. For example, all GUI frameworks contain an abstract class that represents visible objects such as sliders, buttons, and windows. The Java GUI frameworks Swing and AWT call that abstract class Component; ET++ provides the abstract class VObject. When dealing with such a framework, it can be useful to introduce shortcuts to mark a class that conforms to that abstraction by means of a tag, Component or VObject . Another example where a framework-specific tag can be helpful is when framework-specific patterns are introduced. A corresponding tag marks the pattern instances in the framework.
| Section name | Section purpose |
|---|---|
| Name | Defines the tag name, for example VObject . |
| Applies to | Names the modeling element(s) that it may apply to. These are typically class, interface, method, attribute, and the like. If appropriate, a diagram shows the usage of the newly introduced tag. |
| Type | Explains which values the tag may assume. Tags are often of type Boolean. For example, VObject is equivalent to VObject = true . Enumeration values can, for example, be denoted by #green, #red, #blue. Among others strings and integers are common tag types. |
| Motivation and purpose | What is the purpose of the tag? Where and how is it used? |
| Explanation of the effect | Informal, yet precise, explanations help the understanding of the meaning of a tag. |
| Expansion | Sometimes the tag serves as a shortcut. In this case, the effect of the tag can be described through an expanded diagram for example, a VObject tag stands for a certain signature. If the tag stands for an interaction protocol, this could be described through sequence diagrams. Also (partial) method implementations can be shown here. If the tag can only be described partially through expansion, the expansion shall be shown and other semantic aspects should additionally be explained. |
| Discussion | A discussion of what the tag is good for, what the caveats are, and which related tags exist, is mandatory. It is of particular interest to describe how the new tag may interact with existing tags. It may be orthogonal, conflicting, or may imply another implicit tag on related modeling elements. |
The template in Table 3.10 is a modification of the template used by Gamma et al. (1995) to define a design pattern. We apply this template to introduce the subsequent layers of UML-F tags.