From UML and OCL to Relational Logic and Back

Transcription

1 From UML and OCL o Relaional Logic and Back Mirco Kuhlmann and Marin Gogolla Universiy of Bremen, Compuer Science Deparmen Daabase Sysems Group, D Bremen {mk,gogolla}@informaik.uni-bremen.de Absrac. Languages like UML and OCL are used o precisely model sysems. Complex UML and OCL models herefore represen a crucial par of model-driven developmen, as hey formally specify he main sysem properies. Consequenly, creaing complee and correc models is a criical concern. For his purpose, we provide a lighweigh model validaion mehod based on efficien SAT solving echniques. In his paper, we presen a ransformaion from UML class diagram and OCL conceps ino relaional logic. Relaional logic in urn represens he source for advanced SAT-based model insance finders like Kodkod. This paper focuses on a naural ransformaion approach which aims o exploi he feaures of relaional logic as direcly as possible hrough sraiening he handling of main UML and OCL feaures. This approach allows us o explicily benefi from he efficien handling of relaional logic in Kodkod and o inerpre found resuls backwards in erms of UML and OCL. 1 Inroducion Creaing complee and correc models is a criical concern. Modeling languages like UML [24] and OCL [30] allow for precisely specifying sysems which ofen resul in complex models. The analysis of formulaed sysem properies hus requires ool suppor. Lighweigh model validaion approaches allow for agile analysis, since hey allow modelers o auomaically perform muliple validaion asks a any sage of developmen. The advanage of lighweigh approaches, in conras o ineracive verificaion approaches, is (a) heir applicabiliy, as users do no need be familiar wih fields like logical deducion, and (b) heir immediaeness regarding he feedback. As a consequence, hose approaches mus be efficien. We analyze properies of UML class models annoaed wih OCL consrains by analyzing model insances [9], since he exisence or non-exisence of insances wih specific properies allows direc conclusions abou he model iself. For efficienly searching model insances, we apply SAT-based echniques [2], i. e., solvers for Boolean saisfiabiliy. This approach requires he connecion of UML and OCL wih Boolean logic resuling in a bidirecional ransformaion. However, we make use of an inermediae language, relaional logic, whichis auomaically and efficienly handled by he sophisicaed model insance finder R.B. France e al. (Eds.): MODELS 2012, LNCS 7590, pp , c Springer-Verlag Berlin Heidelberg 2012

2 416 M. Kuhlmann and M. Gogolla Kodkod [28]. Kodkod ransforms relaional models ino SAT formulas and ranslaes soluions fulfilling he SAT formulas back ino relaional insances. In his paper, we presen he ransformaion of UML and OCL models ino relaional models, as well as he backward ranslaion from relaional insances ino UML model insances. We pursue a naural ransformaion approach which aims o exploi he feaures of relaional logic as direcly as possible hrough sraiening he handling of main UML and OCL feaures. This approach allows us o explicily benefi from he efficien handling of relaional logic in Kodkod. While explaining he ransformaion, we focus on imporan modeling aspecs and conceps which have no been concerned or adequaely reaed in oher UML and OCL model validaion approaches based on relaional logic [1,27], e. g., n-ary associaions and associaion classes a he UML side, as well as he undefined value and essenial operaions like collec and navigaion via n-ary associaions and associaion classes a he OCL side. This ransformaion approach is suppored by a ool classified as a model validaor which processes a class diagram and OCL invarians as well as informaion (in form of parial objec diagrams and properies like he minimum and maximum number of objecs and links, or aribue value domains) deermining he search space, ha is, he se of model insances o be examined. The ransformaion is fully auomaed wih respec o boh direcions, from UML and OCL o relaional logic, and back from relaional soluions o UML (objec diagrams) (for an overview see [15]). The res of he paper is srucured as follows: Secion 2 inroduces relevan conceps of relaional logic and Kodkod. The main Sec. 3 presens he bidirecional ransformaion. In Sec. 3.1 we consider he ransformaion of UML class diagrams ino relaional models, while Sec. 3.2 discusses he backward ranslaion. The configuraion of search spaces is shorly skeched in Sec Secion 3.4 covers he OCL par of he ransformaion. Relaed work is discussed in Sec. 4 before we conclude wih Sec Background: Relaional Logic and Kodkod Relaional logic [10] is based on fla n-ary relaions, i. e., ses of uples of aomic values (aoms). The evaluaion resul of a relaional formula hus depends on concree insances of relaions. Aoms are consans wih no specific semanics or inner srucure. The individual meaning of an aom emerges from is occurrence in specific relaions. However, i is possible o assign a specific semanics o a subse of he available aoms by mapping hem o ineger values. Thereby, ineger calculaions are enabled. Relaions can express hree kinds of values: Aomic Values: An aomic value is represened by a unary relaion including exacly one uple wih one componen holding he respecive aom. For example, he ineger value 3 and an aom symbolizing he name Ada are realized by he relaional values [[3]] and [[Ada]]. Ses of Aoms: A se of aomic values yields a unary relaion wih possibly more han one uple or no uple, in he case of an empy se. The se of aoms

3 From UML and OCL o Relaional Logic and Back 417 {Ada,Bob,Cyd}, for example, resuls in he relaional value [[Ada],[Bob], [Cyd]]. The aoms Ada, Bob and Cyd do no have a specific meaning, unless hey are pu ino a conex, e. g., if we declare a unary relaion fnames, we consider all uples wihin insances of his relaion as individual firs names. Ses of Relaionships beween Aoms: Aomic values are ofen semanically relaed o oher aomic values. This fac can be described wih n-ary relaions in which uples hold sequences of aoms. Each posiion in a n-ary uple has a specific meaning. Consider, for example, persons who have a name and possibly younger siblings. In order o relae a person o a name and her younger siblings, we can declare wo binary relaions fname and ysiblings, and deermine ha he firs posiion of he uples in boh relaions yields a person aom and he second posiion yields a name or anoher person aom, respecively. Possible insances could be fname=[[p1,ada], [p2,cyd],[p3,bob], [p4,dan]] and ysiblings=[[p1,p3],[p1,p4]]. Relaional logic provides: (a) relaional operaions like he relaional join, produc and ransiive closure, as well as mulipliciy predicaes like some and lone, (b) se comprehension, (c) se operaions like union and subse, (d) Boolean operaions like conjuncion and implicaion, (e) quanifiers of firs order logic-like exisenial and universal quanifiers, and (f) ineger operaions like addiion and comparison predicaes. The relaional join (expressed by a do.) is a cenral operaion, since i allows for exracing and merging he informaion provided by relaion insances. A join is performed in he conex of wo relaional values x and y which may be of differen ariy. The evaluaion resul of he expression x.y is equal o {(x 1,...,x n 1,y 2,...,y m ) (x 1,...,x n ) x (y 1,...,y m ) y x n = y 1 }. An example for informaion exracion wih a join is he deerminaion of a person name based on he menioned relaion fname. The expression [[p1]].fname resuls in he name relaed o he person aom p1, i. e., in our example [[Ada]]. Anoher example illusraes he merging of wo binary relaions which in our case resuls in a se of uples relaing persons o he names of heir younger siblings: ysiblings.fname=[[p1,bob],[p1,dan]]. Kodkod is a ool which provides an inerface o defining relaional models and o efficienly finding relaional insances fulfilling given relaional formulas [28]. A relaional model consiss of hree pars (we will see examples in laer secions): Declaraions: A relaion declaraion deermines he name and ariy of a relaion for which Kodkod searches a valid insance. Bounds: Kodkod is a finie model insance finder, i. e., he universe of aoms available for consrucing relaional values is finie. A relaional model includes (a) an a priori, fully deermined universe of aoms, and (b) bounds for each declared relaion which generally resric he ses of possible uples based on available aoms. In his way, a concree search space is defined. Consrains: Relaional consrains, i. e., formulas, can furher resric he valid insances of he declared relaions. Our approach ranslaes a UML and OCL model ino a relaional model handled by Kodkod. Resuls in form of relaional model insances presened by Kodkod will be ranslaed back ino insances of he UML and OCL model.

4 418 M. Kuhlmann and M. Gogolla 3 A Bidirecional Transformaion The aim of ranslaing UML and OCL models ino relaional models is an efficien search for UML and OCL model insances which fulfill specific user-defined properies. The ransformaion of UML class diagram and OCL conceps ino relaional logic is based on hree key requiremens: The ransformaion of a UML class diagram resuls in a se of relaions. Insances of hese relaions mus srucurally allow for represening all possible insances of he corresponding UML class diagram. Each valid insance of he relaional model mus represen a valid insance of he corresponding UML class diagram respecing he given UML and OCL consrains. The same mus apply for invalid insances. The relaional model mus be formulaed as simply as possible, enabling he mos efficien processing by he model insance finder (Kodkod). UML and OCL offer conceps like collecions (i. e., ses, bags, ordered ses, sequences, and nesed collecions) and a hree valued logic which are fundamenally differen from conceps of relaional logic (e. g., solely fla ses and a wo-valued logic). For ha reason, he firs wo requiremens which concern he compleeness and correcness of he ranslaion conflic wih he hird requiremen concerning efficiency. We ackle wo differen approaches o ransforming UML and OCL ino relaional logic, one giving weigh o he firs wo aspecs, he oher focussing on he hird aspec: Exrinsic Relaional Approach: This approach aims o ransform UML and OCL conceps as compleely as possible ino relaional logic enabling, for example, he ranslaion of all kinds of (possibly nesed) collecions, srings and he associaed operaions. Furhermore, he hree valued-logic of OCL is simulaed a he relaional level. This virual abuse of relaional logic leads o complex relaional srucures (involving high-ariy relaions), large search spaces, and hence o losses in efficiency (for deails of he exrinsic approach see [14]). Inrinsic Relaional Approach: The inrinsic approach aims o make use of srucures direcly suppored by relaional logic, i. e., aomic values, ses of aomic values, and ses of relaionships beween aomic values (cf. Sec. 2), as well as relaional formulas wih wo ruh-values insead of hree (as in OCL). On he one hand, his approach naurally resuls in manageable relaional models which can be efficienly processed. On he oher hand, i induces several resricions o he suppored UML and OCL feaures. In his paper, we presen he inrinsic ransformaion approach and discuss he advanages and disadvanages, pracical implicaions for validaion and feasible alernaives. The inrinsic approach has been successfully applied, for example, in he conex of role-based access conrol (RBAC) revealing ha he imposed resricions do no hinder he validaion of reasonable models [17].

5 From UML and OCL o Relaional Logic and Back 419 Fig. 1. Example UML Class Diagram 3.1 From UML Class Diagrams o Relaional Models In his secion, we focus on he ransformaion of cenral UML class diagram feaures which are frequenly used for modeling srucural aspecs of sysems ino relaional model conceps, i. e., relaions and relaional consrains. The ransformaion is illusraed wih he help of he example class diagram shown in Fig. 1 which has been designed for explanaion purposes covering ineresing aspecs. I describes persons wih a name and a se of addresses. If employable, persons can have a mos one job. A company has a name and defines a minimum salary for is employees. A person can be hired by a mos one employee in he conex of a specific company. In order o explain boh, a binary associaion and a binary associaion class, we aim o consider Job as an ordinary associaion (neglecing he grey par), on he one hand, and o consider Job as an associaion class (involving he grey par), on he oher hand. The associaion class adds a salary o each job. Basic Types. The ransformaion uniformly handles he values of he UML basic ypes Boolean, Ineger, Real, andsring as aomic values. Consequenly, basic ypes resul in unary relaions whose insances hold he disincive ses of available basic values, yping he aoms accordingly. Basic ype values are needed in he conex of UML aribue values, as we will see laer. Boolean unary relaion Boolean=[[rue],[false]]. The resuling Boolean relaion yields a consan insance holding he Boolean values rue and false. Ineger unary relaion Ineger of srucure [[i 1 ],...,[i nin ]]. Example insance: [[-2],[0],[1],[1000],[1100],[1200],[2000]]. The ineger relaion can be variably insaniaed, i. e., Kodkod searches an adequae insance. Each ineger aom whose name represens an ineger lieral is bijecively mapped o a corresponding ineger value which can be used for calculaions wihin a relaional formula. For insance, he aom 1 is mapped o he value 1. Relaional logic provides he respecive mapping operaions (in and In). In order o sore calculaion resuls in relaions, he respecive ineger values mus have an aomic counerpar wihin he ineger relaion, e. g., if he resul of 1+2 should be sored as a UML aribue value, he aom 3 mus be available.

6 420 M. Kuhlmann and M. Gogolla Real unary relaion Real of srucure [[r 1 ],...,[r nreal ]]. Example insance: [[3.14],[2.71],[1.23]]. The Real relaion is analogously defined o he ineger relaion, bu Real aoms canno be mapped o processable Real values in relaional logic. Thus, Real aoms do no have furher meaning excep for heir comparabiliy, e. g., we can infer ha [[3.14]] does no equal [[1.23]], bu we canno deermine heir precedence or apply Real operaions. Sring unary relaion Sring of srucure [[s 1 ],...,[s nsring ]]. Example insance: [[Ada],[Bob],[Apple],[IBM]]. Relaional logic does no direcly suppor Sring values wih an inner srucure, i. e., consising of sequences of characers. The inrinsic approach handles srings analogously o Real values. Undef unary relaion Undef=[[Undef]]. Primiive values may be undefined. Hence, we need a unary singleon relaion holding he undefined value. Classes and Enumeraions. Classes are ranslaed ino unary relaions wih variable insances; enumeraions yield unary relaions wih consan insances: Class c unary relaion c of srucure [[obj 1 ],...,[obj nc ]], where an aom obj i (wih 1 i n c ) represens an objec idenifier. Example ranslaion: Class Person Person. Example insance: [[ada],[bob],[cyd]]. Enum e={li 1,...,li ne } unary relaion e=[[li 1 ],...,[li ne ]]. Example ranslaion: Enum Colors={r,g,b} Colors=[[r],[g],[b]]. Associaions and Associaion Classes. The inrinsic ransformaion fully suppors n-ary associaions and associaion classes wih mulipliciies. An n-ary associaion has n associaion ends, where associaion end i (wih 1 i n) isof ype class c i, i. e., a navigaion o his end resuls in objecs of c i. For ranslaing associaions ino relaional logic we deermine a specific order of he associaion ends in such a way ha end i is mapped o uple posiion i. Hence, we obain he following ransformaion for n-ary associaions: n-ary Associaion a n-ary relaion a of srucure [[obj 11,...,obj 1n ],..., [obj m1,...,obj mn ]], whereobj ij describes he objec occurring in he ih link a he jh associaion end, plus yping and mulipliciy consrains. Example ranslaion: Associaion Hiring wih associaion end order: hiringe, hirede, company Hiring plus consrains shown below. Example insance: [[ada,bob,apple]]. n-ary associaions resul in n yping consrains requiring each associaion end, i. e., each uple posiion, o hold objecs of he relaed class, i. e., aoms of he respecive class relaion. The universe relaion univ provided by relaional logic including all exising aoms allows us o navigae o he desired uple posiions by cuing off he unneeded uple posiions. Consider he following yping consrains for associaion relaion Hiring: (Hiring.univ).univ in Person (univ.hiring).univ in Person univ.(univ.hiring) in Company he hiring employee (firs posiion) is a person he hired employee (second posiion) is a person a person is hired for a company (hird posiion)

7 From UML and OCL o Relaional Logic and Back 421 Furhermore, each associaion end yielding a consraining mulipliciy differing from 0..* resuls in a mulipliciy consrain. Consider for example he consrain for associaion end hiringe which demands ha each pair of objecs belonging o he opposie associaion ends hirede and company is conneced o a mos one objec of associaion end hiringe: all c2:person, c3:company #((Hiring.c3).c2)<=1 If he lower bound of a mulipliciy is greaer han 0, he consrain is exended accordingly. Generally we see ha he absence of a link is indicaed by he absence of a corresponding uple in he associaion relaion. In his way, he navigaion o an associaion end direcly resuls in se values. Objecs no linked o anoher objec do no occur in he se. If no objec is conneced, he navigaion resuls in an empy se. Binary associaions are an excepion o his rule if an associaion end is single-valued, i. e., if i yields he mulipliciy 1 or In his case, a navigaion o his end resuls in exacly one objec. Mulipliciy 0..1 allows his objec o be undefined. Thus, he absence of a link is expressed by uples having he Undef aom a he respecive posiion. Tha is, in conras o general associaion relaions he absence of a link is no indicaed by he absence of he respecive uple, bu by he explici occurrence of he undefined value: Binary associaion a binary relaion a of srucure [[obj 11,obj 12 ],..., [obj m1,obj m2 ]], whereobj ij may be undefined, if associaion end j yields mulipliciy 0..1, plus special relaional consrains for yping and mulipliciies. Example ranslaion: Associaion Job wih associaion end order: employee, employer (dismissing he grey associaion class par) Job. Example insance: [[ada,ibm],[bob,ibm],[cyd,undef]]. Consrains: Job.univ in Person he employee is a person univ.job in Company+Undef he employer is a defined company or undefined all c1:person #(c1.job)=1 a person is conneced o one aom via relaion Job all c2:company #(Job.c2)>=1 a company is conneced o a leas one person If we respec he grey par in Fig. 1, we obain an associaion class. Associaion classes yield wo relaions. One relaion represens he class perspecive following he same ranslaion rules as relaions for ordinary classes. In every respec, he class relaions of associaion classes can be handled like class relaions of ordinary classes. The relaion represening he associaion par is ranslaed analogously o ordinary associaions, excep for an addiional column a he firs uple posiion holding he paricipaing associaion class objecs: n-ary Associaion class ac unary relaion ac of srucure [[ac obj 1 ],..., [ac obj m ]], n+1-ary relaion ac assoc of srucure [[ac obj 1,obj 11,...,obj 1n ],...,[ac obj m,obj m1,...,obj mn ]], plus yping and mulipliciy consrains. Example ranslaion: Associaion class Job wih associaion end order: job (implici), employee, employer (respecing he grey par) Job, Job assoc. Example insance of Job: [[job1],[job2]]. Example insance of Job assoc: [[job1,ada,ibm],[job2,bob,ibm],[undef,cyd,undef]]. As ordinary associaion ends, associaion class ends are yped: (Job_assoc.univ).univ in Job+Undef

8 422 M. Kuhlmann and M. Gogolla Furhermore, he associaion class end requires wo mulipliciy consrains for ensuring ha (a) each permuaion of objecs corresponding o he opposie ends is conneced o a mos one associaion class objec, and (b) each associaion class objec is conneced o exacly one permuaion of defined objecs: (a) all c2:person, c3:company #((Job_assoc.c3).c2)<=1 (b) all c1:job #(c1.job_assoc)=1 && (c1.job_assoc) in (Person->Company) Analogously o binary associaions, binary associaion classes need a special handling if single-valued associaion ends are involved. In he case of an objecvalued associaion end like employer, he opposie end (i. e., employee in our example) is always relaed o one objec which may be undefined: (c) all c2:person #(c2.(univ.job_assoc))=1 In he case of se-valued associaion ends like employee wih mulipliciy 1..*, heopposieend(employer) is never linked o an undefined associaion class objec because, in his case, he navigaion o he associaion class end resuls in a se of objecs (i. e., one or more jobs in our example): (d) all c3:company!(undef in ((Job_assoc.c3).univ)) && #(Job_assoc.c3)>=1 Aribues. Independen from heir ypes, UML aribues are always ranslaed ino binary relaions. Aribue relaions relae objecs wih aribue values. If an aribue is no defined, he respecive objecs are relaed o he undefined value. In he case of se-valued aribues, we use he special aom Undef Se o indicae he absence of a defined se. This way, we can disinguish beween undefined se values (objec relaed o Undef Se), defined se values including he undefined value (objec relaed o Undef) and an empy ses (he corresponding objec does no paricipae in he aribue relaion insance). Regarding his deail, he ranslaion of aribues and binary associaions differ. Aribue Class::ar binary relaion Class ar of srucure [[obj 1, val 11 ],...,[obj 1,val 1n1 ],...,[obj m,val m1 ],...,[obj m,val mnm ]], wheren i is he number of aoms represening he aribue value relaed o obj i (1 i m), plus yping and mulipliciy consrains. Basic, objec and enumeraion ype aribues require n i =1foralli. Se ype aribues allow any posiive value including 0 for n i, also n i and n j (1 j m and i j) maydiffer. Example ranslaion: Aribue Person::name, Person:: Addrs, Job::salary Person name, Person addrs, Job salary. Example insance (Person name): [[ada,ada],[bob,bob],[cyd,undef]]. Example insance (Person addrs): [[ada,ada@apple.com],[ada,ada@gmail.com],[cyd,undef Se]]. Example insance (Job salary): [[job1,2000],[job2,1200]]. Aribue relaions are consrained by formulas for deermining he aribue domain, ype and mulipliciy. The aribue domain is always a class relaion. The undefined value is no involved a he domain side. However, he undefined value always paricipaes in he aribues ype definiion. Le us consider he consrains for he basic ype aribue relaion Person name:

9 From UML and OCL o Relaional Logic and Back 423 Person_name.univ in Person he domain is Person univ.person_name in Sring+Undef heypeissring including Undef all c:person #(c.person_name)=1 he aribue relaes a person o one aom Se-valued aribues yield differen consrains: Person_ Addrs.univ in Person he domain is Person univ.person_ addrs in heypeisaseofsring values in- Sring+Undef+Undef_Se cluding undefined values all c:person an undefined se is no accompanied Undef_Se in c.person_ addrs => by oher values #(c.person_ addrs)=1 3.2 From Relaional Insances o Class Diagram Insances In his secion, we consider he sraighforward backward ranslaion of a valid relaional model insance provided by Kodkod ino insances of UML class diagram conceps. We illusrae he ransformaion wih he help of insances of relaions resuling from he example class diagram shown in Fig. 1 including he grey associaion class par: Boolean=[[rue],[false]], Ineger=[[1000],[1100],[1200],[2000]], Sring=[[Ada],[Bob],[Apple],[IBM]], Undef=[[Undef]], Person=[[ada],[bob],[cyd]], Company=[[apple],[ibm]], Job=[[job1],[job2]], Hiring=[[ada,bob,apple]], Job assoc=[[job1,ada,apple],[job2,bob,apple],[undef,cyd,undef]], Person name=[[ada,ada],[bob,bob],[cyd,undef]], Person employable=[[ada,rue],[bob,rue],[cyd,false]], Person addrs=[[ada,ada@apple.com],[ada@gmail.com],[cyd,undef Se]], Company name=[[apple,apple],[ibm,ibm]], Job minsalary=[[apple,1000],[ibm,1100]], Job salary=[[job1,2000],[job2,1200]] These relaion insances direcly resul in he class diagram insance visualized in he objec diagram shown in Fig User-Defined Search Space Configuraion For searching valid insances of relaional models, Kodkod requires a resriced search space, i. e., a predeermined universe of aoms and bounds o he declared relaions. Upper bounds deermine he se of all possible uples for each relaion. Lower bounds, insead, declare ses of uples which mus occur in a valid insance, i. e., a parial soluion. A comforable way for specifying parial soluions is he ranslaion of a parial user-defined objec diagram ino he lower bounds of he concerned relaions. This forward ranslaion can be done analogously o he backward ranslaion illusraed in Sec Since he search space direcly influences he search efficiency of Kodkod, he aim is o minimize he upper bounds. Respecive opimizaions are in paricular possible in he conex of parial soluions, since he exisence of specific uples in

10 424 M. Kuhlmann and M. Gogolla Fig. 2. Translaion Resul from Relaion Insances o Class Diagram Insances he lower bounds ofen preclude he exisence of oher uples in a valid insance. Those uples can be removed from he upper bounds, e. g., if a parial soluion assigns he name Ada o objec ada, he upper bounds of relaion Person name can be filered wih respec o uples assigning oher names o his objec. The search space configuraion can be exended by relaional consrains which, for example, deermine he minimum and maximum numbers of defined links of a specific associaion, or aribue values of a specific aribue. Those properies canno be configured by bounds, as hey do no concern specific uples. An implemenaion of he considered ransformaion should provide means for easy configuraions while hiding he pariculariies of relaional logic, e. g., allowing he user o deermine he minimum and maximum number of objecs, forbidding specific links, or defining ranges of available aribue values. 3.4 From OCL Consrains o Relaional Consrains Class diagrams can be annoaed wih OCL invarians which consrain he se of valid class diagram insances. OCL invarians, represening Boolean OCL expressions, are ransformed ino relaional formulas. Addiionally, in our validaion approach user-defined validaion asks specifying properies he searched model insance mus fulfill are made available in form of emporary OCL consrains. In his secion, we consider he ranslaion of individual ineresing and imporan OCL operaions. The ransformaion of operaions no discussed in his secion can be inspeced in [13]. Boolean Operaions. The inrinsic ransformaion approach makes use of he wo-valued relaional logic. Consequenly, Boolean OCL expressions resul in relaional formulas, in conras o non-boolean OCL expressions which resul in relaional expressions, i. e., relaion insances. For example, consider he Boolean operaion xor which is he only Boolean operaion wih no direc counerpar in relaional logic:

11 From UML and OCL o Relaional Logic and Back 425 expr 1 xor expr 2 ( expr 1 &&! expr 2 ) (! expr 1 && expr 2 ), wih denoing he ransformaion resul of OCL expression e ino a relaional expression or formula, respecively. Since he Boolean values of relaional formulas canno be sored in relaions, we define wo relaional operaions (a) for mapping Boolean aoms (rue and false which can occur as Boolean aribue values or as Boolean lierals in OCL expressions) o relaional ruh values, and (b) for mapping relaional ruh values ino aomic values: (a) expr2formula(e):formula = e=[[rue]] (b) formula2expr(f):expression = f => [[rue]] else [[false]] e (if-hen-else) Operaion (a) reveals ha he hree-valued logic of OCL is encoded ino wovalued relaional logic by mapping he undefined value o he value false. This realizaion can influence he validiy of OCL invarians. Consider, for example, he OCL consrain expr 1 and expr 2 implies expr 3 which would evaluae o Undefined, and hus would be violaed, if expr 1 evaluaes o Undefined and he oher expressions o false. The corresponding relaional consrain, however, would be fulfilled. This disadvanage can be avoided by explicily reaing possible undefined values wihin a consrain, e. g., by applying explici case disincions and he OCL operaion oclisundefined. As a consequence, he modeler has o be aware of siuaions in which an OCL expression can be undefined (which is anyway a preferable modeling syle). Ineger, OclAny and Oher Operaions. Excep for he explici handling of he undefined value, ineger operaions are direcly ranslaed ino heir counerpars provided by relaional logic. OclAny operaions like equaliy, inequaliy or oclisundefined resul in Boolean values, hence, requiring he applicaion of he expression, formula mapping operaions discussed before. However, heir ransformaion is also sraighforward. The disinc operaions and saemens allinsances, le, if-hen-else, and he access of aribue values also yield plain relaional consrucs. For deails see [13]. Se Operaions. In he majoriy of cases, OCL se operaions like union, including, includes, forall or exiss can be direcly ransformed ino equivalen relaional logic expressions or formulas, respecively. In his subsecion, we consider he prominen se operaion collec which, on he one hand, is ofen used for comforably collecing specific (possibly calculaed) values, on he oher hand, is no handled in oher works on ranslaing OCL ino relaional logic. Furhermore, collec is implicily applied for navigaing a UML class diagram using he do shorcu which we will consider laer. src->collec(v body(v)) src=[[undef Se]] => [[Undef Se]] else rflaenundef(rcollec(v, src, body(v))), where body(v) represens an arbirary OCL expression in which variable v may occur, rflaenundef and rcollec are relaional operaions which we have

12 426 M. Kuhlmann and M. Gogolla defined for ransforming he OCL collec. The case disincion ensures ha an undefined source collecion (src) again resuls in an undefined collecion. The operaion rcollec requires hree argumens; a variable v, herans- laed source expression, and he ranslaed body expression in which v may occur. Firs, his operaion creaes a binary relaion via comprehension which relaes each elemen of he source collecion o he evaluaion resul of he respecive body expression. For insance, he OCL expression Se{1,2,3}->collec(i i*i) would yield he inermediae relaion [[1,1],[2,4],[3,9]]. The ransformaion respecs he fac ha he resul of collec mus be flaened. If he body expression, resuls in a se of values, each elemen of he source collecion is relaed o each elemen of his se via an individual uple, i. e., he resul is auomaically flaened. Afer ha, he firs uple posiion is cu off o obain he desired evaluaion resul, e. g., wih respec o he curren example [[1],[4],[9]]: rcollec(v, src, body (v)) = univ.{v: src, res: body (v) rue} The body of a collec expression can resul in collecion values which are implicily flaened in he conex of he OCL collec, e. g., he expression Se{Undefined,Se{1}}->collec(i i) evaluaes o Bag{Undefined,1} of ype Bag(Ineger), while he source collecion is of ype Se(Se(Ineger)). Thais, undefined se-valued body expressions evaluae o an undefined value in he flaened resul. For his reason, we need he operaion rflaenundef which checks if undefined collecions (expressed by he aom Undef Se) occur, and ransforms hem ino Undef represening undefined single-values: rflaenundef(e) = Undef Se in e => (e-undef Se)+Undef else e Please noe ha he relaional represenaion of collec always resuls in ses of values, while is OCL counerpar eiher resuls in bags or sequences, possibly yielding duplicae values and specific orders. The inrinsic approach hus resrics he expressiveness of collec. However, in many circumsances, no a specific order or he number of duplicae values is crucial, bu he collecion of disinc values. Le us consider his fac wih he help of wo concree OCL invarians based on he class diagram shown in Fig. 1: conex c:company inv MinimumSalaryMainained: c.job.salary->min() > c.minsalary inv HiringPersonEmployed: c.hiringe->noempy() implies c.hiringe.employer->asse()=se{c} The firs invarian ensures in he conex of a company he lowes paid job o yield a salary higher han he minimum salary deermined by he company. The expression c.job.salary implicily applies a collec via he do shorcu, collecing all salaries for each job. The aim is o obain he lowes salary. The number of employees yielding he lowes salary is irrelevan. The oher invarian ensures ha persons can only hire employees for heir own company. Again, he only purpose of expression c.hiringe.employer->asse is o collec he disinc employers of persons who hire for company c. Consequenly, despie he resricions, he inrinsical approach suppors a large variey of pracical models.

13 From UML and OCL o Relaional Logic and Back 427 Navigaion. Our ransformaion approach allows for navigaing arbirary reflexive and non-reflexive n-ary associaions and associaion classes. We consider he general OCL navigaion expression expr.role represening he navigaion via associaion assoc from he evaluaion resul of expr (which yields a defined or undefined objec), i. e., from associaion end i, oherole a associaion end j. For keeping he ranslaion clear, we inroduce he auxiliary operaions univ r and univ l which represen muliple applicaions of universe joins from he righ or he lef side, respecively: univ r(e,n)=if n>0 hen univ r(e, n 1).univ else e univ l(e,n)=if n>0 hen univ.univ l(e, n 1) else e Example: univ r(e, 3) = e.univ.univ.univ expr.role (via n-ary associaion assoc from associaion end i o end j) expr=[[undef]] => [[uv]] else if i<j hen univ r(univ l( expr.univ l(assoc,i 1),j i 1),n j) else univ l(univ r(univ r(assoc,n i). expr,i j 1),j 1), where uv is equal o Undef Se if associaion end j is se-valued, and uv is equal o Undef if end j is objec-valued. Le us consider some example navigaion expressions based on associaion Hiring and associaion class Job shown in Fig. 1: apple.hiringe (fromassociaionend3oend1) (Hiring.[[apple]]).univ. apple.hirede (fromend3oend2) univ.(hiring.[[apple]]). bob.company[hirede] 1 (from end 2 o end 3) [[bob]].(univ.hiring). ada.job (from end 2 o end 1) (Job assoc.univ).[[ada]] As we have menioned before, he do shorcu, i. e., an implici collec, provided by OCL allows us o easily collec objecs while navigaing hrough a class diagram, i. e., via more han associaion. Consider, for insance, he expression apple.hiringe.employer including an ordinary navigaion saring from an objec (apple), as well as an implici collec based on he navigaion resul which furher navigaes o associaion end employer. This shorcu expression is equivalen o apple.hiringe->collec(p p.employer). A (complee) ransformaion of his expression is shown a he end of his secion. Our ransformaion approach allows us o differeniae beween hree disincive cases which is required by OCL. (a) If expr wihin expr.hiringe.employer is undefined, he whole expression resuls in an undefined se. (b)ifexpr.hiringe resuls in a defined se including a leas one unemployed person, he whole shorcu expression resuls in a se including he undefined value. (c)ifexpr.hiringe resuls in an empy se, he whole expression resuls in an empy se. These meaningful cases canno be expressed by approaches like [1] due o language resricions wih respec o Alloy. 1 Since he associaion is reflexive, i. e., persons can paricipae in Hiring links in differen roles, he associaion end from which he navigaion sars mus be deermined wihin brackes if ambiguous.

14 428 M. Kuhlmann and M. Gogolla rflaenundef(rcollec(p, apple.hiringe, p.employer)) = apple.hiringe =[[Undef Se]] => [[Undef Se]] else (Undef Se in univ.{p: apple.hiringe, res: p.employer rue} => ((univ.{p: apple.hiringe, res: p.employer rue})-undef Se)+Undef else univ.{p: apple.hiringe, res: p.employer rue}), wih apple.hiringe = [[apple]]=[[undef]] => [[Undef Se]] else (Hiring.[[apple]]).univ, and p.employer = p=[[undef]] => [[Undef]] else p.(univ.job assoc) 4 Relaed Work While here are many imporan approaches in he field of UML and OCL model validaion, in paricular for informaion sysem validaion [20], here is currenly only one work following our approach o direcly ranslaing UML models ino pure relaional models [27]. The approach focuses on auomaic resoluion of model inconsisencies by ranslaing basic class diagram conceps ino relaions and formulas. OCL as a whole and imporan UML feaures like n-ary associaions, associaion classes, and undefined values have no ye been explicily concerned. OCLexec [12,11] makes use of Kodkod in order o generae Java mehod bodies by animaing OCL operaions consrained by OCL poscondiions and invarians. In his approach, OCL expressions are ranslaed ino arihmeic expressions wih bounded quanifiers and uninerpreed funcions, i. e., pure ineger expressions. The efficien mechanisms of Kodkod [28] are applied o ransform hose expressions ino SAT problems. However, his approach has a loose connecion o our work, since he auhors of OCLexec do no make use of higher-level feaures of Kodkod such as encoding of relaions. Thus, our ransformaion of UML and OCL conceps ino relaions and relaional formulas is fundamenally differen from he ransformaion resul of OCLexec. Our work is relaed o approaches which ranslae UML and OCL ino he specificaion language Alloy [10] which is also based on relaional logic. The so-called Alloy Analyzer ransforms Alloy specificaions ino relaional models suppored by Kodkod. However, he modeling conceps provided by Alloy, e. g., signaures and fields, purposefully resric he srucure of specificaion componens. Tha is, on he one hand, srucures of Alloy specificaions resul in specific relaional srucures, bu, on he oher hand, no all relaional srucures suppored by Kodkod can be modeled wih Alloy. Consequenly, several aspecs of UML and OCL like he adequae handling of undefined values are no suppored by Alloy, and hus are no direcly realizable by approaches like UML2Alloy [1].

15 From UML and OCL o Relaional Logic and Back 429 While UML2Alloy is an elaboraed ool for validaing UML and OCL models, i does no handle UML conceps like n-ary associaions and associaion classes, or OCL operaions like collec. The auhors of CD2Alloy [18] pursue a deep embedding by defining class diagram consrucs as new conceps wihin Alloy, enabling, for example, he comparison of wo class diagrams. The work discussed in [19] aims o check he consisency beween class and objec diagrams by explicily modeling objec diagram conceps in Alloy. A backward ransformaion from original Alloy specificaions ino UML and OCL models is presened in [8]. The auhors in [4] ranslae concepual models described in OnoUML for validaion purposes ino Alloy. Kodkod has been successfully applied in differen fields, e. g., for execuing declaraive specificaions in case of runime excepions in Java programs [25], reasoning abou memory models [29], or generaing counerexamples for Isabelle/HOL a proof assisan for higher-order logic (Nipick) [3]. There are many oher works concerning he validaion of UML and OCL models which do no base on Alloy or Kodkod. For insance, a direc ranslaion of UML and OCL conceps ino SAT has been addressed in [26]. However, a direc ranslaion canno benefi from exising ranslaion mechanisms like he sophisicaed symmery deecion and breaking scheme which enables an efficien handling of parial soluions, or he deecion and exploiaion of redundan srucures in formulas which are implemened in Kodkod. A ranslaion of specific UML and OCL feaures ino consrain saisfacion problems (CSP) is done in [6]. Answer se programming (ASP) [21], he consrucive query conainmen (CQC) mehod [22], or rewriing-based echniques [23,7] are applied for analyzing saic and dynamic model aspecs. The named approaches differ from more ineracive approaches like [5] involving verificaion by heorem proving. 5 Conclusion In his paper we have presened he deails of a bidirecional ransformaion from UML and OCL ino relaional logic and back, while focussing on he essenial conceps of UML models and cenral OCL operaions. Our so-called inrinsic approach implies resricions a he UML and OCL side, bu, on he one hand, enables he direc use of relaional consrucs, and, on he oher hand, does sill suppor a large variey of pracically useful models. Fuure work will comprise he finalizaion of our exrinsic approach which has been developed parallel o he curren inrinsic approach. We will discuss a deailed comparison of (a) he inrinsic and exrinsic approach, and (b) our approaches and oher relaional and non-relaional UML and OCL model validaion approaches. A comparison will consider he suppored UML and OCL feaures based on he OCL benchmark [16] as well as he efficiency wih respec o models of differen scale and purpose. Furhermore, he ransformaion will be exended regarding dynamic aspecs, e. g., involving OCL pre- and poscondiions, UML sae machines, and sequence diagrams, and he mechanisms for specifying and opimizing he search space of model insances will be consolidaed.

16 430 M. Kuhlmann and M. Gogolla References 1. Anasasakis, K., Bordbar, B., Georg, G., Ray, I.: On challenges of model ransformaion from UML o Alloy. Sofware and Sysem Modeling 9(1), (2010) 2. Biere, A., Heule, M., van Maaren, H., Walsh, T. (eds.): Handbook of Saisfiabiliy, Froniers in Arificial Inelligence and Applicaions, vol IOS Press (2009) 3. Blanchee, J.C., Nipkow, T.: Nipick: A Counerexample Generaor for Higher- Order Logic Based on a Relaional Model Finder. In: Kaufmann, M., Paulson, L.C. (eds.) ITP LNCS, vol. 6172, pp Springer, Heidelberg (2010) 4. Braga, B.F.B., Almeida, J.P.A., Guizzardi, G., Benevides, A.B.: Transforming OnoUML ino Alloy: owards concepual model validaion using a lighweigh formal mehod. ISSE 6(1-2), (2010) 5. Brucker, A.D., Wolff, B.: HOL-OCL: A Formal Proof Environmen for uml/ocl. In: Fiadeiro, J.L., Inverardi, P. (eds.) FASE LNCS, vol. 4961, pp Springer, Heidelberg (2008) 6. Cabo, J., Clariso, R., Riera, D.: Verificaion of UML/OCL Class Diagrams using Consrain Programming. In: IEEE Inernaional Conference on Sofware Tesing Verificaion and Validaion Workshop, ICSTW 2008, pp (April 2008) 7. Clavel, M., Egea, M.: ITP/OCL: A Rewriing-Based Validaion Tool for UML+OCL Saic Class Diagrams. In: Johnson, M., Vene, V. (eds.) AMAST LNCS, vol. 4019, pp Springer, Heidelberg (2006) 8. Garis, A.G., Cunha, A., Riesco, D.: Translaing Alloy Specificaions o UML Class Diagrams Annoaed wih OCL. In: Barhe, G., Pardo, A., Schneider, G. (eds.) SEFM LNCS, vol. 7041, pp Springer, Heidelberg (2011) 9. Gogolla, M., Büner, F., Richers, M.: USE: A UML-based specificaion environmen for validaing UML and OCL. Sci. Compu. Program. 69(1-3), (2007) 10. Jackson, D.: Sofware Absracions - Logic, Language, and Analysis. MIT Press (2006) 11. Krieger, M.P., Brucker, A.D.: Exending OCL Operaion Conracs wih Objecive Funcions. ECEASST 44 (2011) 12. Krieger, M.P., Knapp, A.: Execuing Underspecified OCL Operaion Conracs wih a SAT Solver. ECEASST 15 (2008) 13. Kuhlmann, M., Gogolla, M.: Inrinsic Relaional Approach: Transformaion of OCL Operaions, hp:// inern/inrinsicapproachocl2012.pdf 14. Kuhlmann, M., Gogolla, M.: Srenghening SAT-Based Validaion of UML/OCL Models by Represening Collecions as Relaions. In: Tolvanen, J.P., Vallecillo, A. (eds.) ECMFA LNCS, vol. 7349, pp Springer, Heidelberg (2012) 15. Kuhlmann, M., Hamann, L., Gogolla, M.: Exensive Validaion of OCL Models by Inegraing SAT Solving ino USE. In: Bishop, J., Vallecillo, A. (eds.) TOOLS LNCS, vol. 6705, pp Springer, Heidelberg (2011) 16. Kuhlmann, M., Hamann, L., Gogolla, M., Büner, F.: A benchmark for OCL engine accuracy, deerminaeness, and efficiency. Sofware and Sysem Modeling 11(2), (2012) 17. Kuhlmann, M., Sohr, K., Gogolla, M.: Comprehensive Two-Level Analysis of Saic and Dynamic RBAC Consrains wih UML and OCL. In: Baik, J., Massacci, F., Zulkernine, M. (eds.) SSIRI 2011, pp IEEE (2011) 18. Maoz, S., Ringer, J.O., Rumpe, B.: CD2Alloy: Class Diagrams Analysis Using Alloy Revisied. In: While, J., Clark, T., Kühne, T. (eds.) MODELS LNCS, vol. 6981, pp Springer, Heidelberg (2011)

17 From UML and OCL o Relaional Logic and Back Maoz, S., Ringer, J.O., Rumpe, B.: Semanically Configurable Consisency Analysis for Class and Objec Diagrams. In: While, J., Clark, T., Kühne, T. (eds.) MODELS LNCS, vol. 6981, pp Springer, Heidelberg (2011) 20. Olivé, A.: Concepual Modeling of Informaion Sysems. Springer (2007) 21. Ornaghi, M., Fiorenini, C., Momigliano, A., Pagano, F.: Applying ASP o UML Model Validaion. In: Erdem, E., Lin, F., Schaub, T. (eds.) LPNMR LNCS, vol. 5753, pp Springer, Heidelberg (2009) 22. Queral, A., Teniene, E.: Reasoning on UML Class Diagrams wih OCL Consrains. In: Embley, D.W., Olivé, A., Ram, S. (eds.) ER LNCS, vol. 4215, pp Springer, Heidelberg (2006) 23. Roldán, M., Durán, F.: Dynamic Validaion of OCL Consrains wih modcl. ECEASST 44 (2011) 24. Rumbaugh, J., Jacobson, I., Booch, G.: Unified Modeling Language Reference Manual, 2nd edn. The Pearson Higher Educaion (2004) 25. Samimi, H., Aung, E.D., Millsein, T.D.: Falling Back on Execuable Specificaions. In: D Hond, T. (ed.) ECOOP LNCS, vol. 6183, pp Springer, Heidelberg (2010) 26. Soeken, M., Wille, R., Kuhlmann, M., Gogolla, M., Drechsler, R.: Verifying UML/OCL models using Boolean saisfiabiliy. In: DATE, pp IEEE (2010) 27. Sraeen, R.V.D., Puissan, J.P., Mens, T.: Assessing he Kodkod Model Finder for Resolving Model Inconsisencies. In: France, R.B., Küser, J.M., Bordbar, B., Paige, R.F. (eds.) ECMFA LNCS, vol. 6698, pp Springer, Heidelberg (2011) 28. Torlak, E., Jackson, D.: Kodkod: A Relaional Model Finder. In: Grumberg, O., Huh, M. (eds.) TACAS LNCS, vol. 4424, pp Springer, Heidelberg (2007) 29. Torlak, E., Vaziri, M., Dolby, J.: MemSAT: checking axiomaic specificaions of memory models. In: Zorn, B.G., Aiken, A. (eds.) PLDI, pp ACM (2010) 30. Warmer, J., Kleppe, A.: The Objec Consrain Language: Geing Your Models Ready for MDA. The Addison-Wesley Objec Technology Series. Addison-Wesley (2003)