An OCL Formulation of UML2 Template Binding - Semantic Scholar

An OCL Formulation of UML2 Template Binding Olivier Caron, Bernard Carr´e, Alexis Muller and Gilles Vanwormhoudt Laboratoire d’Informatique Fondamentale de Lille UMR CNRS 8022 Universit´e des Sciences et Technologies de Lille F-59655 Villeneuve d’Ascq cedex, France

Abstract. After being considered only as documentation for a long time, models are gaining more and more importance in the software development lifecycle, as full software artefacts. The UML standard contributes a lot to this mutation, with the identification and the structuration of models space dimensions and constructs. Models can nowadays be explicitly manipulated through metamodeling techniques, dedicated tools or processes such as model transformation chains. This is ”Model Driven Engineering”. Once it is clear that models are full software ingredients, we are faced with new problems (needs!) such as the possibility of their reusability and composability. As a consequence, specific constructs are introduced in order to facilitate this, such as the template notion initiated by UML1.3. Applications of this notion are growing more and more so that it was deeply revisited and strengthened in UML2. Though, its specification still lacks precision, particularly concerning the ”binding” mechanism that allows to obtain models from templates. We propose a set of OCL constraints which strengthens the definition and helps in verifying the correctness of resulting models. These constraints apply to the UML2 metamodel and were implemented in an OCL verifier that we integrated in the Eclipse environment.

1

Introduction

After being considered only as documentation elements for a long time, models are gaining more and more importance in the software development lifecycle, as full software artefacts. The UML [2] standard contributes a lot to this mutation, with the identification and the structuration of models space dimensions and constructs. Models can nowadays be explicitly manipulated through metamodeling techniques, dedicated tools or processes such as the MDA [1] transformation chains. This is ”Model Driven Engineering” [9]. The main motivation is the reduction of delays and costs by the capitalization of design efforts (models) at each stage, and the automation, as far as possible, of transitions between these stages. So it would be possible to separate high level business oriented models from low level architectural and technological ones, but also to reuse these models from one application to another.

Indeed, once it is clear that models are full software ingredients, we are faced with new problems (needs!) such as the possibility of their reusability and composability. As a consequence, models stand more and more as good candidates for the ”design for reuse” quest and specific constructs are introduced to make them generic. It is the case of the UML template notion which helps in specifying parameterized models. Applications are patterns formulation [3] [4], modelization of reusable subjects in [5] or frameworks in Catalysis [6]. We also use templates to specify modeling components which capture reusable functional aspects [10]. UML templates applications are numerous and various, with the result that its initial introduction in UML1.3 was deeply revisited and strengthened in the UML2 standard. Though its specification remains much more structural and verbal in [3]. Particularly, constraints lack for the precise definition of the related ”binding” relation which allows to obtain models from templates. These constraints are needed to verify the correctness of the resulting models. That is why we propose here a set of OCL constraints [11] which could strengthen the notion of model templates and facilitate the above verification. These constraints apply to the UML2 metamodel. In the following section, we show the notion of templates through examples of parameterized model elements. Then (section 3), we present the UML metamodels of templates and the template binding as they are specified in [3] and explain them with the help of the preceding examples. We so (section 4) propose a set of OCL constraints which could complete this specification and help in verifying the correctness of resulting models. These constraints were checked in an OCL verifier that we integrate in the Eclipse environment (section 5).

2

The UML 2 Template Notion

In UML standard, a template is a model element which is parameterized by other model elements. Such parameterizable elements can be classes or packages, so called respectively class templates or package templates. To specify its parameterization, a template element owns a signature. A template signature corresponds to a list of formal parameters where each parameter designates an element that is part of the template. Template elements have also a specific notation which consists in superimposing a small dashed rectangle containing the signature on the right-hand corner of the standard symbol. A template can be used to generate other model elements using template binding relationship. A bind relationship links a ”bound” element to the signature of a target template and specifies a set of template parameter substitutions that associate actual elements to formal parameters. The binding of a bound element implies that its contents are based upon the contents of the target template with any element exposed as formal parameter substituted by the actual element specified in the binding. Figure 1 shows a class template on the left. This class, Stack, is graphically represented as a standard UML class with a dashed rectangle containing its sig-

Stack capacity : int := Max contents : Element[*] void put(Element d) Element get()

Element : Class, Max : int

Plate, Max -> 15>

PlatesStack capacity : int := 15 contents : Plate[*] void put(Plate d) Plate get()

Fig. 1. Class Template

nature. Here, the signature states two elements as formal parameters: Element of type class and Max of type int. The right side of this figure shows the class PlatesStack which is bound to the Stack template through a ”bind” relationship. This class is the result of the substitution in the template of its formal parameters, Element and Max by the actual values Plate and 15 respectively. This substitution is stated by the bind relationship. Figure 2 is another example of a template which shows that they can also apply to packages. Here, the notion of template is used to model the well-known observer pattern. The content of this template reflects the structure of this pattern and includes the classical Subject and Observer classes. As indicated by the signature attached to the template, these classes and their respective value and value view attributes are identified as formal parameters. Figure 2 illustrates the use of the previous template for specifying a HeatFlowRegulation package that models a part of a home heating system. This package has its own content which is composed of RoomSensor, HeatFlowRegulator and Furnace classes. In this example, the bind relationship is used to render the collaboration between RoomSensor and HeatFlowRegulator. This is specified by associating RoomSensor to Subject, HeatFlowRegulator to Observer and their respective value and value view attributes to currentTemperature and measuredTemperature. As a result of this binding, RoomSensor and HeatFlowRegulator have respectively the same elements (operations and association) than Subject and Observer. Note that actual classes may have contents in addition to those specified for the formal parameters.

3

The UML 2 Template Metamodel

The templates package in the UML 2 metamodel [3] introduces four classes : TemplateSignature, TemplateableElement, TemplateParameter and ParameterableElement (see Figure 3). TemplateBinding and TemplateParameterSubstitution metaclasses are both used to bind templates (see Figure 4). UML 2 elements that are sub-classes of the abstract class TemplateableElement can be parameterized. Classifier, in particular classes and associations, Package and Operation are templateable elements. The set of template parameters (TemplateParameter ) of a template (TemplateableElement) are included in a signature TemplateSignature. A TemplateSignature correspond to a small dashed rectangle superimposed on the symbol for

Subject, Observer : Class, value, value_view : Property T

ObserverPattern

Subject value : T

subject

observers

Observer value_view : T

0..* void update (val : T)

0..1 void register (Observer o)

< Subject -> RoomSensor, Observer -> HeatFlowRegulator, value -> currentTemperature, value_view -> measuredTemperature T -> float > HomeHeatingSystem

RoomSensor currentTemperature : float

subject

observers 0..*

0..1 void register (HeatFlowRegulator o) void heat ()

HeatFlowRegulator measuredTemperature : float desiredTemperature : float void update (val : float) setTemperature (val : float)

Furnace

void heatOn () void heatOff ()

Fig. 2. Package Template

the templateable element. A TemplateParameter corresponds to a formal template parameter and exposes an element owned by the template thanks to the parameteredElement role. Only parameterable elements (ParameterableElement) can be exposed as formal template parameter for a template or specified as actual parameters in a template binding. Such UML 2 elements are : Classifier, PackageableElement, Operation or Property 1 . The notion of template binding (TemplateBinding) describes the use of a template for a given system (cf. Figure 4). A template binding is a directed relationship labeled by the > stereotype from the bound element to the template (boundElement). The template binding owns a set of template parameter substitutions (TemplateParameterSubstitution). A parameter substitution associates an actual parameter of the bound element to a formal template parameter of the template signature. Figure 5 shows an extract of the instantiation of this metamodel for the example described in Figure 2. It depicts the substitution between the Subject 1

The Property class that is introduced in UML 2 mainly substitutes the UML 1.4 Attribute class.

Fig. 3. Template Metamodel

formal template parameter and the actual RoomSensor parameter of the bound HomeHeatingSystem. UML 2 introduces the notion of partial binding when not all formal template parameters are bound. In that case, the unbound formal template parameters are formal template parameters of the bound element. In case of multiple bindings, each binding is evaluated to produce intermediate results which are then merged to produce the final result.

4

Constraints

The UML 2 specification defines the binding relation as a copy of all template elements into the boundElement modulo parameters substitution. ”The presence of a TemplateBinding relationship implies the same semantics as if the contents of the template owning the target template signature were copied into the bound element, substituting any elements exposed as formal template parameters by the corresponding elements specified as actual parameters in this binding.” [3]. We propose here to formalize this definition with a set of constraints expressed in the OCL language. Note that the standard constraints only check

Fig. 4. Template Binding Metamodel

that the type of each actual parameter is compatible with the type of the related formal template parameter.

4.1

Overall Structure of the Binding

The above definition requires that the structure formed by the template elements is well preserved in the boundElement. To verify this property we define one constraint and two operations. These operations allow to check the matching of complex elements thanks to a recursive and polymorphic call. Indeed they must be enriched to check specific properties to operations and associations. It will be done in the next subsection. Before checking if the bound element is well formed according to a particular binding, it is necessary to check that elements used as parameters are also elements of the bound element. This is done by the first constraint. The standard allOwnedElement query gives both direct and indirect owned elements. [1] The elements used as current parameters of a substitution must belong to boundElement. 1 context TemplateBinding inv :

: TemplateableSignature

ownedTemplateSignature

Observation : TemplateableElement

template signature ownedElement Subject : ParameterableElement templateParameter parameteredElement parameter Subject : TemplateParameter formal

templateBinding : TemplateBinding

parameterSubstitution

: TemplateParameterSubstitution

actual

boundElement HomeHeatingSystem : TemplateableElement

ownedElement

RoomSensor : ParameterableElement

Fig. 5. Extract of the Object Diagram for the HomeHeatingSystem Package

3

self.parameterSubstitution.actual->forAll (p | self.boundElement.allOwnedElement()->includes (p))

The following constraint checks that each element of the template, parameter or not, has a matching element in the boundElement. This matching uses an isBound metaoperation defined on the Element metaclass (see constraint 4). In case of multiple substitutions, it is necessary to check that each actual parameter match the formal parameter (see constraint 3). [2] For any element of the template, a matching element in the boundElement must exist. 1 context TemplateBinding inv : self.signature.template.ownedElement->forAll (template_element | 3 self.boundElement.ownedElement->exists (b | b.isBound (template_element, self))) [3] Each actual parameter of a TemplateParameterSubstitution must match the formal parameter. 1 2

context TemplateParameterSubstitution inv : self.actual->forAll (a | a.isBound (self.formal, self.templateBinding)

The following isBound metaoperation checks if an element of the boundElement matches a template element te according to a given binding. For the matching, we must handle two cases : whether the element is the result of a substitution of the binding (lines 4-5) or a simple copy (lines 6-9). In case of a partial binding,

the constraint 2 verifies for free that copies of unsubstituted parameters exist into the bound element. In order to treat complex elements (classes, packages. . . ), this checking is done recursively on their content. It is the role of the bindOwnedElement metaoperation (line 10)2 . [4] An element is related to another element by a binding relationship if they have the same name and the same type or if there is a substitution between these two elements in the binding relationship, and if it checks the bindOwnedElement operation. 1 context Element def : isBound (te : Element, 3 binding : TemplateBinding) : Boolean = binding.parameterSubstitution 5 ->exists (p | p.formal = te and p.actual->includes (self)) or (self.oclIsKindOf (NamedElement) implies 7 self.oclAsType (NamedElement).name = te.oclAsType (NamedElement).name 9 and self.oclIsTypeOf (te.oclType)) and self.bindOwnedElement (te, binding) [5] An element e binds an element te if there exists, for each element te_owned contained in te , an element contained in e which matches te_owned. 1 context Element def : bindOwnedElement (te : Element, 3 binding : TemplateBinding) : Boolean = te.ownedElement->forAll (te_owned | 5 self.ownedElement->exists (self_owned | self_owned.isBound (te_owned, binding)))

In Figure 6, att1 is an attribute of ClassA in the template and there is no attribute matching in the X class of the boundElement. This kind of error is checked by the previous constraints. 4.2

Specialized Constraints

In order to deal with specificities of Operation, Property and Association the isBound operation is specialized3 . Concerning operations, it is necessary to check, for each operation of the boundElement related to an operation of the template, if their signatures are compatible : types of the operations arguments must be identical or the result of a binding substitution. 2

3

The used recursion is analogous to the allOwnedElements operation specified on UML 2.0. Each specialization always starts with a call to the basic checking (expressed by self.oclAsType (Element).isBound (te, binding)) and then adds specific complements

TemplateP

BoundP

< ClassA, ClassB : Class >

ClassA att1

X < ClassA -> X, ClassB -> Y >

ClassB

Y

att1

Fig. 6. Containment Error

The constraint 6 checks this property and prohibits errors like the ones illustrated Figure 7, where the parameter t of the foo operation of ClassA in the boundElement is typed Z instead of Y. Indeed, the type of t in the template (X ) is substituted by Y in the boundElement.

BoundP

TemplateP

< X : Class> ClassA

ClassA

foo (t : Z) : bool foo (t : X) : bool < X -> Y > X

Y

Z

Fig. 7. Operation Signature Error

[6] An operation of the bound element match an operation of the template if their signatures match according to the isBound operation. 1 context Operation::isBound (te : Element, binding : TemplateBinding) : Boolean 3 body : self.oclAsType (Element).isBound (te, binding) and

5 7 9 11 13 15

self.formalParameter->size() = te.oclAsType (Operation).formalParameter->size () and Sequence {1..self.formalParameter->size ()}->forAll (i : Integer | self.formalParameter->at (i).type.isBound (te.oclAsType (Operation).formalParameter->at (i).type, binding) and self.returnResult->size() = te.oclAsType (Operation).returnResult->size () and Sequence {1..self.returnResult->size ()}->forAll (i : Integer | self.returnResult->at (i).type.isBound (te.oclAsType (Operation).returnResult->at (i), binding))

Lines 5 to 10 check for compatibility of arguments. Lines 11 to 15 do the same for results types.

TemplateP

BoundP

ClassA

ClassA

asso ClassB

ClassC

ClassB

ClassC asso

Fig. 8. Association Error

The following stands for property specificities. First of all it is necessary to check if a Property of boundElement and his matching Property in the template are compatible (line 5). Secondly a property may play a role in an association modeling (figure 9). Indeed in UML2, unlike UML 1.X, there is no more AssociationEnd metaclass. The latter is replaced by a Property playing the role of ownedAttribute for a class and is connected to an association. This is why this constraint is defined on the Property metaclass to check the respect of connections between classes and associations. If a Property is related to an association in the template (line 6), it checks that the connected Property in the boundElement is related to the matching association (lines 7-8). [7] If a property of the template is end of an association A then the dependent property must be end of association related to A. 1 context Property::isBound (te : Element,

Class

Property

Association

+class +ownedAttribute 0..1

* {subsets ownedMemenber}

+memberEnd 2..*

0..1

+association

Fig. 9. Class-Property-Association Metamodel

binding : TemplateBinding) : Boolean 3 body : self.oclAsType (Element).isBound (te, binding) and 5 self.type.isBound (te.oclAsType (Property).type, binding) and te.oclAsType (Property).association->notEmpty () implies 7 self.association.isBound (te.oclAsType (Property).association, binding)

This constraint prevents the kind of errors presented Figure 8, where asso ”is moved” from an association between ClassA and ClassB to an association between ClassB and ClassC. This constraint also works for associations identified as template parameters thanks to the isBound call (line 7). The error illustrated Figure 10 is thus also detected.

TemplateP

< ClassA, ClassB : Class, asso : Association>

ClassA

BoundP

X < ClassA -> X, ClassB -> Y, asso -> link >

asso ClassB

ClassC

Y

ClassC link

Fig. 10. Parameterized Association Error

Lastly, in order for an association of the boundElement to match an association of the template, it must have the same arity, which prohibits for example constructions like that of the Figure 11. This property is checked using the constraint 8. [8] The arity of an association must be the same as that of the matching association of the template. 1 context Association::isBound (te : Element,

TemplateP

BoundP

ClassA

ClassA

ClassC

asso

asso

ClassB

ClassB

Fig. 11. Association Arity Error

binding : TemplateBinding) : Boolean 3 body : self.oclAsType (Element).isBound (te, binding) and 5 self.memberEnd->size () = te.oclAsType (Association).memberEnd->size ()

5

Integration to Case Tools

To validate our set of constraints, we have extended the Eclipse modeling Framework plug-in of the Eclipse environment and coupled this framework with the Dresden OCL Toolkit [8]. EMF [7] (based on Essential MOF) is a Java modeling framework that includes a metamodel for describing models and provides tools and runtime support to produce a set of Java classes for these models and a basic editor. For instance, EMF facilities have been used by its designers to represent the UML2 metamodel and generate an UML2 plug-in 4 that supports representation and editing of UML2 models. Our integration of EMF and OCL Toolkit gives the ability to annotate any EMF models with OCL constraints and verify the expression of these constraints. Figure 12 shows the annotation of the UML2 metamodel described as an EMF model. By selecting an element, the user can easily associate OCL constraints. Here, the selected element is the TemplateBinding class. As it is expanded, we can see that this element owns two of the OCL constraints defined in the previous section. The attachment of constraints to model elements was made possible by extending the EMF metamodel with the introduction of a EConstraint metaclass (similarly to the MOF metamodel). 4

see UML2 project at http://www.eclipse.org

Fig. 12. Annotation of the UML2 metamodel with OCL constraints

Constraints attached to elements of EMF models are checked for syntactical and semantic correctness (i.e type checking and consistency rule). This checking is done by the verifier module of the OCL Toolkit. To implement the checking, we have developed a bridge that provides linkage between OCL expressions and the EMF model over which the expression should be evaluated. All types defined in the EMF model are legal types in an OCL expression belonging to the model. This bridge provides type information from the EMF model to the OCL verifier and ensures the proper handling of navigation and operation call in OCL expression. Each time the verifier needs to check an expression, it can acquire the necessary information from the model by interacting with the bridge. In our current implementation, we extend some implementation classes of the EMF metamodel (Package, Class, Operation, ...) so that they fulfill the bridge functionality. By using this checking facility, we are able to test and validate the expression of our constraints. We do so by annotating the UML2 metamodel that serves to generate the UML2 plug-in.

6

Conclusion

In this paper, we have studied the notion of model template and the associated binding mechanism. We pointed out that the current specification of this notion

remains much more structural and verbal [3]. The set of constraints presented in this paper gives a more precise formulation of template binding and clarify its semantics. Another interest of these constraints is that the correctness of models using templates can be checked. Moreover, template checking can be integrated into modeling case tools. By integrating an OCL verifier into the Eclipse environment, we can now specify any (meta)model with OCL constraints. This functionality was used to verify the correctness of our constraints in relation to the UML 2 metamodel described with this plug-in. In the context of this work, we formulate OCL constraints for the current core of the template specification. These constraints could be completed to treat other parts of the specification such as template inheritance or diagrams other than structural ones.

References 1. OMG Model-Driven Architecture Home Page, http://www.omg.org/mda. 2. U.M.L. Home Page, http://www.omg.org/technology/uml, 2001. 3. Auxiliary Constructs Templates, http://www.omg.org/docs/ptc/03-08-02.pdf, pages 541-568. UML 2.0 Superstructure Specification, 2003. 4. Biju K. Appukuttan, Tony Clark, Andy Evans, Girish Maskeri, Paul Sammut, Laurence Tratt, and James S. Willans. A pattern based approach to defining the dynamic infrastructure of UML 2.0. Technical report, March 2002. 5. S. Clarke. Extending standard uml with model composition semantics. In Science of Computer Programming, Elsevier Science, volume 44, 2002. 6. Desmond D’Souza and Alan Wills. Objects, Components and Frameworks With UML: The Catalysis Approach. Addison-Wesley, 1999. 7. F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. Grose. Eclipse Modeling Framework. Addison Wesley, 2004. 8. Heinrich Hussmann, Birgit Demuth, and Frank Finger. Modular architecture for a toolset supporting ocl. In Proceedings of UML. Elsevier North-Holland, Inc., June 2002. 9. S. Kent. Model Driven Engineering. In Proceedings of IFM 2002, http://www.cs.kent.ac.uk/pubs/2002/1594, pages 286–298. Springer-Verlag, May 2002. 10. A. Muller, O. Caron, B. Carr´e, and G. Vanwormhoudt. R´eutilisation d’aspects fonctionnels : des vues aux composants. In Langages et Mod`eles a ` Objets (lmo’03), pages 241–255, Vannes, France, January 2003. Herm`es Sciences. 11. Jos Warmer and Anneke Kleppe. The Object Constraint Language – Second Edition, Getting Your Models Ready for MDA. Addison-Wesley, 2003.