Section 11.4. Constraints

11.5. UML Profiles

UML profiles combine the concepts of stereotypes, tagged values, and constraints to provide a coherent and concise dialect of UML for a specific family of applications. To make much use of a profile, some tooling must be provided. The application model drives code or application generation, so you have little or no control over the stereotypes, tagged values, or constraints comprising the profile. This section discusses the use of existing profiles (as opposed to defining your own).

Figure 11-6 depicts a partial UML profile defining a stereotype with its associated tagged values and a couple of constraints, as you might receive in a vendor's documentation. The profile extends classes with a stereotyped class, «EJBEntityBean» . It extends attributes with two stereotyped attributes: «EJBPrimaryKey» and «EJBCmpField» . It declares the respective tagged values for the stereotyped classes and attributes, and it declares the enumeration, transactionIsolationLevel , to define the allowable values for the TRansactionAttribute tagged value. The profile also adds the constraints that «EJBEntityBean» classes must have attributes of type «EJBCmpField» and «EJBPrimaryKey» . Furthermore, attributes having these stereotypes can exist only in an «EJBEntityBean» class. From your point of view, the profile, along with its constituent stereotypes and tagged values, is read-only because it tells what the third-party tool expects in order to do its job.

Figure 11-6. A partial specification UML profile

Figure 11-7 shows a portion of a model using the profile declared in Figure 11-6. Figure 11-8 indicates how the tagged value structures in the model relate back to the profile declaration. The notes containing the tagged values make the notation bulky if you need to show a set of tagged values for every class, attribute, operation, and relationship.

When aiming to expose the structure and relationships of a system, class diagrams rarely show tagged values. Referring again to Figure 11-7, one tiny class having two attributes becomes a constellation of four diagram elements. A modest class diagram of 10 classes can easily require 100 extra notes to show the tagged values, hopelessly confusing the diagram and destroying its impact. Instead, modelers often maintain the tagged values invisibly in the model, where tools can extract them as needed.

Figure 11-7. A stereotyped class and its stereotyped attributes, with their respective tagged values

Figure 11-8. The partial specification UML profile, showing model elements applying it

The UML from the profile and the model is shown in Figure 11-8. This illustrates the relationships between the declarations of the profile and a conforming model. The stereotypes in the profile extend the concept of an element. In this case, the stereotype «EJBEntityBean» extends ordinary classes, as shown (1) by the implication of the same element type (metaclass), Class . In the models applying this profile, only classes may have that stereotype, as shown by the relationship (2). Having established that the BillCurrency is an «EJBEntityBean» , it now has all the «EJBEntityBean» tagged values, as shown by the relationship (3). Stereotypes that extend other stereotypes, as «EJBPrimaryKey» extends «EJBCmpField» , have all the parent's tagged values. Ideally, tooling will aid, enforce, and validate by making available the correct tagged values and defaults according to the stereotype's definition. If not, the modeler must rely on discipline.