 Example description |
This following basic class diagram is used as an example throughout this tutorial.
It contains two packages: GenericScheduler, which contains a basic scheduler definition, and a « modelLibrary » package SchedulingPolicies, defining a set of actual scheduling policies.
The purpose of the tutorial is to show how to:
- define a template signature for the GenericScheduler package,
- expose the SchedulingPolicy class as a template parameter for the package
- define a new package that binds the former parameter, thus involving a new Scheduler class with a particular semantics.
|
|
|
| Creation of a TemplateSignature for the GenericScheduler package |
First, select the « Template Signature » item from the Palette. Then left-click on the GenericScheduler package.
Note: You may have noticed that the Palette proposes several items related to UML template mechanism. For the template signature definition purpose, the « Redefinable Template Signature » item must be used for Classes and DataTypes (i.e. modeling elements that are redefinable). In other words, if you want to define a template Class or a template DataType, use RedefinableTemplateSignature instead of TemplateSignature.
This action results in the creation of a template signature for the GenericScheduler package, with a white dashed rectangle appearing in the upper right corner of the package (as illustrated in the following figure).
|
|
|
| Creation of a template parameter |
Let us now describe how to create a template parameter. First, select the previously created template signature from the diagram or from the outline (i.e. in the outline, the GenericScheduler packages now contains a « template signature » item). The property view should now display properties related to the template signature. Actually, the only property available for template signatures is the list of defined template parameters. For the moment, this list is empty. To define a new template parameter, press the « + » (i.e. « add » button) in the right hand side of the property view. An item list appears: it basically contains the different kinds of template parameters that can be defined for a template signature (note: the same items are proposed for a redefinable template signature).
As we explained in the introduction of this tutorial, we want to expose the SchedulingPolicy class as a parameter of the package. So, let’s click on the « Create owned Classifier Template Parameter » item (as Class is a kind of Classifier. In other words, if you want to expose a PrimitiveType, a DataType, a Component, etc. or any kind of Classifier, select this item).
The above figure illustrates the resulting model. The list of parameters (in the diagram as well as in the property view) now contains an item, representing a classifier template parameter. The « » string is displayed. Here, the main point to understand is that a template parameter is not a NamedElement (i.e. it has no name, and this aspect of the UML model may be confusing for users). The string that is displayed is basically « computed », according to the properties of the template parameter, and particularly something that is called its « exposed parameter element ». In other words, a template parameter is basically a kind of pointer, referencing something that is the actual parameter. The next steps of these tutorial will clarify this aspect. NOTE: Following the same principle, the « Create owned Operation Template Parameter » enables to expose an Operation as a parameter, and the « Create owned Connectable Element Template Parameter » enables to expose a ConnectableElement as a parameter (typically used to expose a Property). The « Add referenced Template Parameter » item (which is disabled in this example), enables to reference a parameter which is defined elsewhere in the model, typically by a template which is itself contained in another template. For example, if we define a redefinable template signature for the Scheduler class, it will be possible to define in this signature a template parameter which is actually a reference to a template parameter defined in the signature of the GenericScheduler package.
IMPORTANT NOTE: The use of the « Create owned Template Parameter » is not recommended for the moment. A better integration will be available soon. One interesting potential use of these « default » template parameters is the exposition of ValueSpecification parameters. Typically, this feature enables to expose LiteralInteger or LiteralUnlimitedNatural value specifications, so that these parameters can be referenced in the definition of an attribute (e.g. Array, a class with an elements attribute with multiplicity = [0..nb_element]). Please subscribe to the Papyrus mailing list to get informed when this feature is available. |
|
|
| Exposing an element as parameter |
First select the classifier template parameter from the diagram or from the outline. Several properties related to this parameter appear in the property view. Only two of them are enabled: « Owned parametered element » and « Parametered element » (NOTE: we will talk about the other properties in the next step of this tutorial). As we have explained in the previous step, a template parameter is only a kind of pointer on something which is actually exposed as a parameter. To expose this element, we actually have two options, corresponding to the enabled properties.
At the time when the template parameter is being defined, either the element to be exposed already exists or not. If it does not exist yet, then the user may choose to create it directly in the context of the template parameter. In other words, the exposed element will be owned directly by the template parameter. In this case, the « + » button related to the « Owned parametered element » property must be pressed. In this case, a dialog box will appear, proposing a list of element kind (i.e. metaclasses) for the element to be created (NOTE: this list is consistent with the kind of the template parameter, e.g. if the parameter is a « classifier template parameter », then the dialog box will only propose metaclasses that are compatible with the Classifier metaclass). In our case, the element to be exposed already exists. So let’s click on the « + » button related to the « Parametered element » property. As illustrated in the figure, a dialog box proposing the elements that can be exposed as a parameter (i.e. elements that are owned by the template, and that are compatible with the template parameter i.e. in this case only classifiers). Select the SchedulingPolicy class, and press the OK button.
As illustrated above, the « » string (previously representing the template parameter) has been updated, and actually computed according to the properties of the template parameter. In this case, the parameteredElement property of the template parameter has been taken into account to produce the new display. |
|
|
| Defining a constraining classifier for a classifier template parameter |
The SchedulingPolicy class is now exposed as a parameter of the template GenericScheduler package. This point actually means that any class, whithout any restriction, can be used in a binding based on the GenericScheduler package. In our case, we would like to impose that the classes that will used in a binding should respect some properties: Tipically, we would like to impose that the class used in the binding implements some particular operations, so that a behavior associated with the Scheduler class can be expressed in a generic way. This kind of properties can be ensured using the « constraining classifier » property of a classifier template parameter (NOTE: this property is of course not available for other kinds of template parameters). To define a constraining classifier for our parameter, press the « + » button related to the « constraing classifier » property. A dialog box proposing all the available model elements that can be used as constraining classifiers are proposed: select the AbstractPolicy class, and press OK.
The resulting model is illustrated in the picture below. In the diagram, the parameter is now represented with the string: « SchedulingPolicy : Class > AbstractPolicy », where « > AbstractPolicy » represents the constraining classifier for this classifier template parameter. From now on, valid bindings for the GenericScheduler package will be those that will be expressed using classes compatible with the AbstractPolicy class as actual values.
NOTE: the « Owned default » and « Default » property sections are used to specify default values for the parameter in the case where no bindings are specified. The « owned » qualifier follows a principle similar to the « Owned » qualifier of the parametered element property (described in the previous step of this tutorial). |
|
|
| Creation of a Template binding relationship |
We now have a generic package (GenericScheduler), exposing a class (SchedulingPolicy) as a parameter, where this class is contrained by the AbstractPolicy. Let us now illustrate how to create a particular package, which binds the parameter exposed by the GenericScheduler package.
First, create a package called « EDF_Scheduler », as illustrated in the figure. Then, from the Dependency group of the palette, select the « Template Binding » item, and draw a relationship between the EDF_Scheduler package and the GenericScheduler package.
As illustrated above, a dashed arrow with the stereotype « bind » as been created. |
|
|
| Creation of the parameter substitution |
Now that the template binding relationship has been created, the way how the parameters exposed by the template are substituted with (or bound to) actual values must be specify. This is done through to the definition of « TemplateParameterSubstitutions », that will be owned by the template binding relationship. First select the template binding relationship from the diagram or from the outline (the relationship is owned by the EDF_Scheduler package). In the property view section, press the « + » button to define a new parameter substitution. An item list appears: this list contains one item for each formal parameter of the template (the item appears only if the corresponding parameter has not already been bound). Here, the list only contains one element (as we have only defined one formal parameter for the GenericScheduler template package): press this item to create a parameter substitution related to this parameter.
As illustrated below, the list of parameter substitutions of the template binding relationship now contains an item for the parameter exposing the SchedulingPolicy. In the « SchedulingPolicy -> » string displayed, « SchedulingPolicy » represents the formal parameter, and « » represents the actual substitution value.
The next (and last) section of this tutorial describes how to specifiy this actual value. |
|
|
| Definition of an actual value for a given parameter substitution |
First select the parameter substitution from the outline (or double click on the parameter substitution item of the property view related to the template binding relationship). Two properties related to the parameter substitution appear in the property view section: « Owned actual » and « Actual ». Both enable to specify an actual value used to bind a given formal parameter (Note: The « Owned » qualifier has a similar meaning as for « parameteredElement » or « default » properties we have discribed in previous steps). For the needs of our example, press the « + » button related to the « Actual » property section. A dialog box proposing all the elements that can be used as an actual value for this parameter substitution appear: in our case, all the elements proposed are classes that are compatible with the AbstractPolicy class. Select the EDF class, and press the OK button.
As illustrated below, the parameter exposing the SchedulingPolicy class has been bound to the EDF class.
|
|
|
| Author |
Arnaud Cuccuru (CEA LIST)
Date: 2007/07/26 |
|
|
|
Templates
