Chapter 6. Using UML profiles

In this chapter we discuss the extensibility of UML, based on the information available in [UML-DIAGRAMS.ORG]. It is permitted to extend the language in controlled ways. These mechanisms are used to tailor the UML to the specific needs by creating standardized collections of UML elements that may be reused.

Profile diagram is a structure diagram which describes lightweight extension mechanism to the UML by defining custom stereotypes, tagged values, and constraints. Profiles allow adaptation of the UML metamodel for different:

For example, semantics of standard UML metamodel elements could be specialized in a profile. In a model with the profile "Java model," generalization of classes should be able to be restricted to single inheritance without having to explicitly assign a stereotype «Java class» to each and every class instance.

The profiles mechanism is not a first-class extension mechanism. It does not allow to modify existing metamodels or to create a new metamodel as MOF does. Profile only allows adaptation or customization of an existing metamodel with constructs that are specific to a particular domain, platform, or method. It is not possible to take away any of the constraints that apply to a metamodel, but it is possible to add new constraints that are specific to the profile.

Metamodel customizations are defined in a profile, which is then applied to a package. Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages.

OMG now (as of April 2014) provides a number of UML Profile Specifications that are useful to tailor the language to specific areas—some for business modeling; others for particular technologies. These specifications include profiles for BPMN processes, CORBA, QoS and Fault Tolerance and Testing. Besides those formally specified profiles, UML Superstructure informally describes additional example profiles for J2EE/Enterprise Java Beans (EJB), COM and .NET components.

Profiles can be dynamically applied to or retracted from a model. They can also be dynamically combined so that several profiles will be applied at the same time on the same model.

Profiles were present in UML 1.x. Profile diagrams have been introduced in UML 2.0 but first appeared on "official" taxonomy of UML diagrams in UML 2.2.

Graphical nodes and edges drawn on profile diagrams are: profile, metaclass, stereotype, extension, reference, profile application.

Profile

Profile is a profile package that extends a reference metamodel (such as UML) by allowing to adapt or customize the metamodel with constructs that are specific to a particular domain, platform, or a software development method. In other words, profile is a lightweight extension mechanism to the UML standard.

A profile introduces several constraints, or restrictions, on ordinary metamodeling through the use of the metaclasses defined in this package. The primary extension construct is stereotype, which is defined as part of profile and extends some metaclass.

A profile is a restricted form of a reference metamodel that must always be related to some reference metamodel that is created from MOF such as UML or CWM. It is not possible to define a standalone profile, without its reference metamodel.

Profile uses the same notation as a package, with the addition that the keyword «profile» is shown before or above the name of the package.

Figure 6.1. Profile EJB [UML-DIAGRAMS.ORG]

A profile can define classes, stereotypes, data types, primitive types, enumerations.

Figure 6.2. Profile Servers [UML-DIAGRAMS.ORG]

One profile might reuse some or all parts of another profile, to extend already existing profiles. Multiple profiles could be applied to the same model.

The constraints that are part of the profile are evaluated when the profile has been applied to a package. These constraints need to be satisfied in order for the model to be well-formed.

Package since UML 2.4 has optional URI attribute which serves as unique identifier of the package. Profile is a package, and the URI attribute was introduced mostly to support exchange of profiles using XMI.

The URI attribute of a profile may be rendered in the form {uri=uri} after the profile name. OMG normative profiles follow OMG normative naming scheme for URIs. For non-standard, custom profiles convention recommended by OMG looks like:

uri ::= http://qualified-profile-parent/profile-version/profile-name.xmi

• qualified-profile-parent is the qualified name of the package containing the profile (if any), with "::" replaced by "/" (forward slash), and all other illegal XML QName characters removed. For example: www.uml-diagrams.org/profiles.

• profile-version is a profile version id. OMG normative profiles use for this purpose date in the format YYYYMMDD, for example: 20110331.

• profile-name is the name of the profile, should contain only valid XML QName characters. For example: ejb-30.

Figure 6.3. EJB Profile shown as a package with URI attribute [UML-DIAGRAMS.ORG]