Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)

A UML profile is a variant of the UML that is specialized in some minor ways. A UML profile is allowed to contain specialized versions (called stereotypes) of the metamodel elements defined in the UML metamodel, user-defined values (properties or tags) attached to these elements, and additional well-formedness rules (constraints). A profile is not allowed to break existing UML semantics, although it is allowed to specialize them. A profile may additionally provide new graphical icons and diagrams and domain-specific model libraries. The purpose of a profile is to provide UML that is tailored for a particular vertical market domain or technology area. Thus, it is possible to have a profile for testing, for modeling quality of service, for modeling business processes, and so on. Each of these is, at its core, vanilla UML, but with some (very) minor extensions and specializations to allow it to apply in a more obvious way to the specific domain.

Because a profile is not allowed to change the semantics of the modeling language in any important or fundamental way, what are the advantages of profiling? The primary advantages are creating profiles that allow us to standardize idioms and design patterns common in a particular domain, and that allow tools to exchange models that use the profile. We shall see later that these are precisely the advantages provided for the UML Profile for Schedulability, Performance, and Time (also called the RT UML profile, or RTP) and the other profiles discussed in this chapter. As a variant of the standard, it has all the disadvantages of a standard lack of tool support, lack of trained staff, lack of reference materials, and so on. Standardizing the profile mitigates such effects but does not remove them since they appeal to a subset of the UML user community, tools may offer only limited support.

Nevertheless, profiles can be useful in modeling specific domains, especially when the members of the domain can agree on the contents and notations for the domain. A profile is simply a coherent set of specialized metamodel elements (stereotypes), named values (properties or tagged values), and rules (constraints). Once defined, a profile allows us to use these stereotypes as a part of our basic language in which to express user models, and if done well, the profile provides a richer vocabulary that is more closely aligned with the problem domain to which it is being applied.

4.1.1 Stereotypes

The UML uses stereotypes for a couple of purposes. First, and most common, is to indicate which metamodel element is typing a model element on a diagram. For example, a class box shows you the operations within the interface, and the stereotype interface identifies that this is an interface and not a class. The second primary use for a stereotype is to indicate a specialized kind of metamodel element defined within a profile.^[1] Note that you are not allowed to add fundamentally new metamodel elements to a profile they must be specializations of existing metaclasses in the metamodel.

^[1] Stereotypes were originally specified as they are so that tools wouldn't have to provide extensible schemas for their repositories while still enabling some limited extensions by users. In the four-level meta-architecture described in Chapter 2, they are approximately metalevel 1.5. Alternatively, we can specialize the UML at the level of M2 by defining new classes using the language in which the UML itself is defined the MetaObject Facility (MOF).

Stereotypes are shown in one of two ways. Either a textual annotation is attached to the metaclass being stereotyped, such as a class, relation, or node, or the default icon for the metaclass is replaced with a special icon. Figure 4-1 shows both approaches being used. Several stereo types are used. The first is for the «active» class. An «active» class owns the root of a thread and is how the concurrency model for a system is constructed with UML; instances "contained" via the composition relation (such as the instances of the MQueue class in the figure) run in the context of the thread owned by the instance of the composite active class. The UML 1.x used a class with a heavy boarder as the icon for this kind of class, while in UML 2.0 the icon is a class box with a double line border on the left and right ends. Both forms are shown in Figure 4-1.

The MQueue class is stereotyped it is a "special" kind of class called a «MessageQueue». The MQueue class also contains, via composition, a Lock class, which is likewise stereotyped to be a «Semaphore». The same stereotypes, using the textual notation option, are also shown on the figure. The MotorController class is also stereotyped to be a «motor». Last, any metaclass can be stereotyped the node shown in the figure is stereotyped to be a «Processor», but they can be applied to any kind of metaclass in the UML.

Stereotypes exist so users (and people building profiles) can add their domain's specific concepts to their modeling language in an easy, lightweight way.

4.1.2 Tagged Values

To some degree, just stereotyping something may be useful because it indicates that it is in a class of entity in your domain's conceptual landscape. Using such stereotypes may clarify the model to domain experts trying to construct or understand your system. However, stereotypes are more useful when they contain special values that apply (only) to that kind of stereotype. The first way in which stereotypes are customized is by adding what is called a tagged value or property. A tagged value is a property name value pair. It is common to identify special kinds of values that apply to this stereotype and not others, and to capture these in the model.

The tagged value provides the definition of the kind of information added to the stereotype. The actual values for particular instantiations of the stereotype (e.g., user classes based on the stereotype) are added by assigning or using the tagged values in constraints anchored to the stereotype).

A constraint is a user-defined rule or rule of correctness. The UML has many constraints in its metamodel defining the legal uses for classes, associations, and other model elements. However, these are necessarily highly generalized because the UML can be used to model systems in many domains. A constraint is a way in which a user can express a restriction that makes sense in the particular domain from which a model element is drawn. Figure 4-2 shows a typical use of constraints, combining tagged values that are defined for the stereotype.

For example, a stereotype «Semaphore» might have a tagged value called "capacity," which indicates the number of active users of a resource. In the figure, the tagged value is explicitly set to 1. Similarly, a «MessageQueue» might have a maxSize tagged value, an «active» class might have tags such as IsPeriodic, period, and so on. A «processor» node might have tagged values such as memory size, CPU speed, and endian orientation. A constraint is the classic way to specify specific values for the tags that are valid for a stereotype. Constraints, as can be seen in the figure, are normally shown inside of note boxes and within curly braces to set them off from semantic-free comments.

Given that we can use constraints to specify the values associated with the tags, how do we define the tags themselves? There are two common ways. The first, shown in Figure 4-3a, is to use a property sheet that shows in a context-sensitive way what tags are available for a particular stereotype. The second, shown in Figure 4-3b, is to show the relevant tags in a compartment labeled «tags». Either can be used, depending on your particular UML design tool and personal preference.

4.1.3 Profiles

A profile is a metamodel of some particular domain of interest, expressed using a coherent set of UML stereotypes with associated tagged values that are used via constraints, possibly accompanied by a model library specific to the domain(s) of interest. The constraint on this definition is that all of the elements of this domain metamodel must be expressed as stereotypes of predefined UML metaclasses, such as class, association, node, component, and so on. A profile is not allowed to "break" normal UML semantics, but it is permitted to subset them, specialize them, and extend them, as well as add notations as needed.