UML profiles , stereotypes , reference etc

http://www.uml-diagrams.org/profile-diagrams.html

UML Profile Diagrams

Profile diagram is 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:

• platforms (such as J2EE or .NET), or
• domains (such as real-time or business process modeling).

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.

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 were introduced in UML 2.0 but first appeared on "official" taxonomy of UML diagrams in UML 2.2 ([UML 2.2 - Superstructure], Figure A.5).

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

You can find some profile diagram examples here:

• SoaML UML Profile
• Java EJB 3.0 UML Profile
• DICOM UML Profile

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.

Profile EJB

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

Profile Servers

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.

Note, that UML specification here mingled two different specifications. The whole URI value should follow obsolete URI specification RFC 2396 (see: URI package attribute), while qualified-profile-parent part should also be (or will be made) valid XML QName. XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to the URI requirement.

EJB Profile shown as a package with URI attribute.

Metaclass

Metaclass is a profile class and a packageable element which may be extended through one or more stereotypes.

A metaclass may be shown with the optional stereotype «Metaclass» shown above or before its name (all lower-case «metaclass» was used in UML versions prior to 2.4).

Metaclass Component

Metaclass may be extended by one or more stereotypes using special kind of association - extension.

Stereotype Computer extends metaclass Device

Stereotype

Stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass.

A stereotype cannot be used by itself, but must always be used with one of the metaclasses it extends. Stereotype cannot be extended by another stereotype.

A stereotype uses the same notation as a class, with the keyword «stereotype» shown before or above the name of the stereotype. Stereotype names should not clash with keyword names for the extended model element.

Servlet Stereotype extends Component.

Stereotype can change the graphical appearance of the extended model element by using attached icons represented by the Image profile class.

Stereotype Servlet with attached custom icon.

Actor is extended by stereotype Web Client with attached custom icon.

Because stereotype is a class, it may have properties. Properties of a stereotype are referred to as tag definitions. When a stereotype is applied to a model element, the values of the properties are referred to as tagged values.

Device extended by Server stereotype with tag definitions and custom icon.

Stereotype Application

Profile diagram is used to show definition of stereotype. Stereotype is applied when it is used on use case diagrams, class diagrams, deployment diagrams, etc.

When a stereotype is applied to a model element, an instance of the stereotype is linked to an instance of the metaclass. The name of the applied stereotype is shown within a pair of guillemets above or before the name of the model element.

UML versions before 2.4 required the first letter of the name of the applied stereotype to be in lower case (e.g. «servlet»). Starting from UML 2.4, the first letter should normally be in upper case. Naming stereotype applications with lower-case letters where the stereotypes themselves are defined using upper-case first letter is still valid but is considered obsolete.

Stereotype «Servlet» applied to
the model element SearchServlet

If multiple stereotypes are applied to the same element, the names of the applied stereotypes are shown as a comma-separated list within a pair of guillemets.

When the extended model element has a keyword, then the stereotype name could be displayed close to the keyword, within separate guillemets (example: «device» «server»).

When a stereotype includes the definition of an icon, this icon can be graphically attached to the model elements extended by the stereotype. Every model element that has a graphical presentation can have an attached icon. When a model element is extended by one single stereotype the icon can be presented in a reduced shape, inside and on top of the box representing the model element.

Servlet stereotype applied to the class SearchServlet.

When stereotype is applied, the whole classifier box can be replaced by enlarged icon of the stereotype.

Servlet stereotype applied to the class SearchServlet.

Some model elements are already using an icon for their default presentation. A typical example of this is the actor model element, which uses the "stickman" icon. In that case, when a model element is extended by a stereotype with an icon, the stereotype’s icon replaces the default presentation icon within diagrams.

«Web Client» stereotype applied to the Geek actor.

Computer stereotype with tags applied to Device class.

Stereotype Relationships

A stereotype must always be used in conjunction with one of the metaclasses it extends. A metaclass may be extended by one or more stereotypes. Each stereotype may extend one or more metaclasses.

Stereotypes can participate in binary association. The opposite class can be another stereotype, a non-stereotype class owned by a profile or a metaclass. The stereotype must own property at the association end to be able to navigate to the opposite class. If the opposite end is not a stereotype, the opposite property must be owned by the association itself.

A stereotype may generalize or specialize only another stereotype.

Abstract stereotype Session EJB is specialized by
stereotypes Stateless EJB and Stateful EJB.

Tag Definition

Properties of a stereotype are referred to as tag definitions (or metaproperties).

Stereotype Computer with tag definitions for vendor, CPU, and memory

Tagged Value

Stereotype is applied when it is used on use case diagrams, class diagrams, deployment diagrams, etc.

When a stereotype is applied to a model element, the values of its properties may be referred to as tagged values.

UML 1.x defined tagged value as one of UML extensibility mechanisms permitting arbitrary information (which could not be expressed by UML) to be attached to models. Tagged value is a keyword-value pair that may be attached to any kind of model element.

The keyword is called a tag. Each tag represents a particular kind of property applicable to one or many kinds of model elements. Both the tag and the value are usually encoded as strings though UML tool allow to use other data types for values.

Tagged value specification in UML 1.x has the form
  name = value
where name is the name of a tag or metamodel attribute and value is an arbitrary string that denotes its value. For example,
  {author="Joe Smith", deadline=31-March-1997, status=analysis}

Boolean tags frequently have the form isQuality, where quality is some condition that may be true or false. In these cases, the form "quality" may usually appear by itself, without a value and defaulting to true. For example, {abstract} is the same as {isAbstract=true}. To specify a value of false, omit the name completely. Tags of other types require explicit values.

Tagged value (as well as metamodel attribute) is displayed as a comma delimited sequence of properties inside a pair of curly braces "{" and "}".

Stereotype Computer applied
using "traditional" tag values notation.

In UML 1.3 tagged values could extend a model element without requiring the presence of a stereotype. In UML 1.4, this capability, although still supported, wasdeprecated, to be used only for backward compatibility reasons.

Since UML 2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. To support compatibility with the UML 1.3 some UML tools can automatically define a stereotype to which "unattached" attributes (tagged values) will be attached.

Tag values could be shown in class compartment under stereotype name. An additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets.

Stereotype Computer applied with tag values in compartment

Tag values could be shown in attached comment under stereotype name.

Stereotype Computer applied with tag values in comment note

When displayed in compartments or in a comment symbol, each name-value pair should appear on a separate line.

Extension

An extension is association relationship used to indicate that the properties of a metaclass are extended through a stereotype, and gives the ability to flexibly add stereotypes to classes and remove later, if necessary.

One end of the extension association is an ordinary property and the other end is an extension end. The property ties the extension to a metaclass, while theextension end ties the extension to the stereotype extending the metaclass.

Extension end is a navigable end, owned by extension. This allows a stereotype instance to be attached to an instance of the extended classifier without adding a property to the classifier. Note, that until UML 2.3 extension end was "never navigable".

The notation for an extension is an arrow with the filled triangle arrowhead pointing from a stereotype to the extended metaclass.

Metaclass Class is extended by stereotype Customer.

Because extension is subclass of association, it may have usual association adornments, but navigability arrows should not be shown. Adornments of an extension are typically suppressed.

A non-required extension means that an instance of a stereotype can be linked to an instance of an extended metaclass at will, and also later deleted at will. However, there is no requirement that each instance of a metaclass be extended. An instance of a stereotype is deleted when either the instance of the extended metaclass is deleted, or when the profile defining the stereotype is removed from the applied profiles of the package.

By default, extension is non-required. When extension has no adornments, it could either mean the default value or that the {required} adornment was suppressed. Multiplicity 0..1 on the extension end could be used as an alternative to non-required extension.

A required extension means that an instance of a stereotype must always be linked to an instance of the extended metaclass. The instance of the stereotype is typically deleted only when either the instance of the extended metaclass is deleted, or when the profile defining the stereotype is removed from the applied profiles of the package.

Required extension is shown using the {required} property near the extension end.

Required extension of metaclass Component by stereotype WebService.

It is also allowed to use multiplicity 1 on the extension end as an alternative to the {required}.

A metaclass may be extended by one or more stereotypes. This is obvious and expected.

Each stereotype may extend one or more metaclasses. This might cause some confusion. For example, UML 2.3 specification explains its Figure 18.16 as "the same stereotype Clock can extend either the metaclass Component or the metaclass Class." Either is confusing as it suggests that extension is kind of or relationship but not and as we'd assume.

The same "either" approach is applied in [SoaML 1.0 Beta 2] - stereotype Provider extends either (or both?) Interface or Class metaclasses. The SoaML explains that Interface is used in the case of a non composite service contract while Class - in the case of a composite service contract.

Stereotype Provider extends either (or both?) Interface or Class metaclasses.

Reference

Reference is import relationship represented by "metaclassReference" element import and "metamodelReference" package import.

The "metaclassReference" element imports and "metamodelReference" package imports serve two purposes: (1) they identify the reference metamodel elements that are imported by the profile and (2) they specify the profile’s filtering rules.

The filtering rules determine which elements of the metamodel are visible when the profile is applied and which ones are hidden.

Note that applying a profile does not change the underlying model in any way; it merely defines a view of the underlying model. In general, only model elements that are instances of imported reference metaclasses will be visible when the profile is applied. All other metaclasses will be hidden. By default, model elements whose metaclasses are public and owned by the reference metamodel are visible.

Metaclass Component is referenced (imported) by profile Servlets

Profile Application

Profile application is a directed relationship used to show which profiles have been applied to a package.

One or more profiles may be applied to a package that is created from the same metamodel that is extended by the profile. Applying a profile means that it is allowed, but not necessarily required, to apply the stereotypes that are defined as part of the profile.

It is possible to apply multiple profiles to a package as long as they do not have conflicting constraints. If a profile that is being applied depends on other profiles, then those profiles must be applied first.

When a profile is applied, instances of the appropriate stereotypes should be created for those elements that are instances of metaclasses with required extensions. The model is not well formed without these instances.

Once a profile has been applied to a package, it is allowed to remove the applied profile at will. Removing a profile implies that all elements that are instances of elements defined in a profile are deleted. A profile that has been applied cannot be removed unless other applied profiles that depend on it are first removed.

Applied profile is shown using a dashed arrow with an open arrowhead from the package to the applied profile. The keyword «apply» is shown near the arrow.

Profiles Java and Servlets applied to package WebApplication.

If multiple applied profiles have stereotypes with the same name, it may be necessary to qualify the name of the stereotype with a profile name.