Authoring UML Profiles: Part 1. Using Rational Software Architect, Rational Systems Developer, and Rational Software Modeler to create and deploy UML Profiles

This article will show you in detail how to author UML profiles using IBM® Rational® Software Architect, IBM® Rational® Systems Developer, and IBM® Rational® Software Modeler. It addresses both UI and programmatic approaches. You should be familiar with the UML 2.1 specification.

Dusko Misic (dmisic@ca.ibm.com), Software Development Manager, IBM, Software Group

Dusko joined IBM in 2003. He has been in the software industry for over 13 years. He has worked in UML Modeler component of RSM and RSA as a Software Developer and Software Development Manager. He was directly involved with the design and implementation of RSA/RSM support for UML Profiles, OCL, and various other areas of UML modeling.



29 April 2008

Also available in Chinese

Introduction

This article is a detailed guide to the UML Profile Authoring support in the IBM® Rational® Software Architect, IBM® Rational® Systems Developer, and IBM® Rational® Software Modeler (Version 7.0 and later) products. It covers both the UI support and programmatic support (for users extending the tool itself). It mainly targets profile authors, but it also offers some insight into profile usage.

The specifically referenced versions (in chronological order as they were released) are 7.0, 7.0.0.1, 7.0.0.2, 7.0.0.3, 7.0.0.4, 7.0.0.5 (Rational Software Architect only) and 7.0.5 (Rational Software Modeler and Rational Systems Developer). This article clearly indicates where there is a difference in behavior between versions.

The information in this article applies to Rational Software Architect, Rational Systems Developer, and Rational Software Modeler. Unless otherwise specified, "Rational Software Modeler" and"Rational Systems Developer" will be used in this article to refer to version 7.0.5 or newer will be used in this article to refer to all three products.

The article assumes that you have reasonable knowledge of the UML 2.1 specification, especially the part related to Profiles. It does not attempt to further describe or clarify the specification, but rather focuses on its implementation in Rational Software Architect. General knowledge about Eclipse and Rational Software Architect will be useful as well. Eclipse PDE (plug-in development environment subproject) knowledge is required if you wish to create plug-in based profiles.


Differences between Versions 6.x and 7.x

This section provides a brief overview of the main differences in the UML profile area between Versions 6.x and 7.x. If you are familiar with UML profiles in V6.x, this could be a quick starting point for using them in V7.x.

  • Full support for stereotype/class attributes typed by a class defined in the profile. V6.x only supported definition with the limited read-only support: there were no editing capabilities.
    Note: Full support is provided only if the attribute’s aggregation feature is set to containment.
  • Associations between stereotypes and UML 2.1 metaclasses. Essentially, support for stereotype/class attributes typed by UML 2.1 metaclasses.
  • Associations between two stereotypes residing in the same profile. Essentially, support for stereotype/class attributes typed by stereotypes.
    Note: This was introduced in Rational Software Architect V7.0.0.2.
  • Profiles can be applied to other profiles.
  • Profiles can be imported into other profiles.
  • Profile Editor has been redesigned. It now supports version management, profile documentation, applied profiles section, imported model libraries section, imported profiles section, list referenced and referencing models and profiles. Rational Software Modeler and Rational Systems Developer V7.0.5 and later also has a list of the profile’s diagrams.
  • Support for class diagrams (Rational Software Modeler and Rational Systems Developer 7.0.5 or newer only).
  • Profile tooling generation (Rational Software Modeler and Rational Systems Developer 7.0.5 or newer only).
  • Prevalent usage of stereotype decorations through the tool: not limited to Model Explorer (now Project Explorer) and diagrams only. Most notably, the Select Element dialog supports stereotype decorations as well. Corresponding preferences were improved and streamlined.
  • Improved Select Metaclass dialog (for creating metaclass extensions). Supports search by type-in.
  • Improved Select Profile dialog (for applying profiles). Adds browse in workspace option.
  • Ability to create metaclass extensions through Project Explorer, not just in the Properties view. In Rational Software Modeler and Rational Systems Developer 7.0.5 or newer only, you can also do this through diagrams.
  • Stereotype and stereotype attributes support UI read-only flags.
    Note: this was introduced in Rational Software Architect V7.0.0.2.
  • Improved save behavior. Validation is run during the save and, if there are any errors, a profile version is not generated.
  • Improved release process. It now reuses the last non-released version thus enabling migration from non-released to released version of the profile even in test models.
  • Legacy version support for deployed profiles: the profile can be registered with some versions declared as legacy versions, and these versions get preferential treatment in apply and migration scenarios (Rational Software Modeler and Rational Systems Developer 7.0.5 or newer only).

Creating a profile

This section covers how to create a profile and its content. It also explores various features available to you in regards to the profile definition.

Rational Software Architect UML Profiles are files with the .epx extension. The tool provides creating and editing capabilities only for files that are in the workspace. However, after you create a profile it does not necessarily have to be in the workspace to be used in models that are in the workspace: this is covered in more detail in the Deployment section in Part 2 of this series.

Rational Software Architect also supports Eclipse's open source .profile.uml format for the purpose of applying it to a UML Model. It does not directly support editing files in this format, although you could edit them using the open source (Eclipse UML2) editor.

The rest of this article focuses on Rational Software Architect's native profile format (.epx). For more details on the Eclipse open source format, please see the Resources section.

The Modeling perspective is the best equipped for profile authoring. The two main views used in profile authoring are the Project Explorer and the Properties view. You use the Project Explorer to build the elements of the profile, and the Properties View to set their properties. Rational Software Modeler and Rational Systems Developer also provide support for diagrams that can be used to build and visualize the profile.

New Profile

You can create a new profile either by launching the New UML Profile wizard (shown in Figure 1) or the New UML Profile Project wizard. To launch the New UML Profile wizard, click File > New > Other and then Modeling > UML Extensibility > UML Profile.

Figure 1. New UML Profile wizard
Profile Name, File Name, and Destination Folder

The New UML Profile wizard creates a profile in the specified folder. The name of the profile does not have to match the name of the file containing it, although it probably simplifies things if they are the same. The model libraries could be imported during the profile creation, but that could be done afterwards as well.

The New UML Profile Project wizard simply provides a shortcut to create a project and a profile in it at the same time. Please note that the profile does not have to be stored in Profile Project: you can place it in any project.

After the profile is created, it will be selected in the Project Explorer. Also, Figure 2 shows the Profile Editor associated with the .epx file that opens.

Figure 2. Profile editor
profile information, versions, and documentation

The Profile Editor is associated with the .epx file itself (see Figure 3). It has 3 tabs: Overview, Details, and References. The Overview tab offers some informational data about the profile:

  • Profile name
  • File location (full path) and size
  • The time when the file was last modified
  • Whether or not the file is editable
  • Version management
  • Documentation

The Details tab, shown in Figure 3 has tables of applied profiles, imported profiles, and imported model libraries. Rational Software Modeler and Rational Systems Developer also have a table of the profile’s diagrams.

The References tab provides lists of referenced workspace profiles and referencing models and profiles.

Figure 3. Profile Editor, the Details tab
details in four quadrants

Please review the (uml) and the (UMLPrimitiveTypes) entries under the profile in the Project Explorer. The (uml) entry represents the imported UML 2.1 meta-model, which is the one being extended by the profile. The (UMLPrimitiveTypes) entry represents imported UML Primitive Types model library. That is optional; the profile author does not have to import it.

Note: Theoretically, UML profiles could extend various meta-models, although the Rational Software Architect implementation supports only the UML 2.1 meta-model.

The profile's properties (see Figure 4) are displayed in the Properties view when the profile is selected. Version- and Release-related properties are explained later (in the Change management section in Part 2 of this series).

Figure 4. Profile properties
Properties view with five tabs

To add UML elements to the profile, select it in the Project Explorer, right-click it, and click Add UML, as shown in Figure 5. The only UML types that can be created in a profile are Stereotypes, Classes, and Enumerations. Alternatively, if you are using Rational Software Modeler and Rational Systems Developer, you can select Add Diagram > Class Diagram instead of Add UML. That will create a Class Diagram in the profile. Profile elements can be then created using standard diagram tools: diagram palette, modeling assistant, action bar, and pop-up menu.

Figure 5. Add UML menu for profiles
menu command

Naming

The names of certain element types (Stereotype, Class, Enumeration, and Attribute) have to be valid Java™ identifiers. The most common violation of this rule is using the space character in the name. Depending on the exact profile structure, invalid names can cause various problems. The most serious problem is caused by invalid attribute names, which can corrupt the model where the profile is applied. For that reason the tool does not allow invalid names to be entered in the first place.

Imported Profiles

Profiles can import other profiles on the Profile Editor Details tab, in the Imported Profiles section. Importing a profile makes its elements available in the importing profile itself. For example, elements (classes, enumerations, and stereotypes) defined in the other profile can now be used to type stereotype attributes. Also, its stereotypes can be specialized. However, the imported profile is not "re-imported". That is, its stereotypes are not available in the model where only the importing profile is applied.


Stereotypes, attributes, and associations

Stereotypes

To create a stereotype, select the profile in the Project Explorer and right-click it, then select Add UML > Stereotype. This results in the view shown in Figure 6. Alternatively, you can create the stereotype through a diagram in Rational Software Modeler and Rational Systems Developer.

Figure 6. Stereotype properties
Properties view with six tabs

A stereotype can be used simply to mark up the element to which it is applied. However, its real power is in the extension mechanism, through which it can actually modify the metaclass definition of one or more metaclasses. This extension is not automatically propagated to all instances of the metaclass (or metaclasses); the stereotype first has to be applied to the modeling element that is an instance of the particular metaclass. Of course, you can make the extension required, in which case it is automatic (for the model where the profile is applied).

Abstract stereotypes cannot be applied to modeling elements. The abstract stereotype can be specialized by another stereotype (for more information, see the Generalization section in Part 2 of this series).

The Leaf and Visibility fields are mostly ignored. Stereotypes marked as Leaf -- or with Visibility values other than the default (public) -- do not exercise any special behavior, although the stereotypes with the protected or package visibility are reported as errors when the profile is validated. You should not change the default values for these two fields, because it is very likely that some sort of behavior will be associated with them in subsequent releases.

The Icon and Shape Image fields, as well as the Suppressed flag, are covered in the Presentation section, and the Category field is covered in the Stereotype attributes section.

The UI Read Only and Properties UI Read Only fields were added in Rational Software Architect 7.0.0.2. If the stereotype is marked as UI Read Only, then it cannot be applied or unapplied through the tool’s default UI. If it is marked as Properties UI Read Only then all of its attributes are treated as UI Read Only (you can find more details on this in the Stereotype attributes section).

The metaclasses being extended by the stereotype are specified on the Extensions tab in the Properties view. The Metaclass Extensions table lists all existing extensions for the stereotype, as shown in Figure 7.

Figure 7. Metaclass Extensions
Actor metaclass with Required value of False

You can add a new extension by clicking the Add Extension button, which starts the Create Metaclass Extension dialog shown in Figure 8. The metaclasses that are available for extension are those defined by the UML 2.1 meta-model. Each extension can be marked as Required or not (not required is the default). That option can be set only when the extension is created. If it has to be changed, you should first remove the old extension and then create a new one.

Figure 8. Create Metaclass Extension dialog
scrollable list of available metaclasses

Note: There is a way (not recommended) to change the state of the required flag. First, make sure that Extension Ends are not filtered out from Project Explorer (they are by default). You can do that by removing Extension End from the filter list in preferences (select Window > Preferences, then select Modeling > Views > Project Explorer, then select Filters). Next, navigate to the Extension (under the Associations virtual folder under the profile itself) in Project Explorer and expand it: the property below it is the Extension End. Select it and go to the Advanced tab in the Properties view. To make the extension required, set the value of the lower property to 1; to make it non-required, set it to 0.

When an extension is required, it means that the stereotype will be applied automatically to all modeling elements that are instances of that metaclass, given that the profile owning the stereotype is applied to the model. If the extension is not required, then the stereotype has to be applied to the element either through a user gesture or programmatically.

You can also create metaclass extensions through Project Explorer: select the stereotype and select Add UML > Metaclass Extension. In Rational Software Modeler and Rational Systems Developer, it can also be created through a diagram.

An attribute with a name in the base_<metaclass name> format is created in the stereotype for each metaclass that the stereotype extends. Those attributes are used by the system and should not be modified.

Please note that the stereotype can be applied only to the elements whose metaclass it extends. Of course, the profile (that owns the stereotype) itself has to be applied to the element's package hierarchy (most likely to the model itself) first.

The main aspects in which a stereotype can modify the metaclass definition are:

  • Presentation
  • Additional properties
  • Additional constraints

Each of these is discussed in a separate section.

Presentation

When a stereotype is applied to a modeling element, it can affect its presentation in multiple ways. The most obvious way is that the system now displays (by default) the stereotype name in guillemets in the front of the element's name, where appropriate (for example, in Project Explorer or on diagrams). For example, if a stereotype S is applied to the element E, the system will display <<S>> E in Project Explorer and on diagrams for that element.

Note: The tool does not automatically make the first character of the stereotype name lowercase for display purposes, as suggested by the UML 2.1 specification (see the Resources section). The name is displayed as is. However, you (as the profile author) can fully control the display name -- separately from the name -- using the localization mechanism (for more information, see the Localization section in part 2 of this series).

A stereotype can have an icon and a shape image attached to it: see the General tab in the Properties view for stereotypes. Next to the Icon and Shape Image field on the General tab are two buttons: Browse and Clear. The Browse button lets you find an image file in the file system to be associated with the stereotype. The Clear button removes the specified image from the stereotype. Supported formats for both Icon and Shape Image fields are BMP, GIF, JPG, and PNG. Shape Image additionally supports files in the SVG, EMF, and WMF formats. Of course, neither image has to be specified: it is entirely up to you.

When a stereotype is applied to an element, the system will consult the preference settings to determine how to present the element. To invoke the preferences, click Window > Preferences.

For Project Explorer, the Select Element dialog, and tools in general, click Modeling > Profiles. The Stereotype Style combo box offers the following choices: None, Text,Decoration, Decoration and Text (default).

None
Means that the applied stereotypes are ignored.

Text
Means that all applied stereotypes will be listed in the guillemets in the front of the element’s name.

Decoration
Instructs the tool to use the image from the Icon field of the applied stereotype. Please note that if multiple applied stereotypes have defined icons, only one of them will be used.

DecorationandText
Combines the two options.

Diagrams settings can be found in two places: by clicking Modeling > Diagrams > Appearance > Connectors for connectors and Modeling > Diagrams > Appearance > Shapes for shapes. The Stereotype style combo-box for connectors has only two options: None and Text. The shapes provide more choices: None, Text, Decoration, Decoration and Text, and Shape Image. The Shape Image option replaces the whole shape with the image specified in the stereotype. You can adjust these preferences on diagrams through pop-up menus for each individual element (shape or connector): select Filters > Stereotype and Visibility Style.

Another interesting presentation feature for stereotypes is the Suppressed option (found on the General tab in the Properties view). When selected, it turns off the presentation capabilities of the stereotype: even if the stereotype is applied to an element, neither the Project Explorer nor diagrams display any information about it. This is most useful when the intent is to use the stereotypes programmatically, to hold information or mark up elements but not to change the element’s presentation.

You can still see the suppressed stereotypes as applied in the Properties view’s Stereotypes tab for the element, unless even that is turned off through the preference settings (Window > Preferences > Modeling > Views > Properties View settings > Show suppressed properties). The suppressed stereotypes can be applied only programmatically (they do not show up on the list of the applicable stereotypes), but they can be removed manually.

There is an exception to this rule: suppressed stereotypes with the taggedValueSet keyword can be applied manually as well. This keyword can be set by selecting the stereotype in the Project Explorer, then going to the Stereotypes tab in the Properties view and entering the keyword in the keywords list.

Stereotype attributes

Stereotype owned attributes are added to the metaclass definition as its properties, for the element instance where the stereotype is applied. For example, suppose that there is a stereotype S, which extends the metaclass Actor and has an attribute named attr1. When this stereotype is applied to an actor in a model, the actor's set of properties will now include attr1 (in addition to all of the properties specified in the Actor metaclass, such as name, visibility, and so on).

To create a stereotype attribute, select the stereotype in Project Explorer, right-click it, and select Add UML > Attribute, as shown in Figure 9.

Figure 9. Attribute properties
Properties view with four tabs

The most important properties for an attribute (in addition to the Name) are Type, Default Value, Multiplicity, Aggregation, and Unique.

Because the stereotype-owned attributes eventually become extended metaclass properties, their type cannot be just anything: it has to be a type recognized by the system, for which it can provide proper handling of these properties. Supported types are:

  • Primitive types from the imported model libraries
  • Enumerations defined in the profile itself, or in an imported profile
  • Classes defined in the profile itself, or in an imported profile
  • Metaclasses defined in the UML 2.1 metamodel (through metaclass association)
  • Stereotypes defined in the profile itself (through stereotype association): this is available only in V7.0.0.2 and later

Attributes must have a type. If it is not specified, the tool will report a missing type when the profile is saved (or validated), and will not create a profile version for the profile until the error is fixed.

The default value does not have to be specified. If it is not, the tool will use its own default depending on the type. For example, the default for a String typed attribute is blank string.

The multiplicity indicates if the property will be treated as a singular value or a collection (multiplicity greater than 1). When the multiplicity indicates a collection, you should also pay attention to the Unique field to indicate if the elements in the collection have to be unique or not. By default, this option is set to require uniqueness. Properties of class type (including metaclass and stereotype associations) should have this option selected.

The Aggregation property is important for complex types: it has to be set to Composition for attributes of a class type and Shared for attributes of metaclass or stereotype.

The stereotype-contributed properties are displayed in the Properties view for the element to which the stereotype is applied, together with other properties. They can be found in two places: the Advanced tab and the Stereotypes tab (the Stereotype Properties table). In either case they are grouped together under the category named the same as the stereotype contributing the properties. You can override that rule: there is the Category field on the stereotype's General tab. If that value is specified, then it will be used to group that stereotype's properties together instead of the stereotype name. An example when this is useful is when all stereotypes coming from the same profile need to group properties together under the same category.

Another interesting property for stereotype attribute is UI Read Only. If this option is selected, then the value of the attribute cannot be modified through the tool’s default UI in the element were the stereotype is applied.

Model libraries

Profiles support only 3 predefined model libraries:

  • UML Primitive Types
  • Java Primitive Types
  • Ecore Primitive Types

In order to use the types defined in one of those libraries, you first have to import the library into the profile. The libraries can be imported when the profile is created through the New Profile wizard (by default, it sets UML2 Types to be imported, but you can change that).

You can also import them at any other point: simply select the profile in Project Explorer, right-click it, and then click Import Model Library. In addition, you can import them through the Profile Editor: use the Add button next to the Model Libraries table on the Details tab.

The UML Primitive Types model library contains the 4 primitive types defined by the UML 2.1 specification, as shown in Figure 10, (again, see the Resources section for more information on UML 2.1):

  • Boolean
  • String
  • Integer
  • Unlimited Natural

The Java Types model library defines primitive types corresponding to the Java language primitive types, and the Ecore Types model library defines primitive types corresponding to the Eclipse's EMF types.

UML and Java types are fully supported. The Ecore types are partially supported: they can all be specified, and Rational Software Architect will provide read capability for all of them. However, it supports editing capability only for the types that have a direct Java type representation. For example, the tool provides editing capability for attributes whose type is EByte, but only the read capability for those whose type is ETreeIterator. It is envisioned that such types (like ETreeIterator) will be used only in conjunction with some sort of programmatic manipulation of the profile at the runtime.

Figure 10. Selecting attribute type
UML Primitive Types in a tree view

Enumerations

Enumerations can be used to specify the type of stereotype attributes only if they are defined in the same profile as the stereotype itself, or in an imported profile. The values for attributes whose type is an enumeration would be enumeration literals owned by that enumeration.

The profile-owned enumerations are not generally available outside of the profile itself.

Classes

Classes can be used to specify the type of stereotype attributes only if they are defined in the same profile as the stereotype itself, or in an imported profile. Any such class can (and should) have attributes of its own. The rules for those attributes (in terms of supported types and default values) are the same as for the stereotype attributes.

The limitation is that the aggregation of such properties has to be set to Composite; otherwise, an error will be generated when the profile is saved (or validated), and the tool will not generate a profile version until the error is fixed.

The default value of an attribute typed as a class is null or empty collection (when the multiplicity is greater than 1).

The profile-owned classes are not generally available outside of the profile itself.

Metaclass associations

A UML 2.1 defined metaclass can be used to specify the type of stereotype attributes by creating a metaclass association between the stereotype and the desired metaclass. You can do this through either Project Explorer (right-click the stereotype and select Add UML > Metaclass Association) or in a diagram (only in Rational Software Modeler and Rational Systems Developer; to do so, connect Stereotype shape and Metaclass shape with an Aggregation Association). The values of such attributes would be actual instance(s) of the metaclass.

The limitation is that the aggregation of such properties has to be set to Shared; otherwise, an error will be generated when the profile is saved (or validated) and the tool will not generate a profile version until the error is fixed.

The default value of an attribute typed as a metaclass reference is null or empty collection (when the multiplicity is greater than 1).

Stereotype associations

Other stereotypes can be used to specify the type of stereotype attributes by creating a directed stereotype association between the two stereotypes. you can do this through either Project Explorer (right-click the stereotype and select Add UML > Stereotype Association) or in a diagram (only in Rational Software Modeler and Rational Systems Developer; to do so, connect the two Stereotype shapes with Aggregation Association). The values of such attributes would be actual instance(s) of the other stereotype, that is, stereotype applications. However, that is represented in the UI as elements to which those stereotypes are applied (the elements referenced by the stereotype applications). This type is supported in V7.0.0.2 and later.

The limitation is that the aggregation of such properties has to be set to Shared; otherwise, an error will be generated when the profile is saved (or validated), and the tool will not generate a profile version until the error is fixed. Other big limitations include:

  • Both stereotypes must reside in the same profile (imported profiles are not supported in this case).
  • The attribute values (stereotype application; elements to which the stereotypes are applied) must reside in the same model as the element to which the referencing stereotype is applied.

The default value of an attribute typed as a stereotype reference is null or empty collection (when the multiplicity is greater than 1).


Generalization

A stereotype can specialize or generalize only another stereotype: a class cannot participate in the generalization relationship with the stereotype.

To specify a generalization relationship between the two stereotypes, right-click the stereotype that you wish to be the specialization in the Project Explorer and chose UML Properties.

This launches the Properties dialog. Select the Generalization collection and, in the top right corner, select the insert tool (the Generalization icon), as shown in Figure 11. Select the other stereotype and click OK.

Figure 11. Generalization collection
Generalization selected in list on left

You can accomplish this visually (using diagrams) in Rational Software Modeler and Rational Systems Developer.

Figure 12. Create Generalization through diagrams
Explore and Create tabs

Profile constraints

In a profile, only stereotypes can own constraints. To create a constraint, select the stereotype in the Project Explorer, right-click it, and click Add UML > Constraint. You can name the constraint, but you do not have to. It is a good idea to provide a name, though, because the name can be used in reporting the constraint failure by the tool.

It extends the meta-model to constrain the model where the stereotype is applied. The system automatically extends the meta-model if the specified language is supported. If the language is not supported, the constraint is ignored by the tool.

The constraint is defined in the profile but evaluated in the model, where the stereotype (that owns it) is applied.

The properties on the General tab (in the Properties view) are Name, Language, and Value, as shown in Figure 13. The two system-supported languages are OCL (Object Constraint Language) and Java. The content of the Value field depends on the specified language.

The Java-based constraints should yield better performance, might be easier to use to express complex constraints, and offer greater flexibility. On the other hand, the Java-based constraints work only with the plug-in deployed profiles (for more information, see the Deployment section in Part 2 of this series) and are more time-consuming for initial tests performed by profile author. Another advantage of OCL-based constraints is that they are more consistent with how OMG defines UML constraints (please see the Resources section for more information).

Figure 13. General constraint properties
Properties view with six tabs

There are also important properties on the Validation tab (in the Properties view shown in Figure 14): Evaluation Mode, Message Key, and Severity.

The Evaluation Mode value could be either Batch (evaluated only on demand when you invoke the validation action) or Live (evaluated both when the change occurs and on demand). The default is Batch. Note: in Rational Software Modeler and Rational Systems Developer, special rules apply for batch constraints. If the errors are discovered during validation, then batch constraints will start behaving very similar to live constraints.

The Message Key is used for display purposes when the constraint fails. If it is not specified, the system uses the fully qualified constraint name. If it is specified, the system looks it up in the corresponding properties file if there is one (for more information, see the Localization section in Part 2 of this series). If no properties file is found, the key itself is used. A single quote in the message must be escaped with another single quote.

The Severity could be Error, Warning, and Informational. The exact behavior for each of those values depends on your preference settings. However, if a Live constraint with the Error severity is violated, the change is automatically rolled back.

Figure 14. Validation tab in constraint properties
Validation tab options

Built-in OCL support

Note: This article does not attempt to clarify or explain OCL. To understand the information in this section, you should be familiar with the OCL specification (see the Resources section for more information).

The supported version of the OCL is 2.0, matching the supported UML definition (2.1).

The OCL statement is entered in the Value field of the constraint's General tab in the Properties view.

The union of the user-modeled stereotype and the intersection of its meta-model extensions is used as the OCL context when the constraint is defined.

For example:

  • Stereotype S1 has two attributes (a1: Integer, and a2 : Boolean), extends Class and Actor metaclasses, and has constraint profileCons1.
  • OCL statement in the profileCons1 constraint would have access to properties a1 and a2 and the intersection of features defined in metaclasses Class and Actor.
  • The intersection of features defined in all extended metaclasses is used instead of the union to ensure that the constraint is syntactically valid, regardless of the element where the stereotype will be applied. The tool does not allow Class-specific features to be used in the constraint, because the constraint would not be syntactically valid when the stereotype is applied to an Actor, and the other way around.

Note: there is workaround to access the non-shared features. You could do so through the base_Xyz attribute (you should check first if it has value). In the above example, the following statement would access Actor specific features: base_Actor <> null implies base_Actor.someFeatureXyz.

The element with the constraint's stereotype applied to it is used as the OCL context during the evaluation of the constraint.

For example:

  • Actor A1 has stereotype S1 applied to it.
  • The constraint profileCons1 is evaluated depending on the evaluation mode settings. At that time, actor A1 is used as the OCL context in the meta-model mode.

The UI provides syntax highlighting, content assist, and syntax parsing.

The constraint is evaluated during model validation in the model where the stereotype is applied. It is checked only for syntactical validity when the profile itself is validated.

If the constraint has a message associated with it (through the Message Id), the {0} variable in the message is substituted by the context element -- unless it is between single quotes.

Built-in Java support

The user can specify the Java class in the Body field of the constraint's General tab in the Properties view.

The Java class has to be specified using its fully qualified name. It has to extend the org.eclipse.emf.validation.AbstractModelConstraint class. Both the profile and the Java class have to be deployed through the same plug-in (for more information, see the Deployment section in Part 2 of this series).

The element with the constraint's stereotype applied to it is used as the constraint context during evaluation of the constraint.

The constraint is evaluated during model validation in the model where the stereotype is applied. It is not checked when the profile itself is validated.

If the constraint has a message associated with it (through the Message Id), it can be obtained from the org.eclipse.emf.validation.IValidationContext object that is passed to the constraint by the system. The constraint can then deal with any number of the {n} variables in the message using standard Java message formatting.


Profiles and diagrams

Class diagram

Rational Software Modeler and Rational Systems Developer support class diagrams in profiles. You can use the diagrams to visualize an existing profile’s structure, or build the profile using the diagram in a visual manner instead of building it through the Project Explorer's Properties View combination.

The profiles that contain diagrams are fully compatible with the older versions of the tool (7.0, 7.0.0.1 through 7.0.0.5): the diagrams are simply not visible in those versions.

Figure 15. Class diagram
diagram with Create and Explore tabs

Generate profile tooling

Rational Software Modeler and Rational Systems Developer also support the generation of profile tooling. To invoke the wizard shown in Figure 16, right-click the profile in Project Explorer and select Generate Profile Tooling.

Figure 16. Generate Profile Tooling wizard
general options

The wizard guides you through creating the project, and is capable of generating palette items, menus, and custom shapes based on the profile. The tooling generation is a big topic on its own, and is addressed in separate articles. Please see the Resources section.


Using UML profiles

The intent of this section is to provide a short overview of using UML profiles, so that you can quickly start testing the new profile. More advanced topics are addressed in Part 2 of this series.

Applying profiles

Before you can use the content of a profile (for all practical purposes, that means stereotypes) in a model, the profile itself has to be applied to the model. To be precise, the profile can be applied to any package in the model, including the model itself. When the profile is applied to the model itself, it is visible in the whole model. If it is applied to some package in the model, then it is visible only in that package's sub-tree. It is usually easier to manage if the profile is applied to the model, but it is entirely up to you. A profile can also be applied to other profiles.

To apply a profile, select the model (package) in Project Explorer or on a diagram (if it is present there) and navigate to the Profiles tab in the Properties view, as shown in Figure 17. A similar view is offered in the Model Editor, on the Details tab, in a table of applied profiles.

Figure 17. Profiles tab
Properties view with seven tabs

The Applied Profiles table lists all of the profiles that have already been applied. Do not worry too much about the Version and Release Label columns for now: these concepts are addressed in the Change management section of Part 2 of this series.

To remove a profile, select the profile and click the Remove Profile button.

Note: Not all profiles can be removed. There are certain profiles that are required by the system, and you cannot remove them. One of them is Standard, which is defined by the UML 2.1 specification. The other two (Default and Deployment) are defined by Rational Software Architect.

To apply (add) a new profile, simply click Add Profile, which will launch the Select Profile dialog shown in Figure 18.

Figure 18. Select Profile dialog
Deployed Profile radio button selected

You can choose one of the available (system-known) deployed profiles, browse the workspace, or browse the file system to select a profile. More details on deploying profiles are provided in the Deployment section of Part 2 of this series. For now, the simplest way to start is to select the Workspace option and then browse the workspace to find the profile.

Applying stereotypes

To apply a stereotype, select the modeling element in Project Explorer or on a diagram, and navigate to the Stereotypes tab in the Properties view, as shown in Figure 19.

Figure 19. Stereotypes tab
Properties view with seven tabs

The Applied Stereotypes table lists all of the stereotypes that have already been applied. The Stereotype Properties table lists the element’s properties that are contributed by those stereotypes.

To remove a stereotype, select the stereotype and click the Remove Stereotypes button. If the stereotype is required (as indicated by the Required column) then it cannot be removed. To apply (add) a new stereotype, simply click Add Stereotypes, which will launch the Apply Stereotypes dialog shown in Figure 20.

Figure 20. Apply Stereotypes dialog
perspective check box selected

The list in the dialog contains all applicable stereotypes for that element that are not already applied.


What you have learned so far

This article, one of two in a series, has shown you how to create or import UML profiles using IBM Rational Software Architect, IBM Rational Systems Developer, and IBM Rational Software Modeler. You have learned about built-in support for OCL and Java, as well as how to apply a profile.

Part 2 of this series will address change management, deployment, localization, programmatic support, and best practices.


Acknowledgments

The author wishes to thank Christian Damus, Daniel Leroux, Michael Hanner, and Wayne Diu.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=302711
ArticleTitle=Authoring UML Profiles: Part 1. Using Rational Software Architect, Rational Systems Developer, and Rational Software Modeler to create and deploy UML Profiles
publish-date=04292008