consistency of model transformation contracts
TRANSCRIPT
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.1 (1-19)
Science of Computer Programming ••• (••••) •••–•••
Contents lists available at ScienceDirect
Science of Computer Programming
www.elsevier.com/locate/scico
Consistency of model transformation contracts
Christiano Braga a,b,∗, Cássio Santos a,b, Viviane Torres da Silva a
a Instituto de Computação, Universidade Federal Fluminense, Brazilb ADDLabs, Universidade Federal Fluminense, Brazil
a r t i c l e i n f o a b s t r a c t
Article history:Received 7 April 2012Received in revised form 8 August 2013Accepted 19 August 2013Available online xxxx
Keywords:Mathematical aspects of softwareengineering
Model-driven development is a generative software development process with increasingrelevance both in industry and academia. Model transformations are the generativecomponents in a model-driven development process. As such, their analysis is an importanttask. We have been developing a technique to specify, validate and implement modeltransformations. Our technique is based on the concept of transformation contracts,a specification that relates two modeling languages and declares properties that must befulfilled in such a relation. Since a transformation contract is a model, the verification andvalidation of a transformation contract use the same techniques that are used to verifyand validate any given model. This paper describes our technique, discusses consistency ofmodel transformations and reports on its application to a non-trivial model transformationfrom access control models to Java security.
© 2013 Published by Elsevier B.V.
1. Introduction
Model-driven development (MDD, e.g. [1]) is a software engineering discipline that considers models as live artifactsin the development process. By live artifacts we mean that models are not used for documentation purposes only butactually as input to software tools that may operate on them and produce other artifacts. Such artifacts may be compilablesource-code or even other models, in the same or different abstraction levels than the source model. MDD aims at allowingfor a generative software development process in which applications are produced from formal models possibly describedat the application domain level.
Model transformations are important artifacts in a model-driven development process since they are the generativecomponents of the process. As such, their specification, verification and validation are imperative tasks in an MDD process.A transformation contract (e.g. [2–5]) is a specification of a model transformation. Essentially, a transformation contract iscomprised by relations, between the model elements of the modeling languages it relates, and properties that such relationsmust fulfill. Therefore, a model transformation specification may be understood as a model that relates metamodels. (Morespecifically, it is the disjoint union of metamodels, as we shall see in Section 4.) In this paper, inspired by [6], we call themodel representing a model transformation a transformation model. A particular application of a model transformation isrepresented as an object model instance of the transformation model. A transformation contract is thus a transformationmodel and a set of properties over it. Therefore, one may use the same modeling language used to specify the modelinglanguages being related to also describe the model transformation and the same model reasoning techniques may be appliedto reason about model transformations as well.
In [2–5,7,8], the present authors and others specify metamodel properties as invariants in the Object Constraint Lan-guage representing typing rules of the different metamodels involved in a model transformation. In this paper, we generalize
* Corresponding author at: Instituto de Computação, Universidade Federal Fluminense, Brazil.E-mail addresses: [email protected] (C. Braga), [email protected] (C. Santos), [email protected] (V.T. da Silva).
0167-6423/$ – see front matter © 2013 Published by Elsevier B.V.http://dx.doi.org/10.1016/j.scico.2013.08.013
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.2 (1-19)
2 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
previous work and allow for the automatic verification of model transformation consistency understood as satisfiability of anassociated theory in Description Logics [9].1 We also discuss the implementation of transformation contracts as the appli-cation of a design pattern [5] extended with consistency checking support. As a proof of concept, we discuss the applicationof our proposed technique with a non-trivial model transformation from access control models to Java security.
This paper contributes with: (i) a logical formalization of transformation contracts, a rigorous approach to the specifica-tion, verification and implementation of model transformations, (ii) the inclusion of model consistency verification into thetransformation contracts approach, and (iii) tool support to the proposed approach, vis-à-vis, (a) the Consistency Checker,2
a tool for checking model consistency according to the technique discussed in Section 4, and (b) the SecureUMLtoAAC+JAAStool,3 an implementation of the model transformation from SecureUML to Java security, that performs OCL validation andconsistency checking for stereotyped SecureUML models.
This paper is a revision and an extension of [10]. All sections have been revised, made more precise and extended.Section 4, in particular, was thoroughly extended with new results from the formalization of the notion of extended TBoxesof models while reasoning about model transformation consistency with Description Logics.
Plan of the paper. Section 2 discusses related work. Section 3 describes our proposed model transformation process, makingprecise important concepts in MDD that are otherwise loosely applied. Section 4 formalizes transformation contracts astheories in Description Logics and describes how consistency verification may be added to our model transformation process.Section 5 describes our case study. It reports on the rigorous implementation of model transformations according to ourproposed model transformation process and exemplifies its application. We conclude this paper in Section 6 with our finalremarks.
2. Related work
In this paper we discuss three aspects of the development of model transformations, namely its specification, verificationand implementation. Therefore, we organize this section following these three perspectives.
At the specification level, we adopt a relational approach towards the specification of a model transformation. It is similarin essence to [11,6] but different from [2,3]. In [2] the authors specify transformation contracts as OCL invariants fromsource and target model elements. We formalize our understanding of transformation contracts in Section 3 as opposed tothe informal discussion in [11,6,3]. (The authors in [2,3] also discuss the use of pre- and post-conditions but such predicatesmay also be represented as invariants.) The specification of a relation between the model elements of the metamodelsrelated by a model transformation is essential to generalize from OCL invariants and understand that different kinds ofproperties may be specified over such relation. It is important to make explicit the relationship among the metamodels.
In [6] the idea of transformation model to specify model transformation is discussed. The authors describe the benefitsof omitting details of the transformation process and concentrating in depicting the transformation as a model, in whichmodels are instances of metamodels and transformations can be described in conformity to a metamodel. From this point itis possible to describe a transformation model in a formal way, thus it can be validated and verified. We share the idea oftransformation models but in this work we make precise what we mean by transformation model (as the result of a disjointunion of two metamodels) and how it may be used to reason on model transformations, as opposed to [6].
OMG’s Query View Transformations (QVT) [12] and Graph Grammars (GG) (e.g. [13–15]) are other possible specificationsfor a model transformation that require specific theory and machinery to reason and implement model transformations.(In the case of GG, focus is on the verification of typical properties of term rewriting systems such as confluence andtermination.) The transformation contracts approach proposed in this paper is not biased by any particular specificationlanguage and may be used with them as well. Note, however, that QVT is bound to OCL as the specification language forthe properties of metamodels and there are properties, such as consistency, subject of this paper, best specified in othersemantic frameworks. GG may not have QVT’s restriction on the specification language for metamodel properties but a keyaspect of our approach is that we apply to model transformation specification design the same specification languages andtechniques one would to design a modeling language. No additional framework, such as QVT or GG, is necessary.
At the verification level, different kinds of properties may be reasoned upon besides OCL invariants. One such propertyis model consistency understood as satisfiability of a propositional formula representing a constrained model. In this paper,we check for the consistency of Description Logic theories associated with a given model. Note that, since we understandmodel transformations as models, their consistency may be checked as one would check the consistency of any given model,such as in [16].
In [17] the authors use an SMT-solver to check for the satisfiability of model transformations. The mapping is essentiallybuilt upon a first-order logic semantics for OCL in [18]. However, they are focused on a particular model transformationlanguage. We believe that to be able to use the same modeling language to describe both the metamodels and modeltransformation is an important issue.
1 In this paper, we focus on a particular Description Logic that allows us to write axioms encompassing set union, set intersection, set complement, andbinary relations with inverse and cardinality constraints.
2 http://lse.ic.uff.br/node/11.3 http://lse.ic.uff.br/node/14.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.3 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 3
Some approaches to model verification consider the transformations of models into other languages and formalisms,in which the validation occurs by the use of solvers or theorem provers. In [19], Constraint Satisfaction Problem (CSP) isused to verify UML/OCL models using a translation method. After the translation, a constraint solver is used to verify ifthe constraint problem induced by the OCL specification is satisfiable. In [20] the authors propose the verification of modeltransformations specified in a language that extends QVT relations with CSP techniques. The use of CSP techniques is similarto our use of Description Logic however their approach is bound to QVT.
We believe that work on test case generation for model transformations (e.g. [21,22]) is also related to our approachwhen one understands the analysis associated with a Design by Contract [23] (DbC) approach as a form of testing. DbC,as in Hoare Logic, allows for the specification of invariants, pre- and post-conditions of programs. A key aspect in a DbCapproach is checking such specifications every time a program is ran. A key point in our approach is that we check forthe properties specified in a transformation contract every time a model transformation is applied, following DbC ideas. Forinstance, consistency checking of models (that ask for the existence of scenarios, that is, object models that are instances ofthe given model) is performed every time a model transformation is applied.
At the implementation level, given our generalization, we are not confined to OCL based languages such as OMG’s QueryView Transformation (QVT) to specify our transformation contracts. QVT is one possibility, that allows for the specificationof the relation among the metamodels related by a model transformation. We generalize the understanding of concreteand abstract syntaxes discussed in [11,3]. There, the authors impose that the concrete syntax of a modeling language mustbe in bijection with the abstract syntax described by the metamodel. This has the benefit for the model transformationdesigner to have a parser for any given modeling language. However, this choice is cumbersome for the user (of a modeltransformation) since one must create a quite detailed model so that a machine may understand what one wants. The ideaof a domain-specific modeling language appears precisely to allow descriptions at the domain level and, if possible, conciseones. This is what UML profiles are for. In our proposed model transformation process, described in Section 4 we allow themodel transformation designer (actually the modeling language designer) to define how a model must be represented as aninstance of a metamodel and its inverse, in the form of parsing and pretty-printing functions.
3. Model-driven development with transformation contracts
In this section we interpret the application of model transformations and transformation contracts from a logical per-spective. Models and metamodels are understood as logical theories. Since a transformation contract is also a model, itmay be inconsistent. This is the subject of Section 3.1. Section 3.2 gives an illustrative example using a simplified UMLmetamodel and an example invariant that checks for cycles in the class hierarchy. The example in Section 3.2 illustrates theinconsistency problem in a UML model. In Section 4 we will see how a decidable logic can help us solve this problem.
3.1. Model transformations
Model transformations relate languages. If one decides to work with the standards of the Object Management Group(OMG), to take advantage of the interoperability gained from using such standards, the abstract syntax of the languagesrelated by a model transformation may be described in the form of a UML class diagram.4 Such a model is called a meta-model and it describes the syntax that models should follow. In the Meta Object Facility (MOF) standard, from OMG, a UMLdiagram may be represented as an object model (or simply model) that is an instance of a class diagram representing ametamodel.5
A model that is a proper instance of a metamodel is called well-formed with respect to the given metamodel. Thenotion of well-formedness may be understood as the pertinence of a program (or word) with respect to a context-freelanguage, that is, a model must be well-formed with respect to its metamodel as a program written in a language L mustbe well-formed with respect to L’s syntax. Definitions 1, 2 and 3 formalize the notions of model, metamodel and modelwell-formedness with respect to a metamodel, respectively.
Definition 1 (Object model). An object model m is a structure 〈O ,At, L〉 where O ⊆ Id×Class is a set of objects with o : C ∈ Oan abbreviation for 〈o, C〉 ∈ O denoting that the object identified by o is an instance of class C ; At ⊆ Id × Id × Values is aset of object attributes with a(o, v : T ) ∈ A an abbreviation for 〈a,o, (v, T )〉 ∈ A, a denotes an attribute of object o, and va (typed) value attached to a, with T ⊆ Value; and L ⊆ Id × Id × Id is a set of links relating objects in O with l(o1,o2) anabbreviation for 〈l,o1,o2〉.
Definition 2 (Metamodel). A metamodel M is a structure 〈C,A〉 with C the set of classes of M comprised by a set ofattribute declarations Id × (T ∪ C) and a set of method declarations Id × (T ∪ C)∗ × (T ∪ C), and A ⊆ C2 × K 2 the set ofassociations of M where K is the set of association’s cardinalities given by intervals of the general form [n1..n2], wheren1,n2 ∈ N and n1 � n2.
4 Of course, the Backus–Naur Form, or BNF for short, could also be used for such descriptions but the main point here is to interoperate and use all theefforts based on such standards.
5 In this paper, whenever we refer to a UML model, we will be making a reference to an object model, unless explicitly stated otherwise.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.4 (1-19)
4 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
m ∈ Sparse
m′ ∈ S,m′ | PSτ n ∈ T ,n | PT ,k | PK
pretty printn′ ∈ T .
Fig. 1. Model transformations with transformation contracts.
Definition 3 (Well-formed model). Given an object model m = 〈O ,At, L〉 and a metamodel M= 〈C,A〉, m is said well-formedwith respect to M, denoted by m ∈ M, if and only if for every object o : c ∈ O we have c ∈ C , each tuple formed byattributes in At indexed by o is an element of the product denoted by c, and for every link l(o1,o2) in L, o1 : c1 ∈ O ando2 : c2 ∈ O , with c1, c2 ∈ C , and there exists an a ∈A such that a = (c1, c2,k1,k2), with k1,k2 ∈ K .
With the concepts formalized up to this point, the application of a model-transformation may be drawn as follows,where m,m′,n,n′ are models; S and T represent the source and target metamodels related by a model transformationτ ; we write m ∈ M to denote that the model m is well-formed with respect to any given modeling language M where Mrepresents the concrete syntax for a given modeling language M and M represents the abstract syntax of a given modelinglanguage M , that is, M is the metamodel of M; parse is the mapping that given a model m written in the concrete syntaxof a modeling language M (S and T in the diagram) generates an abstract syntax version m′ of m where m′ is well-formedwith respect to M; finally, pretty print is the inverse mapping of parse, that is, it generates the concrete syntax of themodeling language M given a model instance of M,
m ∈ Sparse
m′ ∈ S τ n ∈ T pretty printn′ ∈ T .
It is not always true, however, that any well-formed model with respect to a given metamodel M of a modeling languageM is in conformance with M . A modeling language may have properties (in a given logic, such as first-order logic or atemporal logic) that must hold on all instances of its metamodel.
Definition 4 (Model conformance). Given a model m and a metamodel M, m is said in conformance with M, denoted bym |M, if and only m | PM , where PM is the set of properties that must hold on every model m ∈M. When PM is notempty, M is defined as a triple 〈C,A, P 〉.
While well-formedness represents proper syntactical character of a model with respect to a metamodel, conformancerepresents proper semantics preservation of a model with respect to a given metamodel.
When conformance is considered, the application of a model transformation may be drawn as follows, where PM is theset of properties of the metamodel of the modeling language M and m | PM means that PM hold in the model m ∈M,
m ∈ Sparse
m′ ∈ S,m′ | PSτ n ∈ T ,n | PT
pretty printn′ ∈ T .
We are now ready to explain the concept of transformation contracts and how it fits into the MDD approach consideredin this paper. A transformation contract is a specification of what a model transformation should do. It is comprised by atransformation model, that relates the metamodels of a source and target modeling languages through a set of associationsand a set of properties that must hold on every instance of the transformation model.
Definition 5 (Transformation contract). A transformation contract is a model K resulting from a model operation S �AK Ton two given metamodels S and T that extends6 the metamodels S and T and: (i) disjointly unites7 all the model elementsof S and T ; (ii) declares associations a ∈ AK that relate classes in S with T and disjointly unites AK with S and T ; and(iii) declares properties PK over AK .
The application of a model transformation may be drawn as in Fig. 1 when transformation contracts are consideredwhere K = S �AK T , k ∈K, l ∈AK and k = (m �l n),
We would like to emphasize that we are applying a Design by Contract approach to the verification of model transfor-mations. Therefore, the different properties are checked every time a model transformation is applied.
Note, however, that the process depicted in Fig. 1 works under the assumption that all models and metamodels areconsistent, in the logical sense of the word. A metamodel is consistent if there exist models that are in conformance with it,that is, if it admits instances. A model is consistent if it has scenarios.
Definition 6 formalizes metamodel consistency. Note that this definition also applies to model consistency: one onlyneeds to perceive the given model as a metamodel and its scenarios as object models. Moreover, since a transformationcontract is also a model, the notion of model consistency also applies to it.
6 We use the word extends here in its algebraic sense that “junk” may be added but no “confusion”, that is, new terms may be added but are notidentified with old ones.
7 The disjoint union avoids name clashing by tagging each model element name with the metamodel’s name.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.5 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 5
Fig. 2. Simplified UML metamodel.
Definition 6 (Metamodel consistency). A metamodel M is said to be inconsistent, denoted by ∅ | M, if metamodel M hasnot a model in conformance with it.
Finally, Definition 7 formalizes our notion of correctness of a model transformation with respect to a transformation con-tract. Informally, given a consistent source metamodel, a consistent target metamodel, a consistent transformation contractmodel, and a model in conformance with the source metamodel, a correct model transformation should generate a modelin conformance with the target metamodel and a transformation scenario in conformance with the transformation contractmodel.
Definition 7 (Correctness with respect to a transformation contract). An application of a model transformation to a model m issaid correct with respect to a transformation contract K =M�A M′ iff
(∅ �| M∧ ∅ �| M′ ∧ ∅ �| K) ⇒(m ∈ M
(∃m′ ∈ M′ ∧ l ∈ A(m | PM ⇒ (
(m′ | PM′) ∧ (k | PK)))))
where k ∈K, and k = m �l m′ .
3.2. Illustrative example
We will use a simplified version of the UML metamodel as a running example until Section 5 where our transformationcontract case study is thoroughly discussed. For pedagogical purposes, our illustrative examples cover a single domain andnot a model transformation. Note that, since we understand a model transformation as model, all the discussion regardingmodel consistency also applies to a model transformation as well. Section 5 exemplifies consistency in the context of atransformation contract.
Now, Fig. 2 shows a simplified version of the UML metamodel, slightly enhanced from [1] by considering inheritancebetween classes through the association inherited-inheritsFrom. The metamodel essentially represents the notions of classes,association classes, features, attributes, association ends, and their relations. Any given class diagram may be seen as awell-formed (object) model with respect to the UML class diagram in Fig. 2.
As an illustrative example, let us consider a model m with an inheritance chain that has a cycle. It may be syntacticallywell-formed with respect to UML’s metamodel in Fig. 2 but it is not in conformance with it. The reason is that there is aninvariant (a type of property in Definition 4) in the UML metamodel that specifies that there should be no cycles in anyinheritance chain. Since the invariant does not hold in m, the model m is not in conformance with UML’s metamodel. (Theconformance relation between a model m and a metamodel M requires well-formedness of m with respect to M.)
One way to specify such invariants is using the Object Constraint Language (OCL). Essentially, OCL has several constructsfor manipulating collections of typed model elements in a model m, navigating through m’s relationships, defining oper-ations and invariants in M, where M is the metamodel of m. For example, the invariant noCyclesinClassHierarchy belowchecks for the presence of cycles in class hierarchies in a model instance of the simplified UML metamodel by verifying foreach class c if c is not included in the transitive closure of the inheritsFrom relationship that represents class inheritancehierarchy. The invariant uses two operations, namely superPlus and superPlusOnSet, to calculate the reflexive-transitive clo-sure. The operation superPlusOnSet does the actual calculation by a recursive call on each element of the collection yieldedby the inheritsFrom relation for each class c. Regarding OCL syntax, the keyword context defines the type of objects that theinvariant should be applied to. The keyword inv defines an invariant. The informal meaning of the remaining OCL construc-tors in the example are as follows: forAll iterates over the elements of a given collection checking for a given predicate;
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.6 (1-19)
6 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
excludes checks if a given collection does not contain a given element; collects creates a collection of objects such that agiven predicate holds; flatten receives a set which may have other sets as elements and produces a flatten set of objectsfrom its set elements; asSet casts a collection into a set; and including includes a given element in a given collection. Theuser-defined function emptySet constructs an empty set of objects of type Class.
1 context Class inv noCyclesinClassHierarchy: self.super−>forAll(r|r.superPlus()−>excludes(self))2 context Class::superPlus():Set(Class) body: self.superPlusOnSet(self.emptySet())3 context Class::superPlusOnSet(rs:Set(Class)):Set(Class) body:4 if self.inheritsFrom−>notEmpty() and rs−>excludes(self)5 then self.inheritsFrom−>collect(c : Class | c.superPlusOnSet(rs−>including(self)))−>flatten()−>asSet()6 else rs−>including(self) endif
OCL can be used to automatically validate UML models. Considering an implementation of an OCL interpreter, suchas [24], one may actually apply the invariants of a metamodel M to a syntactically well-formed model m with respectto M to guarantee m’s conformance with respect to M. Therefore, before applying a model transformation to a givenmodel m, one must make sure that m is syntactically well-formed with respect to M and all invariants in M (such asnoCyclesinClassHierarchy) hold in m. For example, a simplified UML class diagram must be well-formed with respect to thesimplified UML metamodel in Fig. 2 and the invariant noCyclesinClassHierarchy should hold on it.
Inconsistent models. However, the application of an invariant to an object model m only makes sense if the metamodelM is consistent, that is, if it admits instances. For instance, let us assume that the meaning of an inheritance hierarchyis constrained to a disjoint and complete inclusion relation, that is, if B � A � C denotes an inheritance relationamong classes B , C and A meaning that B ⊆ A ∧ C ⊆ A ∧ A ⊆ B ∪ C ∧ B ∩ C = ∅ where A, B and C are sets representing thehomonymous classes. Now, if an inheritance relation is additionally specified between classes Association and Class in thesimplified UML metamodel in Fig. 2 then Class would become inconsistent since both AssociationClass and Association areinconsistent. AssociationClass is inconsistent since is simultaneously disjoint from Association and a subset of it. Association isinconsistent since it is equivalent to AssociationClass. (They are included in one another.) This is formalized by the followingaxiom.
Class = Association ∪ AssociationClass ∧AssociationClass ⊆ Association ∧Association ⊆ AssociationClass ∧AssociationClass ∩ Association = ∅
Therefore, the application of an OCL invariant to any object model that claims to be an instance of this inconsistent simplified UMLmetamodel would be meaningless. From Definition 7, if the source or target metamodels or the transformation contract modelis inconsistent, anything is implied.
The question then is: how can we check for model consistency before applying OCL invariants to object models? The approachdescribed in this paper uses a logical approach to answer this question by checking the consistency of Description Logic [9]theories of the associated models before validating them using OCL. This is the subject of Section 4.
4. Specifying transformation contracts in Description Logics
In Section 4.1 we recall basic concepts of Description Logic. Section 4.2 discusses how to represent UML models with OCLconstraints in Description Logics. Finally, in Section 4.3 we discuss how to incorporate consistency checking to our modeltransformation with transformation contracts process.
4.1. Description Logics
Description Logics is a family of logics defined to be efficiently decidable. Each fragment of the logic was carefully studiedon its expressiveness and efficiency of reasoning.
A specification in DL has two components: (i) the terminology box or TBox, comprised essentially by concepts, whichdenote sets; concept subsumption represented by C � C ′ , denoting set inclusion, where C and C ′ are concepts (C ≡ C ′abbreviates C � C ′ and C ′ � C ); and roles, which are essentially binary relations, and (ii) the assertion box, or ABox, a set ofindividuals (or instances) of the TBox concepts.
In this paper we will focus on ALCQI , a particular Description Logic which is expressive enough for the purposes ofthis paper, that is, representing UML models with OCL constraints.
The syntax of ALCQI ’s axioms is as follows:
C ::= A | ¬C | C1 � C2 | (� k R.C)
R ::= P | P−
where C , C1 and C2 are concepts, A is an atomic concept, k ∈N, R is a role and P an atomic role with P− its inverse.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.7 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 7
Table 1Mapping from class diagrams to DL.
Given a class Diagram D , the TBox T associated with D is defined as follows:
1. For each class C in D there exists an atomic concept C in T ;2. For each generalization between a class C and its child class C1 in D there exists an
inclusion assertion C1 � C in T . A class hierarchy is represented by the assertionsC1 � C, . . . , Cn � C in T when Ci inherits from C in D . A disjointness constraintamong classes C1, . . . , Cn in D can be modeled as Ci � �n
j=i+1 ¬C j , with 1 � i �n − 1 in T , while a covering constraint can be expressed as C � ⊔n
i=1 Ci in T ;3. Each binary association (or aggregation) A between a class C1 and a class C2, with
multiplicities ml ..mu and nl ..nu on each end, respectively, in D is represented bythe atomic role A, together with the inclusion assertion � � ∀A.C2 �∀A−.C1 in T .The multiplicities are formalized by the assertions C1 � (� nl A.�) � (� nu A.�)
and C2 � (� ml A−.�) � (� mu A−.�), where � denotes the largest concept (top)that includes all concepts and ∀R.C is just syntactic sugar for � 0 R.¬C in T .
Some abbreviations may help the definition of ALCQI TBoxes: (i) ⊥ ≡ A � ¬A, where A is an atomic concept;(ii) � ≡ ¬⊥; (iii) C1 � C2 ≡ ¬(¬C1 � ¬C2); (iv) C1 ⇒ C2 ≡ ¬C1 � C2; (v) � k R.C ≡ ¬(� (k − 1)R.C); (vi) (= 1C .R) ≡(� 1C .R �� 1C .R); (vii) ∃R.C ≡ (� 1 R.C); and finally, ∀R.C ≡ ¬∃R.¬C .
The meaning of a TBox is defined in a standard way by means of an interpretation I = (�I , ·I), where �I is the domainof I and ·I is the interpretation function that associates to a concept C , or relation R , a subset of the domain with theappropriate arity. The following rules specify the interpretation for ALCQI TBoxes.
�T = �I �Tn ⊆ (�I)n
PI ⊆ �I2 AI ⊆ �I
(P−)I ⊆ {(a,a′) ∈ �I2 | (a′,a) ∈ PI} (C1 � C2)
I ⊆ CI1 ∩ CI
2(� kR.C)I ⊆ {a ∈ �I | ¬CI ⊆ �I/CI
#{a′ ∈ �I | (a,a′) ∈ RI ∧ a′ ∈ CI}� k}Given a TBox T , an interpretation that satisfies all of T ’s assertions is called a model of T . Similarly, a TBox T is
said consistent if T has a model and inconsistent otherwise. A concept C is satisfiable in a TBox T if there exists aninterpretation I of T such that CI is not empty, that is, C ⊆ ⊥.
Definition 8 (TBox consistency). A TBox T is said consistent if all concepts in T are consistent. We define the predicateisConsistent : TBox → Bool to denote TBox consistency, where CT denotes the concepts of the TBox T and ⊥ is the emptyconcept:
isConsistent(T ) ={
true, ∀c ∈ CT (c �� ⊥)
false, otherwise.
4.2. Representing UML models with OCL constraints in Description Logics
In this paper, we identify the concepts of UML model and model of the logical theory of DL TBoxes.We understand a UML model as an object model instance of a given metamodel. With this understanding in mind,
a metamodel is formalized as a TBox, and a UML model, that is an object model instance of the given metamodel, isformalized as an interpretation of the TBox associated with the given metamodel.
Now, if a metamodel is inconsistent, understood as the TBox that represents the metamodel being inconsistent, then thegiven metamodel has no instances, that is, it does not have any object models that properly instantiate it. In logical terms,the TBox that represents the metamodel has an empty interpretation.
If a modeling language is inconsistent, that is, if the metamodel (together with its properties) is inconsistent, than sucha language has no models both in the UML and logical sense.
We apply the same formalization to UML models and scenarios by understanding a UML model as a logical theory andits scenarios as possible models for such a logical theory.
Now, DL consistency reasoning may be applied to class diagrams when a proper encoding is defined between classdiagrams and TBoxes in DL. Such a mapping has been defined in [16], has been proven correct and the complexity of DLreasoning on class diagrams has been calculated. The encoding of class diagrams in DL essentially relates classes with DLconcepts and association ends with DL roles. For the purposes of this paper, it suffices to explain the encoding for classes,inheritance and binary associations following [16, Section 7.1]. Table 1 captures this encoding. Informally, classes give rise toconcepts and associations to pairs of (inverse) roles, representing its association ends. Cardinality constraints are capturedby cardinality axioms over the appropriate roles.
Now, we need a logic as expressive as First-Order Logic (FOL) to represent general OCL constraints as logical formulae.Unfortunately, FOL is not decidable. In [25] the authors propose a mapping from a subset of OCL, called OCL Lite, to De-scription Logics. OCL Lite essentially allows for the specifications of invariants comprised by quantifiers, select expressions,
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.8 (1-19)
8 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
Table 2Syntax of OCL Lite normal form.
OCL-LiteConstraint ::= context C inv : OCL-LiteExprOCL-LiteExpr ::= Path SelectExpr | oclIsTypeOf(C) | not OCL-LiteExpr |
OCL-LiteExpr and OCL-LiteExpr |OCL-LiteExpr or OCL-LiteExpr |OCL-LiteExpr implies OCL-LiteExpr
Path ::= PathItem | PathItem.PathPathItem ::= R | oclAsType(C).R
SelectExpr ::= BooleanOp | →select(OCL-LiteExpr) BooleanOpBooleanOp ::= →isEmpty() | →notEmpty()
Table 3Semantics of OCL Lite normal form.
�context C inv : OCL-LiteExpr� = C � �OCL-LiteExpr��Path →notEmpty()� = �Path�.�
�Path →isEmpty()� = ¬ �Path�.��Path → select(OCL-LiteExpr)→notEmpty()� = �Path�.�OCL-LiteExpr�
�Path → select(OCL-LiteExpr)→isEmpty()� = ¬ �Path�.�OCL-LiteExpr��PathItem.Path� = �PathItem�.�Path�
� R � = ∃R�oclAsType(C).R � = C � ∃R
�oclIsTypeOf(C)� = C�not OCL-LiteExpr� = ¬�OCL-LitetExpr�
�OCL-LiteExpr and OCL-LiteExpr� = �OCL-LitetExpr� � �OCL-LiteExpr��OCL-LiteExpr or OCL-LiteExpr� = �OCL-LitetExpr� � �OCL-LiteExpr�
�OCL-LiteExpr implies OCL-LiteExpr� = ¬�OCL-LitetExpr� � �OCL-LiteExpr�
type casting and type checking, and a limited form of cardinality checking of collections that only verifies if a collection isempty or not. OCL Lite may be normalized into a simpler form, called OCL Lite normal form. The syntax of OCL Lite normalform is described in Table 2.
Table 3 defines the semantics, denoted by the operator �·�, of normalized OCL Lite in terms of Description Logics, whereC is a concept and R is a role. Informally, an invariant gives rise to a Description Logic axiom that constraints the conceptthat contextualizes the given invariant. The body of an OCL Lite invariant, denoted by the syntactical category OCL-LiteExpr,is, essentially, a path expression followed by a set-emptiness check expression (e.g. select(OCL-LiteExpr)→isEmpty()), a typeexpression (e.g. oclIsTypeOf(C)), or a composition of OCL Lite expressions (e.g. OCL-LiteExpr and OCL-LiteExpr). A path ex-pression is represented in DL by the concept constructor ∃R.C , where R denotes either an attribute or an association endand C is a concept denoting an OCL-LiteExpr.
Definition 9 (TBox of a class diagram). Given a class Diagram D , the TBox T associated with D is defined by the mappingsdefined in Table 1 and Table 3.
Illustrative example. Let us consider now the subset of the UML model in Fig. 2 that we used to illustrate the model con-sistency problem in Section 3.2 with a set of invariants that can be automatically checked. Table 4 describes this model inECore syntax: a notation to describe models used in the Eclipse Modeling Framework [26].8 The model declares: (i) classesClassifier, Association, Class (which inherits from Classifier), Feature, AssociationClass (which inherits from Class and Associ-ation), and AssociationEnd (which inherits from Feature); (ii) an association named feature–classifier among classifiers andfeatures. Recall from Section 3.2 that we are assuming that the inheritance relationship is complete and disjoint. Invari-ants classifierInheritanceComplete, associationInheritanceComplete, classInheritanceComplete, featureInheritanceComplete specifythe completeness constraint on the inheritance relationship. Finally the invariant associationClassCannotBeTypedByAssociation-End (defined in [1]) does not allow an association class to have an association end, that is, only the classes related by anassociation class may have association ends.
Let us look how the model in Table 4 is represented in Description Logic. The application of Definition 9 to the model inTable 4, considering the inheritance relation as a complete and disjoint inclusion relation, gives rise to the TBox describedin Table 5. Axiom (1) denotes the relationship between classes Classifier and Feature. Axiom (2) defines the cardinality con-straint of relationship classifier–feature. Axioms (3) to (6) capture the inheritance relationship between classes Class andClassifier, AssociationClass and Class, AssociationClass and Association, and, finally, AssociationEnd and Feature. The invariantassociationClassCannotBeTypedByAssociationEnd is represented by Axiom (7). Axioms (8), and (9) denote the completenessconstraints of the inheritance relationship between AssociationClass and Class and the inheritance relationship between Asso-ciationClass and Association. (Since Class has only AssociationClass as its child, there is no axiomatization for the disjointness
8 ECore’s textual representation makes it easier to present the invariant together with the model.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.9 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 9
Table 4A subset of the simplified UML metamodel.
package UMLMetamodelSimple : UMLMetamodelSimple = ’http://UMLMetamodelSimple/1.0’{
class Classifier{
property feature#classifier : Feature[*] { ordered };invariant classifierInheritanceComplete: oclIsTypeOf(Class);
}class Association
{invariant associationInheritanceComplete: oclIsTypeOf(AssociationClass);
}class Class extends Classifier
{invariant classInheritanceComplete: oclIsTypeOf(AssociationClass);
}class Feature
{property classifier#feature : Classifier { ordered };invariant featureInheritanceComplete: oclIsTypeOf(AssociationEnd);
}class AssociationClass extends Class,Association;class AssociationEnd extends Feature
{invariant associationClassCannotBeTypedByAssociationEnd:
self.classifier->forAll(not oclIsTypeOf(AssociationClass));}
}
Table 5TBox for the model in Table 4.
� � ∀classifier.Classifier � ∀feature.Feature (1)
Feature � = 1 classifier.� (2)
Class � Classifier (3)
AssociationClass � Class (4)
AssociationClass � Association (5)
AssociationEnd � Feature (6)
AssociationEnd � ¬∃ classifier.AssociationClass (7)
Class � AssociationClass (8)
Association � AssociationClass (9)
Feature � AssociationEnd (10)
Classifier � Class (11)
constraint. Similarly, for class Association.) Axioms (10) and (11) denote the completeness constraint for the inheritancerelationships that have classes Feature and Classifier as superclasses.
Now, if an inheritance relation is declared between classes Association and Class, as in the illustrative example of Sec-tion 3.2, the following axioms would be included in the TBox of Table 5.
Association � Class (12)
Class � AssociationClass � Association (13)
Association � ¬AssociationClass (14)
Axiom (12) denotes inheritance between Association and Class. Axiom (13) denotes the completeness constraint of theinheritance relationship among the subclasses of Class, which is captured by Axiom (8) in Table 5. Axiom (14) denotes the
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.10 (1-19)
10 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
disjoint constraint over child classes of Class. The inconsistency arises from Axioms (5) and (14) that require AssociationClassto be included in Association and Association and AssociationClass to be disjoint, respectively.9
4.3. Verifying the application of transformation contracts with DL
We are now ready to explain how a transformation contracts is formalized as a TBox in Description Logic and howconsistency checking is incorporated into our model transformation process. First, recall that a transformation contract isa UML model. Therefore, Definition 9 applies to a transformation contract as it applies to any given UML model. Second,regarding the inclusion of consistency checking into our model transformation process, the idea is essentially to check formodel consistency before validating the appropriate invariants as it only makes sense to check for properties of models that areconsistent, as discussed in Section 3.1 and exemplified in Section 3.2.
Recall from Section 3.1 that we validate each model every time a model transformation is applied, as drawn in Fig. 1.We have two sources of inconsistency: a metamodel may be inconsistent and a model may be inconsistent. In the formercase, there are actually no models to be transformed and, in the latter case, a given model has no scenarios. The questionthen is how to reason on both metamodel and model consistency at once and prevent both cases.
Now, there are two types of reasoning procedures in DL: the so-called ABox reasoning means to check that the axiomsof a TBox hold on a particular set of individuals (or instances) of concepts and roles. The so-called TBox reasoning means toperform a symbolic reasoning process over a given TBox that verifies if the axioms of a TBox are generally satisfiable and notonly for a particular set of individuals.
In the context of the analysis of UML models, the ABox reasoning of a model m instance of a metamodel M requiresthe representation of the metamodel M as a TBox and m as an ABox, that is, a set of individuals. The ABox reasoningprocess consists of checking that the axioms of the TBox representation of M hold in the ABox representation of m. TheTBox reasoning of a model m, instance of a metamodel M, requires an extension of the TBox that represents the metamodelM of m with the Description Logic axioms that represent m itself. In this paper, we call it extended TBox reasoning. It allowsfor consistency checking of metamodel and model consistency at once and is the most general reasoning process.
Let us now make this discussion precise. Definition 10 formalizes what is the TBox of an object model and Definition 11formalizes the concept of Extended TBoxes.
Definition 10 (TBox of an object model). Given an object model O = 〈O , A, L〉, the TBox of O, denoted by O, is given by theapplication of the following mapping to O: (i) for each object o ∈ O there exists a concept o in O, and (ii) for each attributea(o, v : T ) ∈ A there exists an axiom O � a.T in O.
The extended TBox of a model with respect to a metamodel adds axioms that relate the TBox of an object model withthe TBox of the metamodel. This is done essentially by: (i) (disjointly and completely) including the concepts representingthe objects of a certain class into the concept that represents the given class and, (ii) for each link, adding an axiom relatingthe concepts representing the objects in the given link by the appropriate role.
Definition 11 (Extended TBox). Given a model m and a metamodel M, such that m ∈ M and m | M, the TBox of mextended with respect to the TBox of M, or extended TBox for short, denoted by Mm , is given by the union of M, givenby Definition 9, with m, given by Definition 10, together with: (i) axioms o � C , for each concept o in m, representing anobject o in m, with C the concept representing o’s class; (ii) disjointness axioms among objects of the same type C in mdeclared as oi � �n
j=i+1 ¬o j , with 1 � i � n − 1 and n the cardinality of the set of objects of type C in m, (iii) completenessaxioms among objects of the same type C in m declared as C � ⊔n
i=1 oi , with n the cardinality of the set of objects of type Cin m, (iv) let L A be the set of links in m for association A in M, then (a) for each link l(oi,o j) ∈ L A , with A ⊆ C1 × C2,
axiom oi � =1A.o j is in Mm , and (b) for all l(oi,o) �∈ L A , with o ∈ C2 (and all C2’s child concepts), axiom oi � ¬∃A.o is
in Mm .
Remark. DL has the so-called open world assumption which means that a missing link between objects, for instance, is notconsidered an error, as opposed to the so-called closed world assumption, where the absence of information, such as a missinglink between objects, is an error. Now, in Definition 11, case (iv(b)), it is necessary that o ∈ C2 and all C2’s child conceptsdue to open world assumption. Consider a model D A � {B, C} where A, B, C and D are sets, there is a relationbetween D and A and classes B and C are subclasses of A. Now consider an object model with objects d1, b1 and c1 witha link between d1 and b1. If it is not said that d1 and c1 are not linked then the reasoning process may consider it due tothe open world assumption.
9 This example can be automatically checked with the Consistency Checker using the model umlMetamodelSimpleCyclic.ecore which is availablein the Example/scpmodels folder available from http://lse.ic.uff.br/node/11.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.11 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 11
m ∈ Sparse
m′ ∈ S,
isConsistent(Sm′ ),m′ | PS
τ
n ∈ T ,k ∈K,
isConsistent(Tn),
isConsistent(Kk),n | PT ,k | PK
pretty printn′ ∈ T
Fig. 3. Model transformations with consistent transformation contracts.
Fig. 4. An object model for the UML model in Table 4.
We now state and prove Theorem 1 about extended TBoxes which says that any model which is in conformance with agiven metamodel has a consistent extended TBox and any extended TBox represents a model in conformance with a givenmetamodel.
Theorem 1. Given a model m and a metamodel M,
m ∈ M∧ m | M ⇔ isConsistent(Mm).
Proof. For the right implication, m ∈ M ∧ m | M ⇒ isConsistent(Mm), since m | M then isConsistent(M) given thecorrectness of Definition 9 in [16]. Moreover, the axioms of m do not make M inconsistent for the following reasons,defined by case on Definition 10 and considering Definition 11. The axioms produced for links in step (i) of Definition 10are properly typed due to Definition 11 since: (a) the roles l and l− , created for a given link l, are subroles of the appropriaterole R , representing the association that l instantiates, (b) relate subconcepts of the concepts related by R . The axiomsproduced in step (ii) of Definition 10 relate, for each attribute, a primitive type T with a subconcept of a concept alreadyaxiomatized in M, since m | M and Definition 11. The axioms produced in step (iii) of Definition 10 will not make Minconsistent since m | M. In the worst case, given Definition 10, for each role R in M there will be as many axioms forlinks that are instances of R as the cardinality specified for R therefore fulfilling the cardinality constraints axiomatizedin M.
For the left implication, m ∈M∧m |M⇐ isConsistent(Mm), it should be noted that the mappings in Definitions 9, 10and 11 are invertible. Therefore, given TBoxes structured as defined by these mappings, the application of them in theinverse direction, from TBoxes to models, will produce from M a class diagram representing the metamodel M and fromm an object model representing a model m. Since M is consistent, M admits instances. Given the structure imposedby Definitions 9, 10 and 11, m is one such instance, therefore m | M. Since a model which is in conformance with ametamodel must be well-formed with respect to it, we have m ∈M. �
When model consistency is considered, our model transformation process is drawn as in Fig. 3, where Sm′ , Tn and Kkdenote the extended TBox of the source, target and transformation models, respectively.
Illustrative example. Let us consider now an object model of the UML model in Table 4 depicted in Fig. 4.This object model is inconsistent because it breaks the cardinality constraints of the UML model in Table 4. The extended
TBox of this example is described by Axioms (1), (2), (3), and (6), from the subset of the simplified UML metamodel inTable 5, and Axioms (15) to (24) denoting the object model in Fig. 4. (We are only displaying the axioms that are directlyrelated with the inconstancy problem.) The inconsistency arises because Axiom (3) states that every Feature is connected toa single Classifier. However, Axioms (23) and (24) connect AssociationEnd ae1, which is also a Feature, to two disjoint classes,c1 and c2, which are also Classifiers.10
� � ∀classifier.Classifier � ∀feature.Feature (1)
10 This example can be automatically checked with the Consistency Checker using the model umlsimplemodel.xmi and model umlMetamodelSim-ple.ecore which is available in the Example/scpmodels folder available from http://lse.ic.uff.br/node/11.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.12 (1-19)
12 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
Feature � = 1 classifier.� (2)
Class � Classifier (3)
AssociationEnd � Feature (6)
c1 � Class (15)
c2 � Class (16)
Class � c1 � c2 (17)
c1 � ¬c2 (18)
ae1 � AssociationEnd (19)
AssociationEnd � ae1 (20)
c1 � = 1 feature.ae1 (21)
c2 � = 1 feature.ae1 (22)
ae1 � = 1 classifier.c1 (23)
ae1 � = 1 classifier.c2 (24)
4.4. DL and OCL are complementary techniques
It should be clear that consistency checking via TBox reasoning in DL is a general process as opposed to ABox reasoningin DL and OCL validation which is applied to a particular model represented as a set of individuals in DL or as an objectmodel in OCL validation. Using DL one may check for: (i) metamodel consistency, in other words, answer the question“Does this modeling language admit models?”, and therefore reason about the consistency of a modeling language, and (ii)model consistency, in other words, answer the question “Does this model admit scenarios?” and therefore reason about thepossibility of the instantiation of a particular model, that is, the existence of scenarios for a given model. DL allows forunbounded checking.
OCL validation executes OCL invariants on a particular scenario or metamodel instance. It does not allow any reasoningat the modeling language level. (However, all techniques allow for reasoning on models.) At this point one may wonderwhy OCL validation is necessary at all if DL reasoning is considered. The point is that DL does not represent OCL entirelysince checking satisfiability of general OCL expressions is undecidable. Therefore, DL and OCL validation (the execution ofOCL invariants over object models) are complementary techniques, as pointed out by the first author and Haeusler in [27], inthe sense that OCL validation identifies errors that DL reasoning may miss. Due to its open world semantics, if DL reasoningdoes not identify a problem because there is missing information in a model then the execution of OCL invariants would.This is the reason why these techniques should be applied sequentially starting with DL reasoning. Section 5.2.1 exemplifiesthe complementarity of the reasoning techniques.
5. A transformation contract from access control policies to Java security
We exemplify the specification of a transformation contract with an excerpt of the model transformation from the mod-eling language SecureUML+ComponentUML [28], for access control modeling, to a modeling language we call JAAS thatrepresents the Java Authentication and Authorization Service. This excerpt is part of the SecureUMLtoAAC+JAAS modeltransformer that generates AspectJ code, an extension of the Java programming language with aspect-oriented concepts,with JAAS support. The tool is available for download from http://lse.ic.uff.br/node/14. The complete description of themodel transformation is given in [7].
5.1. The modeling languages
SecureUML+ComponentUML is a language to model access control. A model in SecureUML+ComponentUML describespermissions that user roles have in order to perform actions over entities. Examples of such actions are: (i) the executionof a method, (ii) updating an entity’s state, or (iii) full access to an entity. The first two actions are atomic actions andthe last one a composite action. As opposed to atomic actions, composite actions form a collection of actions which maybe atomic or composite. The EntityFullAccess composite action, for instance, allows for both read and update access to allelements of an entity, that is, its attributes, methods and association ends. It includes EntityRead and EntityUpdate which inturn include AtomicRead and AtomicUpdate, respectively. SecureUML also allows for the modeling of user roles’ hierarchies.Role inheritance means that if role r1 inherits from role r2 than all permissions of r2 also apply to r1. The metamodel ofSecureUML+ComponentUML is described in Fig. 5.
We have defined a modeling language called JAAS, which is the acronym for the Java Authorization and AuthenticationService, to capture the access control subset of the Java security framework. Its metamodel is depicted in the diagram
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.13 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 13
Fig. 5. SecureUML+ComponentUML metamodel.
Fig. 6. JAAS metamodel.
in Fig. 6. In JAAS there are different authentication mechanisms such as Lightweight Directory Access Protocol (LDAP) orNetwork Information Service (NIS). These mechanisms are captured as instances of a protection domain. The metaclassesPrincipal, JAASPermission and JAASAction are the counter parts of Role, Permission and Action in SecureUML. We will focus onthe transformation from Role, Permission and Action to Principal, JAASPermission and JAASAction in this paper.
5.2. The transformation contract
The “raison d’être” of a transformation contract is to guarantee that essential properties of the source model are pre-served in the target model in a given transformation. In our example, we want to guarantee that a user in a given SecureUMLrole is properly represented as a principal, that is, a principal may enact exactly the same actions with the same constraintsof its associated role.
In this paper, we will focus on the transformation from Role, Permission and Action to Principal, JAASPermission andJAASAction, respectively. As opposed to SecureUML, JAAS does not have role hierarchies or composite action hierarchies.The transformation contract from SecureUML+ComponentUML model to JAAS models is the result of a composition of twocontracts: (i) the flattening contract F , in which the role and action hierarchies are flattened in SecureUML+ComponentUMLand (ii) the mapping contract M, in which flattened SecureUML+ComponentUML and JAAS are related. With the composedcontract,11 a principal will be able to enact the actions associated with the permissions of the role that the given principal isrelated with, since: (i) flattening the role hierarchy associates with a given role all the permissions of the transitive closure
11 The SecureUML+ComponentUML to JASS model transformation is presented as a non-trivial proof of concept for transformation contracts. The compo-sition of flattening and mapping contracts is a design choice in the development of this particular model transformation and it is not part of the generaltechnique to develop model transformations with transformation contracts. It arose due to the lack of expressivity of composed roles and actions in JASS,which is present in SecureUML.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.14 (1-19)
14 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
1 context Role inv targetsRoleFlattened:2 Role’.allInstances()→select( role’ |3 role’.isFlattened() and role’.name = self.name and4 role’.default = self.default role’.haspermission = self.allPermissions())→size() = 15 context Role::allPermissions():Set(Permission) body: self.superrolePlus().haspermission→asSet()6 context Role::superrolePlus():Set(Role) body: self.superrolePlusOnSet(self.superrole)7 context Role::superrolePlusOnSet(rs:Set(Role)):Set(Role) body:8 if rs.superrole→exists(r|rs→excludes(r))9 then self.superrolePlusOnSet(rs→union(rs.superrole)→asSet())
10 else rs→including(self) endif
Fig. 7. Role flattening invariant.
1 context Action’ inv actionFlattening:2 self.faction-permissions→includesAll(self.atomicaction-faction→allPermissions())
Fig. 8. Action flattening invariant.
of its inheritance hierarchy and (ii) flattening the action hierarchy associates with a given role all the atomic actions, andtheir constraints, for each composite action in a given permission.
Recall from Definition 5 that a contract is a structure K = 〈(CS ∪ AS ) � (CT ∪ AT ) � AK, PS ∪ PT ∪ PK〉, where �denotes the disjoint union operation. For the SecureUMLtoAAC+JAAS contract, the properties are invariants that must holdon model instances of the contract, that is, applications of the model transformation. In the reminder of this section, wewill refer to the properties sets PM as IM since this example only specifies invariants.
For the flattening contract F , CS and AS are the metaclasses and associations from the SecureUML+ComponentUMLmetamodel. The properties PS will not be discussed here as they are not relevant to our example. (For the sake of exem-plification, one such invariant is that, in any given SecureUML model, every role must inherit from a default role that has adefault permission over resources.) The set CT includes metaclasses Role′ and Action′ , for flattened role and flattened action,respectively. The set AT includes12: (i) a one-to-one association role–frole between metaclasses Role in SecureUML and Role′in flattened SecureUML, (ii) a one-to-one association atomicaction–faction between AtomicAction in SecureUML and Action′ inflattened SecureUML, (iii) a one-to-many association frole–permission between Role′ in flattened SecureUML and Permissionin SecureUML, and finally, (iv) a one-to-many association faction–permission between Action′ in flattened SecureUML andPermission in SecureUML. The set PT is empty since F is an endogenous transformation in SecureUML that substitutes therole and action hierarchies for equivalent ones without inheritance. Therefore, there are no invariants in the target of Fsince the contract is only about flattening.
The set PK specifies the flattening process. The first invariant in PK , targetsRoleFlattened (see Fig. 7), specifies that aRole′ “mirror” instance of a Role in SecureUML model has the same permissions of the reflexive–transitive closure of thesuperrole relation of the given Role. The operation allPermissions is defined in [29] and calculates all the Permissions of thetransitive closure of the superrole relation between instances of Role in SecureUML.
The invariant actionFlattening (see Fig. 8) specifies that every Action′ instance has the same permissions as its AtomicActioncounterpart which means gathering the permissions of all CompositeAction that the given AtomicAction is part of togetherwith the permissions attached to the AtomicAction itself. The operation allPermissions for AtomicAction is calculated in a waysimilar to Role but using the transitive closure of the composite actions relation.
The signatures in M are given by the metaclasses and associations of flattened SecureUML and JAAS. The set PK of Messentially establishes a bijection between Role’ and PrincipalRole and a bijection between Action′ and JAASAction: for everyRole′ there must exist a PrincipalRole such that the PrincipalRole’s associated instances of JAASAction are those related withthe instances of Permission of the given Role′ . There are other aspects of model transformation that are handled by M butare out of the scope of this paper. We refer the interested reader to [7] for a detailed presentation of the complete modeltransformation from SecureUML+ComponentUML to JAAS and AspectJ.
5.2.1. Verifying and validating SecureUMLtoAAC+JAAS with DL and OCLIn Section 4.4 we discussed how DL verification and OCL validation complement each other. The analysis of the flattening
contract comprises the verification of the consistency of the transformation model of the flattening contract and executionof its invariants to a particular model in an application of the model transformation SecureUMLtoAAC+JAAS. An excerpt isdepicted in Fig. 9.
Let us consider an example of the application of the extended TBox technique, discussed in Section 4.3, using the map-ping contract M. We discuss two scenarios: (i) DL reasoning identifies a problem in an implementation of M, that is, theextended TBox associated with a model instance of M is inconsistent and (ii) DL reasoning does not identify a problem inM due to the open world assumption but the OCL validation does.
12 There could be associations between a class in the source metamodel and different classes in the target metamodel. This example is functional but itshould be clear that AT denotes a relation.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.15 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 15
Fig. 9. Subset of the mapping contract from flattened SecureUML+ComponentUML to AAC+JAAS.
Fig. 10. A simple SecureUML object model.
For the first scenario, let us consider a model m resulting from a faulty implementation of the transformation contractfor SecureUMLtoAAC+JAAS. The model m in Fig. 10 is an instance of the transformation model M in Fig. 9 that contains aBasicPermission b associated with a protection domain pd through the association end isprotectedby (which has associationend permissions as its inverse) and two instances of Permission p1 and p2 through its permission association end, which hasthe association end basicpermission as its other end.
Following Definition 11, the extended TBox for m, denoted by Mm , includes the following axioms from M,
� � ∀permission.Permission � ∀basicpermission.BasicPermission (25)
Permission � (= 1 permission.�), (26)
BasicPermission � (= 1 basicpermission.�). (27)
and the following axioms from m,
b � BasicPermission (28)
BasicPermission � b (29)
p1 � Permission (30)
p2 � Permission (31)
Permission � p1 � p2 (32)
pd � ProtectionDomain (33)
ProtectionDomain � pd (34)
p1 � ¬p2 (35)
p1 � = 1 basicpermission.b (36)
p2 � = 1 basicpermission.b (37)
b � = 1 permission.p1 (38)
b � = 1 permission.p2 (39)
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.16 (1-19)
16 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
Fig. 11. A design pattern for model transformations with transformation contracts.
b � = 1 isprotectedby.pd (40)
pd � = 1 permissions.b. (41)
The extended TBox Mm described above is inconsistent because Axioms (25) to (27) constrain role permission to exactlyone Permission for each BasicPermission and there are individuals from both concepts p1 and p2 related to an individual ofb, as axiomatized in (38) and (39).
For the second scenario, let us consider a model m ∈M, with M the mapping contract in Fig. 9, containing an instancep of PrincipalRole. The metamodel M specifies that there must exist a one-to-one association between a given PrincipalRoleand a Role, which is not the case in our scenario. Due to the open world assumption, discussed in Section 4.4, DL reasoningwould not identify this violation. As we mentioned before, the open world assumption allows us to identify inconsistencieson given information. Nothing can be said if the information is not there. This is where OCL validation comes into place. Theapplication of the invariant that constrains the cardinality on the association between PrincipalRole and Role would fail form as the collection returned by navigating through the association between PrincipalRole and Role from p would produce anempty collection when it should be of size 1.
5.3. A rigorous model transformation implementation for SecureUMLtoAAC+JAAS
We have defined a design pattern [5] that captures the general process of model transformations with transformationcontracts described in Fig. 1 aiming at providing a rigorous mechanism for the implementation of model transformationsin any given general-purpose programming language. The design pattern enforces the verification and validation at thedifferent points that they must occur in a model transformation, that is, the analysis of: (i) the source model before themodel transformation is applied, (ii) the target model after the transformation is applied and (iii) both source and targetmodels and the associations between them also after the application of the model transformation. According to Definition 7,a transformation contract may not be valid, that is, it can be the case that a particular application of a model transformationfails. In the case of the model transformation from SecureUML+ComponentUML to AAC+JAAS this would mean that either theDL consistency checking failed or OCL invariant validation failed. Exceptions are raised in such cases. As a matter of fact, thedesign pattern, as well as the model transformation process it implements, is general enough to incorporate new analysistechniques and not only DL reasoning and OCL validation for different modeling languages when the proper encodings aredefined, of course.
Fig. 11 presents a class diagram of our proposed design pattern. In the pattern, a Domain represents a modeling languagewhich interacts with a ModelManager, responsible for model persistence, and validators responsible for model analysis. EachDomain has a parser from the XMI standard representation, that is, the Domain’s concrete syntax, to its metamodel, whichis the Domain’s abstract syntax. The transformation model of a transformation contract is represented by class JoinedDomainwhich references the two instances of Domain it relates, named source and target. The class TransformationContract declaresa static method transform that executes the model transformation process that we have explained in Section 4. It is staticbecause it is always the same behavior, independently of the actual domains that a particular model transformation relates.Since class Domain is abstract, and functions parsing and pretty-printing are domain-specific, they should be overwrittenby every domain (such as the SecureUML+ComponentUML domain). Therefore, the instances of Domain, related by a giveninstance of TransformationContract, will perform the “real” work, that is, parsing, pretty printing and the encodings to thedifferent formalisms are either implemented in methods within classes that inherit from Domain or that a Domain delegatesto its instances.
Fig. 12 depicts the application of the design pattern for model transformations with transformation contracts to themodel transformation from SecureUML+ComponentUML to AAC+JAAS. (As mentioned before, the model transformation alsouses aspect-oriented model elements, which are out of the scope of this paper, but this is the reason why the acronym
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.17 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 17
Fig. 12. Applying the design pattern to the SecureUML to JAAS model transformation.
Fig. 13. OCLPad showing an inconsistency error.
AAC appears in the model.) SecureUML and SecureUML+Component UML are coded as different domain classes. The lat-ter extends the former with metaclasses and associations making the action and resource hierarchies more concrete, asexplained in Section 5.1. Moreover, each domain has its own validator class that implements the encoding to the properreasoner. For DL reasoning, we use the Pellet13 reasoner and for OCL execution we use EOS [24], which is also used tomanage model persistence. Implementing a model transformation as an application of our proposed design pattern enforcesthe implementation of a rigorous model transformation as different verification and validation techniques can be applied.
One may execute each step of the model transformation, as depicted in Fig. 1, using the TCPad application which supportsinteraction with the EOS model manager through OCL and allows for the visualization of the different models (source, targetand joined) using the Prefuse14 visualization toolkit. TCPad is a general graphical user interface application that has beenextended to allow the interactive application of the SecureUMLtoAAC+JAAS model transformation, in this work, and othermodel transformations created by our group such as in [5].
Fig. 13 depicts TCPad showing the inconsistency identified by Pellet, the DL reasoner used in this work, described bythe fist scenario of Section 5.2.1. Fig. 14 depicts TCPad showing the invariant error described by the second scenario ofSection 5.2.1.
6. Final remarks
We are developing and applying a general technique for the rigorous specification, verification and implementation ofmodel transformations using the concept of transformation contracts. A transformation contract is essentially a transfor-
13 http://clarkparsia.com/pellet/.14 http://prefuse.org.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.18 (1-19)
18 C. Braga et al. / Science of Computer Programming ••• (••••) •••–•••
Fig. 14. TCPad showing an invariant error.
mation model that relates metamodels and a set of properties over the transformation model. Implementations of modeltransformations are realized as an application of a design pattern that enforces our proposed model transformation process.In this paper we have used the standardized metalanguages of UML class diagrams, OCL for the specification of metamodelsand invariants over them together with Description Logics to verify consistency. However, our approach is not coupled withany particular choice of metalanguages. Different metanotations and reasoners may be employed in the development of amodel transformation. We plan to continue our work by integrating different automated analysis techniques to our modeltransformation process and to apply our approach to industrial case studies, such as [30].
References
[1] A.G. Kleppe, J. Warmer, W. Bast, MDA Explained, Addison-Wesley, 2003.[2] E. Cariou, R. Marvie, L. Seinturier, L. Duchien, OCL for the specification of model transformation contracts, in: Proc. of OCL and Model Driven Eng.
Workshop, 2004, pp. 69–83.[3] P.V. Gorp, D. Janssens, Cavit: a consistency maintenance framework based on transformation contracts, in: Transformation Techniques in Soft. Eng.,
2005, number 05161 in Dagstuhl Seminar Proc.[4] C. Braga, A transformation contract to generate aspects from access control policies, J. Softw. Syst. Model. 10 (2010) 395–409, http://dx.doi.org/
10.1007/s10270-010-0156-x.[5] C. Braga, R. Menezes, T. Comicio, C. Santos, E. Landim, Transformation contracts in practice, IET Softw. 6 (2012) 16–32.[6] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault, I. Kurtev, A. Lindow, Model transformations? Transformation models!, in: Proc. of MoDELS’06, in: Lect.
Notes Comput. Sci., vol. 4199, Springer, 2006, pp. 440–453.[7] T. Comicio, A transformation contract approach to model-driven security, Master’s thesis, Universidade Federal Fluminense, http://www2.ic.uff.br/
PosGraduacao/Dissertacoes/500.pdf, 2011 (in Portuguese).[8] R. Menezes, Transformation contracts in practice, Master’s thesis, Universidade Federal Fluminense, http://www2.ic.uff.br/PosGraduacao/Dissertacoes/
521.pdf, 2011 (in Portuguese).[9] F. Baader, D.M. Diego Calvanese, D. Nardi, P. Patel-Schneider, The Description Logic Handbook, Cambridge University Press, 2003.
[10] C. Braga, R. Menezes, T. Comicio, C. Santos, E. Landim, On the specification verification and implementation of model transformations with transforma-tion contracts, in: A. Simao, C. Morgan (Eds.), Proceedings of the 14th Brazilian Symposium, SBMF 2011, São Paulo, Brazil, September 26–30, in: Lect.Notes Comput. Sci., vol. 7021, Springer, 2011, pp. 108–123.
[11] D.H. Akehurst, S. Kent, A relational approach to defining transformations in a metamodel, in: Proc. of the 5th Int. Conf. on UML, UML ’02, Springer-Verlag, London, UK, 2002, pp. 243–258.
[12] OMG, MOF QVT final adopted specification, OMG adopted specification ptc/05-11-01, 2005.[13] A. Schürr, Specification of graph translators with triple graph grammars, in: Proc. of WG’94, in: Lect. Notes Comput. Sci., vol. 903, Springer, 1995,
pp. 151–163.[14] F. Hermann, H. Ehrig, U. Golas, F. Orejas, Efficient analysis and execution of correct and complete model transformations based on triple graph gram-
mars, in: Proceedings of the First International Workshop on Model-Driven Interoperability, MDI ’10, ACM, New York, NY, USA, 2010, pp. 22–31.[15] L. Ribeiro, L. Foss, B. Silva, D. Nunes, Model transformation using graph transactions, in: Proceedings of the 11th International Conference on Software
Reuse: Formal Foundations of Reuse and Domain Engineering, ICSR ’09, Springer-Verlag, Berlin, Heidelberg, 2009, pp. 95–105.[16] D. Berardi, D. Calvanese, G.D. Giacomo, Reasoning on UML class diagrams, Artif. Intell. 168 (2005) 70–118.[17] F. Büttner, M. Egea, J. Cabot, On verifying ATL transformations using ‘off-the-shelf’ SMT solvers, in: Proceedings of the 15th International Conference
on Model Driven Engineering Languages and Systems, MODELS’12, Springer-Verlag, Berlin, Heidelberg, 2012, pp. 432–448.[18] M. Clavel, M. Egea, M.A.G. de Dios, Checking unsatisfiability for OCL constraints, in: J. Cabot, J. Chimiak-Opoka, F. Jouault, M. Gogolla, A. Knapp (Eds.),
Proceedings of the Workshop The Pragmatics of OCL and Other Textual Specification Languages at MoDELS 2009, in: Electronic Communications of theEASST, vol. 24, 2009, pp. 1–13.
[19] J. Cabot, R. Clarisó, D. Riera, Verification of UML/OCL class diagrams using constraint programming, in: Proc. of IEEE Soft. Testing Verification andValidation Workshop, pp. 73–80.
[20] A. Petter, A. Behring, M. Mühlhäuser, Solving constraints in model transformations, in: Proc. of ICMT ’09, in: Lect. Notes Comput. Sci., vol. 5563,Springer, 2009, pp. 132–147.
JID:SCICO AID:1597 /FLA [m3G; v 1.113; Prn:16/09/2013; 9:08] P.19 (1-19)
C. Braga et al. / Science of Computer Programming ••• (••••) •••–••• 19
[21] S. Sen, B. Baudry, J.-M. Mottu, Automatic model generation strategies for model transformation testing, in: Proc. of ICMT ’09, in: Lect. Notes Comput.Sci., vol. 5563, Springer, 2009, pp. 148–164.
[22] C. Fiorentini, A. Momigliano, M. Ornaghi, I. Poernomo, A constructive approach to testing model transformations, in: Proc. of ICMT’10, in: Lect. NotesComput. Sci., vol. 6142, Springer, 2010, pp. 77–92.
[23] B. Meyer, Object-Oriented Software Construction, 2nd edition, Prentice Hall, 1997.[24] M. Clavel, M. Egea, M.A.G. de Dios, Building an efficient component for OCL evaluation, ECEASST 15 (2008), http://www.bm1software.com/eos/.[25] A. Queralt, A. Artale, D. Calvanese, E. Teniente, OCL-Lite: Finite reasoning on UML/OCL conceptual schemas, Data Knowl. Eng. 73 (2012) 1–22.[26] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF: Eclipse Modeling Framework, 2nd edition, Eclipse Series, Addison-Wesley Professional, 2008.[27] C. Braga, E.H. Hæusler, Lightweight analysis of access control models with description logic, Innov. Syst. Softw. Eng. 6 (2010) 115–123.[28] D. Basin, J. Doser, T. Lodderstedt, Model driven security: From UML models to access control infrastructures, ACM Trans. Softw. Eng. Methodol. 15
(2006) 39–91.[29] D. Basin, M. Clavel, J. Doser, M. Egea, Automated analysis of security-design models, Inf. Softw. Technol. 51 (2009) 815–831.[30] C. Braga, R. Menezes, C. Santos, A. Track, T. Iversen, R. Silva, Towards model-driven development of seismic applications with transformation contracts,
in: Proceedings of the 2nd Brazilian Workshop on Model-Driven Software Development (WB-DSDM’11), CBSoft 2011, São Paulo, Brazil, 2011, pp. 34–42.