Profiles and Stereotypes

From nUML

Contents 1 Introduction 2 Defining Stereotypes 2.1 Definitions 2.2 XMI Representation 2.3 Graphical Representation 2.4 Stereotype Attributes vs. Tag Definitions 3 Applying Stereotypes 3.1 Rules 3.2 Graphical Representation 3.3 Model Elements 3.4 XMI Representation 4 Sample Program

Introduction

In this article we'll discuss how to handle UML profiles, stereotypes and stereotype applications with nUML.

Before we get started, it is worth mentioning that nUML's implementation of profiles is not 100% compliant with the UML 2.x standard. This is due to the fact that compliance in this area is really difficult to get; it suffices to read the XMI serialization of models generated with leading UML tools to see how they differ amongst them and with the specification itself.

It is recommended to read the specification before continuing; it can be found here: Unified Modeling Language (UML)

Bear in mind that current version of nUML tracks UML 2.0, and the current version of the UML standard is 2.1.1. There are some minor differences between versions, but the core problems that hinder interoperability (regarding the application of stereotypes) are still there.

This article makes use of features that are available since version 0.4.

Defining Stereotypes

Definitions

A Profile is a specialized package, whose purpose is to contain Stereotypes.

A Stereotype defines how an existing metaclass may be extended. By "metaclass", we mean one of the elements that compose the UML language (i.e. Class, Interface, Package, Association, etc.) This implies that an instance of a stereotype is associated with an instance of its related metaclass.

Consider the following model:

This is a stereotype definition, and means that we have a stereotype named Remote, which can be applied to interfaces.

The line with the solid triangle is an Extension, which is a specialization of Association. The end at the left is a specialization of Property called ExtensionEnd, and is the value of the extension's ownedEnd attribute; the type of this property is the stereotype Remote. The end at the right is a regular property, owned by the Stereotype via its ownedAttribute attribute. This property is typed by the class "Interface". The keyword metaclass in the "Interface" class is shown to remark that this class should be interpreted as belonging to the UML metamodel, not to the user model.

XMI Representation

The following is an XMI representation of this model:

<?xml version="1.0" encoding="utf-8"?>
<xmi:XMI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmi:version="2.1"
xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/xmi/2.1">

 <uml:Profile xmi:id="1" name="SampleProfile">

   <ownedMember xmi:type="uml:Stereotype" xmi:id="_Remote" name="Remote">
     <ownedAttribute xmi:id="5" name="base_Interface" visibility="private" type="_UML_Interface" association="3" />
   </ownedMember>

   <ownedMember xmi:type="uml:Extension" xmi:id="3" name="Remote extends Interface" memberEnd="5">
     <ownedEnd xmi:id="4" name="extension_Remote" visibility="private" lower="0" type="_Remote" />
   </ownedMember>

 </uml:Profile>

 <uml:Model xmi:id="_UML" name="UML">
   <ownedMember xmi:type="uml:Class" xmi:id="_UML_Interface" name="Interface" />
 </uml:Model>

</xmi:XMI>

Graphical Representation

For clarity sake, we present a diagram that represents the model discussed above.

Note: the boxes in the upper image should be interpreted as instances, not classes.

Stereotype Attributes vs. Tag Definitions

In UML 2.x, stereotypes are allowed to have owned attributes (instances of Property). This mechanism replaces Tag Definitions from UML 1.x.

Adding an string attribute (formerly known as tag definition) named "magic" to Remote would result in the following model fragment:

<ownedMember xmi:type="uml:Stereotype" xmi:id="_Remote" name="Remote">
   <ownedAttribute xmi:id="5" name="base_Interface" visibility="private" type="_UML_Interface" association="3" />
   <ownedAttribute xmi:id="7" name="magic" visibility="public" type="string" />
</ownedMember>
...
<uml:PrimitiveType xmi:id="string" name="string" />

So, as Sterotype derives from Class, everything we know about classes (at least regarding attributes) can be applied to stereotypes.

Applying Stereotypes

Rules

Once a stereotype has been defined, it can be applied to any instance of its corresponding metaclass. In the previous example, the Remote stereotype can be applied to interfaces.

Warning: The following scheme is the bit not 100% standards compliant that we mentioned earlier.

A stereotype application is just an instance of the stereotype and its features. For every element in the model definition, there's one corresponding element instantiation:

Definition	Instantiation
Stereotype	InstanceSpecification
Property	Slot
Extension	InstanceSpecification (optional)
ExtensionEnd	Slot

Graphical Representation

In user models, stereotype applications look like this:

Here we can see an interface ComputeEngine, which is extended by the Remote stereotype. The value of the "magic" attribute on Remote is "abc".

Model Elements

As we already mentioned, every element that conforms to the stereotype definition has a corresponding element in the stereotype application.

Besides the correspondence table introduced in Rules, additional model elements are required to store the actual values of the attributes in their corresponding slots. For this purpose, any of the standard model elements derived from ValueSpecification can be used. However, there's one exception: the value of the attribute base_Interface.

The attribute base_Interface is typed by the Interface metaclass, which means that its corresponding slot should have ComputeEngine as its value. However, there's no element derived from ValueSpecification that allows to specify an arbitrary model element; for this reason, we created a new metamodel element named ElementValue, which derives from ValueSpecification, and has an attribute element whose type is UML::Element. This solves the problem, abeit it introduces an incompatibility.

Note: this approach has been already suggested to the OMG; see Issue 10821: ValueSpecification that refers to some Element shall be defined

XMI Representation

The following is an XMI serialization of the presented model:

 <uml:Package xmi:id="10" name="ProfileApplication">

   <!-- "ComputeEngine" interface -->
   <ownedMember xmi:type="uml:Interface" xmi:id="_ComputeEngine" name="ComputeEngine" />

   <!-- "Remote" stereotype application -->
   <ownedMember xmi:type="uml:InstanceSpecification" xmi:id="12" name="ComputeEngine is Remote" classifier="_Remote">
     <slot xmi:id="13" definingFeature="5">
       <value xmi:type="uml:ElementValue" xmi:id="14" name="ComputeEngine" type="_UML_Interface" element="_ComputeEngine" />
     </slot>
     <slot xmi:id="15" definingFeature="7">
       <value xmi:type="uml:LiteralString" xmi:id="16" name="abc" value="abc" />
     </slot>
   </ownedMember>

   <!-- Link corresponding to the Extension element -->
   <ownedMember xmi:type="uml:InstanceSpecification" xmi:id="20" name="" classifier="3">
     <slot xmi:id="21" definingFeature="5">
       <value xmi:type="uml:ElementValue" xmi:id="22" name="ComputeEngine" type="_UML_Interface" element="_ComputeEngine" />
     </slot>
     <slot xmi:id="23" definingFeature="4">
       <value xmi:type="uml:InstanceValue" xmi:id="24" name="Remote application" instance="12" />
     </slot>
   </ownedMember>

 </uml:Package>

Sample Program

The source distribution provides a sample program, show_stereotypes, which illustrates the manipulation of models with stereotype applications. The code can be seen browsing the SVN repository with the previous link, getting a working copy with subversion, or just taking a look at the most relevant file in the sample project.