Class descriptions


Extension (from Profiles)

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

Description

Extension is a kind of Association. One end of the Extension is an ordinary Property and the other end is an

ExtensionEnd. The former ties the Extension to a Class, while the latter ties the Extension to a Stereotype that extends the Class.

Attributes
  • / isRequired: Boolean
Indicates whether an instance of the extending stereotype must be created when an instance of the extended class is created. The attribute value is derived from the multiplicity of Extension::ownedEnd; a multiplicity of 1 means that isRequired is true, but otherwise it is false. Since the default multiplicity of an ExtensionEnd is 0..1, the default value of isRequired is false.

Associations
Constraints

[1] The non-owned end of an Extension is typed by a Class.

metaclassEnd()->notEmpty() and metaclass()->oclIsKindOf(Class)

[2] An Extension is binary, i.e., it has only two memberEnds.

memberEnd->size() = 2

Additional Operations

[1] The query metaclassEnd() returns the Property that is typed by a metaclass (as opposed to a stereotype)

Extension::metaclassEnd(): Property;
metaclassEnd = memberEnd->reject(ownedEnd)

[2] The query metaclass() returns the metaclass that is being extended (as opposed to the extending stereotype).

Extension::metaclass(): Class;
metaclass = metaclassEnd().type

[3] The query isRequired() is true if the owned end has a multiplicity with the lower bound of 1.

Extension::isRequired(): Boolean;
isRequired = (ownedEnd->lowerBound() = 1)

Semantics

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. The model is not well-formed if an instance of the stereotype is not present when isRequired is true.

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 further 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.

In order to be able to navigate to the extended metaclass when writing constraints, the end must have a name. If no name is given, the default name is baseClass.

Notation

The notation for an Extension is an arrow pointing from a Stereotype to the extended Class, where the arrowhead is shown as a filled triangle. An Extension may have the same adornments as an ordinary association, but navigability arrows are never shown. If isRequired is true, the property {required} is shown near the ExtensionEnd.



Presentation Option

It is possible to use the multiplicities 0..1 or 1 on the ExtensionEnd as an alternative to the property {required}. Due to how isRequired is derived, the multiplicity 0..1 corresponds to isRequired being false.

Style Guidelines

Adornments of an Extension are typically elided.

Examples

In Figure 448, a simple example of using an extension is shown, where the stereotype Home extends the metaclass



An instance of the stereotype Home can be added to and deleted from an instance of the class Interface at will, which provides for a flexible approach of dynamically adding (and removing) information specific to a profile to a model.

In Figure 449, an instance of the stereotype Bean always needs to be linked to an instance of class Component since the Extension is defined to be required. (Since the stereotype Bean is abstract, this means that an instance of one of its concrete subclasses always has to be linked to an instance of class Component.) The model is not well-formed unless such a stereotype is applied. This provides for a way to express extensions that should always be present for all instances of the base metaclass depending on which profiles are applied.


Changes from UML 1.4

Extension did not exist as a metaclass in UML 1.x.

Occurrences of Stereotype::baseClass of UML 1.4 is mapped to an instance of Extension, where the ownedEnd is typed by Stereotype and the other end is typed by the metaclass that is indicated by the baseClass.

ExtensionEnd (from Profiles)

An extension end is used to tie an extension to a stereotype when extending a metaclass.

Description

ExtensionEnd is a kind of Property that is always typed by a Stereotype.

An ExtensionEnd is never navigable. If it was navigable, it would be a property of the extended classifier. Since a profile is not allowed to changed the referenced metamodel, it is not possible to add properties to the extended classifier. As a consequence, an ExtensionEnd can only be owned by an Extension.

The aggregation of an ExtensionEnd is always composite.

The default multiplicity of an ExtensionEnd is 0..1.

Attributes

No additional attributes.

Associations
Constraints

[1] The multiplicity of ExtensionEnd is 0..1 or 1.

(self->lowerBound() = 0 or self->lowerBound() = 1) and self->upperBound() = 1

[2] The aggregation of an ExtensionEnd is composite.

self.aggregation = #composite

Additional Operations

[1] The query lowerBound() returns the lower bound of the multiplicity as an Integer. This is a redefinition of the default lower bound, which was 1.

ExtensionEnd::lowerBound() : [Integer];
lowerBound = if lowerValue->isEmpty() then 0 else lowerValue->IntegerValue() endif

Semantics

No additional semantics.

Notation

No additional notation.

Examples

See "Extension (from Profiles)" .

Changes from UML 1.4

ExtensionEnd did not exist as a metaclass in UML 1.4. See "Extension (from Profiles)" for further details.

Class (from Constructs, Profiles)

Description

Class has derived association that indicates how it may be extended through one or more stereotypes.

Because a stereotype is a class, it is possible to apply a stereotype not only to classes, but also to definitions of stereotypes.

Attributes

No additional attributes.

Associations
  • / extension: Extension [*]
References the Extensions that specify additional properties of the metaclass. The property is derived from the extensions whose memberEnds are typed by the Class.

Constraints

No additional constraints.

Semantics

No additional semantics.

Notation

No additional notation.

Presentation Option

A Class that is extended by a Stereotype may have the optional keyword «metaclass» shown above or before its name.

Examples

In Figure 450, an example is given where it is made explicit that the extended class Interface is in fact a metaclass (from a reference metamodel).


Changes from UML 1.4

A link typed by UML 1.4 ModelElement::stereotype is mapped to a link that is typed by Class::extension.


Package (from Constructs, Profiles)

Description

A package can have one or more ProfileApplications to indicate which profiles have been applied.

Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

No additional semantics.

Notation

No additional notation.

Changes from UML 1.4

In UML 1.4, it was not possible to indicate which profiles were applied to a package.

Profile (from Profiles)

A profile defines limited extensions to a reference metamodel with the purpose of adapting the metamodel to a specific platform or domain.

Description

A Profile is a kind of Package that extends a reference metamodel. The primary extension construct is the Stereotype, which are defined as part of Profiles.

A profile introduces several constraints, or restrictions, on ordinary metamodeling through the use of the metaclasses defined in this package.

A profile is a restricted form of a metamodel that must always be related to a reference metamodel, such as UML, as described below. A profile cannot be used without its reference metamodel, and defines a limited capability to extend metaclasses of the reference metamodel. The extensions are defined as stereotypes that apply to existing metaclasses.

Attributes

No additional attributes.

Associations
Constraints

[1] An element imported as a metaclassReference is not specialized or generalized in a Profile.

self.metaclassReference.importedElement->
    select(c | c.oclIsKindOf(Classifier) and
    (c.generalization.namespace = self or
    (c.specialization.namespace = self) )->isEmpty()

[2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())->
    union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty()

Additional Operations

[1] The query allOwningPackages() returns all the directly or indirectly owning packages.

NamedElement::allOwningPackages(): Set(Package)
allOwningPackages = self.namespace->select(p | p.oclIsKindOf(Package))->
        union(p.allOwningPackages())

Semantics

A profile by definition extends a reference metamodel or another profile. It is not possible to define a standalone profile that does not directly or indirectly extend an existing metamodel. The profile mechanism may be used with any metamodel that is created from MOF, including UML and CWM.

A reference metamodel typically consists of metaclasses that are either imported or locally owned. All metaclasses that are extended by a profile have to be members of the same reference metamodel. A tool can make use of the information about which metaclasses are extended in different ways, for example to filter or hide elements when a profile is applied, or to provide specific tool bars that apply to certain profiles. However, elements of a package or model cannot be deleted
simply through the application of a profile. Each profile thus provides a simple viewing mechanism.

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel. However, it is possible to have associations between ordinary classes, and from stereotypes to ordinary classes. Likewise, properties of stereotypes may not be typed by metaclasses or stereotypes.

Notation

A 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::metaclassReference and Profile::metamodelReference uses the same notation as Package::elementImport and Package::packageImport, respectively.

Examples

In Figure 451, a simple example of an EJB profile is shown.



The profile states that the abstract stereotype Bean is required to be applied to metaclass Component, which means that an instance of either of the concrete subclasses Entity and Session of Bean must be linked to each instance of Component.

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



In Figure 452, the package Types is imported from the profile Manufacturer. The data type Color is then used as the type of one of the properties of the stereotype Device, just like the predefined type String is also used. Note that the class JavaInteger may also be used as the type of a property.

If the profile Manufacturer is later applied to a package, then the types from Types are also available for use in the package to which the profile is applied (since profile application is a kind of import). This means that for example the class JavaInteger can be used as both a metaproperty (as part of the stereotype Device) and an ordinary property (as part of the class TV). Note how the metaproperty is given a value when the stereotype Device is applied to the class TV.

ProfileApplication (from Profiles)

A profile application is used to show which profiles have been applied to a package.

Description

ProfileApplication is a kind of PackageImport that adds the capability to state that a Profile is applied to a Package.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

One or more profiles may be applied at will 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.

Note ­ The removal of an applied profile leaves the instances of elements from the referenced metamodel intact. It is only the instances of the elements from the profile that are deleted. This means that for example a profiled UML model can always be interchanged with another tool that does not support the profile and be interpreted as a pure UML model.

Notation

The names of Profiles are shown using a dashed arrow with an open stick arrowhead from the package to the applied profile. The keyword «apply» is shown near the arrow.

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

Examples

Given the profiles Java and EJB, Figure 453 shows how these have been applied to the package WebShopping.



Stereotype (from Profiles)

A stereotype defines how an existing metaclass (or stereotype) may be extended, and enables the use of platform or domain specific terminology or notation in addition to the ones used for the extended metaclass.

Description

Stereotype is a kind of Class that extends Classes through Extensions.

Just like a class, a stereotype may have properties, which may be referred to as tag definitions. When a stereotype is applied to a model element, the values of the properties may be referred to as tagged values.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

[1] A Stereotype may only generalize or specialize another Stereotype.

self.generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and
self.specialization.specific->forAll(e | e.oclIsKindOf(Stereotype))

[2] A concrete Stereotype must directly or indirectly extend a Class.

not self.isAbstract implies self.extensionEnd->union(self.parents.extensionEnd)->notEmpty()

Semantics

A stereotype is a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile.

Similarly, a class may be extended by one or more stereotypes.

An instance of a stereotype is linked to an instance of an extended metaclass (or stereotype) by virtue of the extension between their types.

Notation

A Stereotype uses the same notation as a Class, with the addition that the keyword «stereotype» is shown before or above the name of the Class.

When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the Stereotype. If multiple stereotypes are applied, the names of the applied stereotypes is shown as a
 comma-separated list with a pair of guillemets.

Presentation Options

If multiple stereotypes are applied to an element, it is possible to show this by enclosing each stereotype name within a pair of guillemets and list them after each other.
The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.

If the extension end is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element.

It is possible to attach a specific notation to a stereotype that can be used in lieu of the notation of a model element to which the stereotype is applied.

Style Guidelines

The first letter of an applied stereotype should not be capitalized. The values of an applied stereotype are normally not shown.

Examples

In Figure 454, a simple stereotype Clock is defined to be applicable at will (dynamically) to instances of the metaclass



Note that in order to be able to write constraints on the stereotype Clock that should be applied to the metaclass Class or any of its relationships, it is necessary to give the end typed by the metaclass a name for navigation purposes. A typical such name would be for example base.

In Figure 455, an instance specification of the example in Figure 454 is shown. Note that the extension must be composite, and that the the derived required attribute in this case is false.


In Figure 456, it is shown how the same stereotype Clock can extend either the metaclass Component or the metaclass Class. It is also shown how different stereotypes can extend the same metaclass.



Figure 457 shows how the stereotype Clock, as defined in Figure 456, is applied to a class called StopWatch



Figure 458 shows an example instance model for when the stereotype Clock is applied to a class called StopWatch. The extension between the stereotype and the metaclass results in a link between the instance of stereotype Clock and the


Next, two stereotypes, Clock and Creator, are applied to the same model element, as is shown in Figure 459. Note that the attribute values of each of the applied stereotypes can be shown in a comment symbol attached to the model element.