1.1 UML profiles

UML is a large and regrettably complex language. Still, there are many requests to represent additional features explicitly that cannot be described conveniently with UML in its current version. Therefore, UML provides mechanisms, in particular stereotypes and tagged values, that allow extensions. These extensions may be defined and grouped in so-called profiles. UML-F represents such a profile, with a focus on framework description. We define a UML profile as an extension of the UML standard language with specific elements. A profile provides new notational elements and usually specializes the semantics of some elements. It may also restrict the use of UML elements.

UML is intended to cover a wide variety of application domains. It is not even restricted to describing software, but offers concepts to describe hardware as well as real-word requirements. Apparently these different domains require different modeling elements. Therefore, it became clear quite early on that UML was not going to become a single language fitting all purposes, despite all the efforts to unify its syntax, semantics, and usage. Instead, UML is a family of languages with one common core. This core is defined in the UML standard documents produced by the Object Management Group (OMG, 2001).

The UML family of languages consists of individual members that extend, adapt, restrict, and/or modify the meaning of UML elements. The UML-F variant presented in this book is such a member. For a systematic introduction of new family members, UML provides a profile mechanism. A profile describes a modification of the UML standard. Such a profile may target a specific application domain the UML-RT real-time profile (Powel Douglass, 2000) is a prominent example. Other profiles provide tool-specific extensions. For example, these might shape the UML so that it is better suited for modeling web-based systems: a Java profile would restrict the UML to single class inheritance; a JavaBean subprofile should additionally provide notational elements to mark classes that comply with JavaBean requirements. We suggest that you have a look at OMG's web sites to understand the current efforts in defining profiles.

Profiles usually build a hierarchy. Figure 1.1 shows a sample profile structure. Such profiles form the basis of tool-specific extensions, as well as project-specific extensions to already given profiles. The current challenge of the UML standardization process is to define a standard meaning for the important and widely used concepts. Only a few extensions should be project- or tool-specific. From Figure 1.1 it can be inferred that some profiles will be as standardized as UML itself is. UML-RT is the primary profile in that direction. A further layer of profiles may be available publicly for some time before it becomes an OMG standardized profile. Other profiles may only be used within companies, or even within projects. Project-specific profiles may be built on more general profiles, sometimes only adding a few stereotypes or specializing the meaning of object serialization. The UML-F profile is intended to be used publicly and is designed to be a general profile toolsmith which project-specific profiles can be based on.

Figure 1.1. Sample hierarchy of profiles illustrated as a UML package diagram

A paper by Cook et al. (1999) describes the profiling mechanism in further detail and also an extension of it, called prefaces.