Composition of UML Described Refactoring Rules *

Transcription

1 Composton of UML Descrbed Refactorng Rules * Slavsa Markovc Swss Federal Insttute of Technology Department of Computer Scence Software Engneerng Laboratory 05 Lausanne-EPFL Swtzerland e-mal: Slavsa.Markovc@epfl.ch Abstract. Refactorngs resent a powerful approach for mprovng the qualty of software systems. A refactorng can be seen as a specal knd of behavor servng model formaton. The Object Constrant Language (OCL) together wth the metamodel of Unfed Modelng Language (UML) can be used for defnng rules for refactorng UML models. Ths paper nvestgates descrptons of refactorng rules that can be checked, reused and composed. The man contrbuton of ths paper s an algorthm to compute the descrpton of sequentally composed formatons. Ths allows one to check f a sequence of formatons s successfully applcable for a gven model before the formatons are executed on t. Furthermore, t facltates the analyss of the effects of formaton chan and ts usage n other compostons Introducton Model formatons are the core of Model Drven Archtecture (MDA) approach [0]. There exst several classfcatons of model formatons lke classfcaton on exomorphc, endomorphc and creatonal formatons []. Exomorphc formaton s a specal type of formaton that nvolves models from dfferent levels of abstracton. On the contrary to exomorphc formaton, endomorphc formaton deals wth models that are resented at the same level of abstracton and where source and target models are nstances of the same metamodel. Usages of endomorphc formatons are numerous. Typcal examples of ths knd of formaton are refactorngs [,, ]. For the descrpton of model formatons we wll use the Object Constrant Language [8] that would replace, possbly vague and ambguous, natural language descrpton. In ths paper, we wll address the problem of composng endomorphc model formatons n the context of ther applcaton to UML models [7]. Namely, the am s to have a method that wll allow us to specfy a formaton, analyze that formaton, evaluate a sequence of formatons or compose together descrptons of dfferent formatons. Ths wll leave us wth the possblty to decde n * Ths paper has been supported by Swss Natonal Scentfc Research Fund under the reference number

2 advance f t s meanngful or safe to perform a certan sequence of formatons or not. We offer some examples n ths paper that show the composton of several formaton descrptons, wth the goal of creatng more elaborated formaton descrptons. Ths paper s composed as follows: secton contans detals about the concepts used n ths approach and gves some examples of formaton descrptons appled on refactorng rules. In secton, the approach for composton of formatons s sented. Sectons 4 and 5 are reserved for related work and conclusons, respectvely. Refactorng Refactorng can be seen as a process of mprovng structure of a software system wthout changng ts behavor. In other words t means that for the same nput the refactored software system has to produce the same output as before. Ths behavor servaton s assured by so called condtons and condtons. Precondtons have to be fulflled before some refactorng s executed, and condtons resent descrpton of effects of one refactorng In ths paper we show that OCL constrants can be used to descrbe these and condtons. In the past, as descrbed n [], the process of refactorng was based on code-tocode formaton. Today, thanks to UML, we can rase the level of abstracton by refactorng UML models nstead of mplementaton code. Because of ths model change, whch appears after applyng refactorng, we can observe refactorng as just one type of model formaton. Ths type of model formatons, where the formaton wll be executed only f the condton s met, s called Condtonal Transformaton n [0]. Our man emphass s on the and condtons that have to be satsfed n order to refactor some UML model. Applyng OCL assertons on nstances of the UML metamodel (.e., model elements) s possble to defne these constrants. The two followng sub-sectons contan examples of OCL descrptons of formatons that resent two refactorng rules. The frst one, Abstracton, creates a new abstract superclass for some exstng class. The second one creates a new nterface for some exstng class.. Descrpton of the Abstracton Transformaton Ths formaton s used to create a new abstract class that wll be connected wth a generalzaton lnk to the exstng class, e.g. t creates a new parent of the exstng class. The condton of the descrpton assures that before executng the formaton there s a class n the system wth the same name as the parameter product but there s no class wth the same name as the parameter absproduct. The condton of the descrpton assures that after executon of the formaton a new abstract class wth the same name as the parameter absproduct s created and that there exsts a generalzaton lnk between the new and ntal class.

3 The condton s based on frame assumpton that means that anythng that s not mentoned has not been changed durng the formaton. Example of states that resent ths refactorng are shown on fgure. The upper and lower parts of fgure resent the same system state but usng dfferent syntax. The upper part descrbes one system state usng UML model elements, and the lower one descrbes the same system state usng nstances of metemodel elements. The OCL constrants are specfed on the metamodel level. The relevant part of the UML metamodel s shown on fgure. context Package def: classes: Set(Class) self.ownedclassfer->select(oclistypeof(class))->collect(c c.oclastype(class)) def: generalzatons: Set(Generalzaton) self.ownedclassfer->collect(generalzaton) def: nterfaces: Set(Interfaces::Interface) self.ownedclassfer->select(oclistypeof(interfaces::interface)) ->collect(c c.oclastype(interfaces::interface)) context Package::abstracton (product:strng, absproduct:strng) : classes->exsts(name product) and not classes->exsts(name absproduct) not nterfaces->exsts(name absproduct) : let: absprod:classclasses->select(nameabsproduct)->any(true) n let: gen:generalzatongeneralzatons->select(g g.specfc.name product and g.general.name absproduct)->any(true) n absprod.sabstracttrue and absprod.oclisnew() and gen.oclisnew() AbsProduct Product Product :C las s name'product' :C las s specfc name'product' generalzaton :G en eralzaton :C las s name'absproduct' s A bs tracttrue general Fg.. Example of the Abstracton refactorng

4 NamedElement name : Strng... Package +package 0.. +nestedpackage * +package 0.. Namespace +ownedclassfer * Classfer sabstract : Boolean false +general Generalzaton +specfc +generalzaton ssubsttutable : Bo... * Class Fg.. The relevant part of the UML.0 metamodel for the Abstracton refactorng. Descrpton of the Interface Extracton Transformaton The Interface Extracton formaton s used to add an nterface to a class. Ths enables another class to take a more abstract vew of a class by accessng t nstead, va an nterface. By the condton of the descrpton we assert that there exsts a class on whch we want to apply ths formaton and that there does not exst nether a class nor an nterface wth name creatorinf. The condton of the descrpton ensures that, after executon of the formaton, a new nterface s created wth the same name as creatorinf parameter, and that there exsts one mplementaton relaton between ths nterface and the class whose name we pass as a parameter creator. Furthermore, the condton ensures that all publc operatons from the class must exst n the nterface. In ths exsson we have borrowed hassamesgnature from UML.5 [5] that does not exst n the UML.0. Ths formaton s descrbed n the followng way usng OCL constrants appled on the nstances of the UML metamodel. context Package def: mplementatons:set(interfaces::implementaton) self.ownedclassfer->collect(mplementaton) context Package::nterfaceExtracton (creator:strng, creatorinf:strng) : classes->exsts(name creator) and not classes-> exsts(name creatorinf) and not nterfaces-> exsts(name creatorinf)

5 : let: creatinf:interfacenterfaces->select(namecreatorinf)->any(true) n let: mp:implementatonmplemenatons-> select(:implementaton.lementatngclassfer.name creator and.contract.name creatorinf)->any(true) n let: creat:classclasses->select(namecreator)->any(true) n creatinf.oclisnew() and mp.oclisnew and creat->collect(operaton)->select(vsbltyvsbltyknd::publc)-> forall(o:operaton creatinf->collect(operaton)-> exsts(o:operaton o.hassamesgnature(o))) and creatinf->collect(operaton)->forall(c:operaton c.oclisnew()) Fgure shows one possble state that satsfes the condton of the Interface Extracton formaton. CreatorInf Creator Creator :C las s nam e'creator' :C las s m plementatngclassfer nam e'creator' mplem entaton :Im p lem en ta ton :In terfac e nam e'creatorinf' contract Fg.. Example of Interface Extracton refactorng Fgure 4 shows the relevant part of UML.0 metamodel on whch the OCL exssons from and condtons of Interface Extracton are specfed.

6 NamedElement name : Strng... Namespace +ownedclassfer Package +package 0.. +package +nestedpackage * 0.. * +class +ownedoperaton Operaton Classfer 0.. sabstract : Boolean false * * +ownedoperaton 0.. Interface Interfaces) +contract * (from Class BehavoredClassfer +mplementaton Implementaton (from Interfaces) +mplementatngclassfer * Fg. 4. The relevant part of the UML.0 metamodel for the Abstracton refactorng Composton of Refactorngs. Why Composng Refactorngs? Refactorngs as they are sented n well known catalogs lke [] or [] resent only basc formatons that can only be used n some specfc stuatons. Furthermore, tools lke [4] that support these basc refactorngs do not let users to create ther own refactorngs, from scratch or by composng exstng refactorngs nto new ones. The composton of refactorngs would allow users of the tool to create ther own complex refactorngs that fulfll ther specfc needs. Of course, the new refactorng created n ths way could be combned wth others n order to create new ones, and so on. The problem wth composng refactorngs that are gven as the formatons of exstng code or models s that f t s not possble to execute one component formaton we have to nvoke a knd of roll-back mechansm that wll restore the system n the vous state; t may even be necessary to rollback several steps. By not dealng wth concrete formatons but only wth ther specfcatons, t s possble to avod ths knd of problem. Namely, the condtons and condtons of one composed formaton could be calculated before the formaton s executed so t would be possble to know n advance f one composton of formatons s legal and f t fulflls our needs. Furthermore, t s easer to analyze composed refactorngs f they are resented by one - par.. Prncples of Composng Whenever we want to make a formaton that s composed of several formatons we have to deal wth as many and condtons as we have formatons. The queston that arses s how to calculate the overall and condtons that we can use for the whole chan of small formatons.

7 Fgure 5 shows one formaton that conssts of three sub-formatons. As we have already stated each formaton has ts own and condton gven by two OCL exssons. One approach for applyng ths sequence s to evaluate the and exssons for each step (.e., each formaton) n the gven sequence on ther own system states. A better approach would be to calculate one and one condton for the whole sequence. Ths problem s solved by calculatng and condton for a chan of length. Iteratve addtons of the next formaton and condtons wll lead us to composte condtons for the chan of any length. At a frst glance, one mght guess that two formatons can be composed smply by composng the condtons usng the AND operator and composng the condtons usng AND as well. In some cases ths s correct but ths would not always lead to the legal chan of formaton descrptons. Ths s because each of the condtons s evaluated on ts specfc system state n some pont of tme. Our task now s to project condton of ntermedate state to condton of the ntal state. Here, the semantcs of the frst formaton has to be taken nto account. Obvously, f the condton of the ntermedate state s a logcal consequence from the condton of the frst formaton then nothng has to be added to the condton of the ntal state. T T T... T T T T T T composte - composte - composte - composte - Fg. 5. Composte formaton Fgure 6 shows relaton between two formatons. Each condton s evaluated on ts own system state that can be dfferent from other system states. Also, each condton s evaluated on the separate system state but on the contrary to condtons, each condton can be dependent on some part of the vous state. Ths dependency on the vous system state s realzed operator n OCL. On fgure 6, ths knd of dependency s resented wth the dashed lnes. Transformatoncomposte Transformaton Transformaton composte composte State State State Fg. 6. Dependences between two formatons Before we proceed wth the composton of formaton descrptons we have to perform a knd of -processng of descrptons by markng all varables dependant on ther system states on the followng way:

8 : V V : V V + : V@ V () In order to provde more cse descrpton of formaton composton we ntroduce the followng notaton: Χ set of all varables that exst n some system state X, X X set of all varables n ntal, ntermedate and fnal system state, ( X ) { true, false} a condton of the -th formaton that s evaluated on the state X ( X, X ) a { true, false} + condton of the -th formaton that s evaluated on the states X and X + ( X, X +) descrpton of a formaton that forms one system state to system state + PRE( X) a { true, false} composte condton that s evaluated on ntal system state POST ( X, X ) a { true, false} composte condton that s evaluated on the states X and X TRANS ( X, X ) descrpton of composte formaton that forms ntal system state to system state Now we can resent each formaton descrpton lke: ( X X ) ( X ) ( X X ), +, + () Usng ths notaton, two formatons from fgure 6 can be resented as followng: ( X, X ) ( X ) ( X X ), ( X, X ) ( X ) ( X X ), The process of fndng composed formaton descrpton can be formulated lke: calculatng and condton for a formaton that forms one system from state X to state X. Gven wth our notaton, composte formaton can be resented lke: TRANS Or n other words: ( X, X ) PRE( X ) POST ( X X ), () (4)

9 ( X ) POST( X, X) X ( X) ( X, X ) ( X ) ( X, X) We can calculate composte condton PRE ( X ) usng the followng formula: PRE (5) PRE ( X ) X ( X ) ( X X ) ( ) (6), X On the smlar way we can calculate the composte condton by usng the followng formula: PRE ( X ) POST ( X, X ) ( X ) X ( X, X ) ( X X ) (7), The frst condton for our chan of refactorngs to be legal s that every condton must evaluate to true on ts own system state. eval [ ( X )] true If ths condton s not satsfed then we have one llegal component formaton and we can conclude that our whole chan s llegal. The second condton that must be satsfed s that f the condton of the frst formaton descrpton evaluates to true then the condton of the second formaton descrpton must also evaluate to true: [ ( X, X )] true eval [ ( X )] true f eval then [ ( X, X ) mples ( X )] true eval Before we contnue wth composng OCL statements we are oblged to perform a sort of analyss. Ths s analyss of consstency between condton of the frst and condton of the second formaton descrpton. Wth ths step we detect all cases n whch after completon of the frst formaton we cannot contnue wth the second formaton due to ts unsatsfed condton. Durng ths analyss of legalty of a chan of formatons three cases can be detected: The chan s legal The chan s llegal but t can be formed nto a legal one The chan s llegal but t can not be formed nto a legal one The three followng subsectons contan three smple examples that descrbe these three possble cases. (8) (9)

10 Example. In ths subsecton we gve an example of one legal chan of two formatons. These two formatons are shown n Table. Table. Example of two formatons before -processng x > x x@ + x > x 5 y y y@ y y@ After the -processng usng () we have the followng and condtons lke shown n Table. Table. Example of one legal chan of two formatons x > x x + x > x 5 y y y y y Now, by observng values of condton of and condton of for varables of system state we can conclude that sequence of formatons {, } s legal because after solvng the equaton from the condton of, we have stuaton that x > 4 n and x > n whch depcts a set of correct system states. In other words, any value that satsfes also satsfes, whch means that the condton () s satsfed. For example gven n Table, usng (6) we have calculated the composte condton descrbed wth the followng exsson: ({ x, y} ) x y x > x x + x > y y y PRE (0) After the frst step of smplfcaton we get: ({ x y }) x > x > y PRE () And n the next step of smplfcaton:, ({ x y }) x > y PRE (), One remark s that durng the process of calculatng the composte condton, we are always lookng for the weakest soluton among all condtons that solve the condton (). Usng formula (7) we can calculate the composte condton. For our example from Table we have that:

11 PRE x y ({ x, y }) POST ({ x, y, x, y }) x > y () x So after smplfcaton we get: x + y y x ({ x y, x, y }) x 5 y, 5 y POST (4) y Example. In ths subsecton we gve an example of one llegal chan of two formatons that can be formed nto a legal one. Two formatons that buld ths chan are shown n Table. The only dfference from example s that now the condton of the second formaton s x 0. Table. Example of an llegal chan that can be formed nto a legal one x > x x + x > 0 x 5 y y y y y By observng values of condton of and condton of for varables of system state we can conclude that ths sequence of formatons s not legal because after solvng the equaton from the condton of, we have stuaton that x > 4 n and x > 0 n. Ths means that there can exst system states that satsfy the condton of the frst formaton but don t satsfy the condton of the second one,.e. there can exst some system states that do not satsfy (). If we want to compute composte condton for example from Table we follow the same algorthm lke we dd for example from Table. After the frst step of smplfcaton we have the followng stuaton: > ({ x y }) x > x > 8 y PRE (5), Further smplfcaton of ths exsson yelds the followng: ({ x y }) x > 8 y PRE (6), Ths means that f we want to have legal composte formaton descrpton we have to make composte condton stronger than condton of the frst formaton descrpton. The composte condton wll be the same as (4) because the change on the condton of the second formaton does not make any nfluence on t.

12 Example. In ths subsecton we gve an example of one llegal chan of two formatons that can not be formed nto a legal one. Two formatons that buld ths chan are shown n Table 4. The only dfference from example s that now the condton of the second formaton s x 4. Table 4. Example of an llegal chan that can not be formed nto a legal one x > x x + x < 4 x 5 y y y y y By observng values of condton of and condton of for varables of system state we can conclude that ths sequence of formatons s not legal because after solvng the equaton from the condton of, we have stuaton that x > 4 n and x < 4 n. Ths means that set of system states that satsfes both and condton s empty. If we try to compute the composte condton usng (7) we wll get the followng: < ({ x y }) x < 4 x > 4 y PRE (7), Ths means that t s not possble to fnd the composte condton for ths chan,.e. the chan s llegal.. Example of a Composed Refactorng Rule By analyzng our two refactorng examples from secton, we can conclude that composed formaton descrpton wll look lke the followng: context Package::composed (product:strng, absproduct:strng, creator:strng, creatorinf:strng) : classes->exsts(name product) and not classes->exsts(name absproduct) and not nterfaces-> exsts(name absproduct) classes->exsts(name creator) and not classes-> exsts(name creatorinf) and not nterfaces-> exsts(name creatorinf) and not absproductcreatorinf : let: absprod:classclasses->select(nameabsproduct)->any(true) n let: gen:generalzatongeneralzatons->select(g g.specfc.name product and g.general.name absproduct)->any(true) n

13 let: creatinf:interfacenterfaces->select(namecreatorinf)->any(true) n let: mp:implementatonmplemenatons-> select(:implementaton.lementatngclassfer.name creator and.contract.name creatorinf)->any(true) n let: creat:classclasses->select(namecreator)->any(true) n absprod.sabstracttrue and absprod.oclisnew() and gen.oclisnew() and creatinf.oclisnew() and mp.oclisnew and creat->collect(operaton)->select(vsbltyvsbltyknd::publc)-> forall(o:operaton creatinf->collect(operaton)-> exsts(o:operaton o.hassamesgnature(o))) and creatinf->collect(operaton)->forall(c:operaton c.oclisnew()).4 Lmtatons of the Approach One can notce that n our approach we use only a lmted set of OCL exssons n condtons n order to be able to evaluate unque new system state from the ntal one. Ths means that we do not use exssons wth, for the example < or > operators. In other words, we are usng only those OCL exssons that can be evaluated to true only on one system state. Usng the full set of OCL exssons can be seen as superfluous because the future system state n whch we want to brng our system s csely defned so operatons that can evaluate to true on several system states have to be avoded. Also, OCL s clumsy when we do not use the frame assumpton but have to wrte full versons of or condtons. Stll there s a hope that ths process of extractng full verson of OCL constrants out of verson that s based on the frame assumpton could be automated. Current lmtaton of our approach s that we can descrbe only formatons whose source and target models are nstances of the same metamodel lke the refactorng rules. 4 Related Work In hs PhD thess [], Opdyke resents refactorngs as combnatons of condtons whose purpose s the servaton of behavor of a program that s to be refactored and actual refactorng steps that are descrbed usng natural language. These condtons have to serve seven basc propertes of each program that are usually volated durng refactorng process. Also, ths work contans certan prncples of composton of refactorngs. The emphass s on the composton of prmtve condtons n order to keep behavor served. In [], Roberts ntroduces condtons nto the refactorng process; they are used n the composton of condtons for the chan of refactorngs. Before composng

14 condtons, Roberts frst forms them accordng to the vous refactorngs n the chan, by usng the condtons. Besdes the problem of composton, he dscusses the problems of commutatvty and dependences between refactorngs. He extends the approach of Opdyke by formalzng refactorngs usng frst-order dcate logc. Smlarly to ths approach, we also use condtons n order to calculate cumulatve condton of a refactorng chan. In hs thess [5], Ó Cnnedé uses the approach of Roberts n order to compose refactorngs related to desgn patterns. Besdes the composton of condtons, he ntroduces the concept of composton of condtons. He uses ths approach for manually calculatng desgn patterns seen as a chan of prmtve refactorngs. Sunyé et al. [4] use a very smlar approach to our one for resentng refactorngs. They descrbe refactorngs usng OCL exssons appled to the metamodel of UML. A dfference of our approach wth thers s that we localze all formatons on the level of one package assumng that, for the sake of smplcty, all refactorngs are done locally n the package. Ther refactorngs are defned on the model elements that are nfluenced by the specfc refactorng. In [], Sunyé et al. extend OCL wth so called actons whch are used to descrbe the formatons as the thrd component of refactorng, besdes and condtons. Composton of refactorngs s not dscussed n ths work. Due to the lack of Acton Semantcs n UML.4 specfcaton, Van Gorp et al. [6] propose ther own UML extenson for the support of refactorngs. OCL exssons are appled on the UML.4 extended metamodel. They defne OCL and condtons as the separate functons ntroduced wth the OCL def-let mechansm. Ths approach lacks of the possblty to use operator nsde of condtons. Knesel and Koch [] gve a cse defnton of refactorngs composton and descrbe an automatc approach of composng refactorngs that are gven wth ther condton and formaton descrpton. Ther noton of formaton descrpton s dfferent from ours, because they use ths term as a functon that forms condtons to reflect the real formatons. Our formaton descrptons nclude necessary and condtons whch descrbe each formaton. Ther approach for composton of refactorngs s dfferent to ours because they start composng from the last formaton whle we start from the frst one. 5 Concluson Ths work tackles the problems of composng endomorphc model formatons lke refactorngs. The am was to provde an approach for valdatng the sequence of these formatons and to fnd the way of composng these formatons n order to get more complcated formatons that can be appled or used n further compostons. On the contrary to work of some authors where a new metamodel s created n order to facltate usage of OCL exssons, we use the full UML. Despte all ts drawbacks, OCL n ths approach provdes an elegant way of descrbng model formatons and compostons of formatons. Unfortunately, by usng OCL condtons lke n our approach we can deal only wth the models that resent nstances of the same metamodel. Our wsh s to further develop our method n order

15 to be able to deal not only wth endomorphc formatons but wth any knd of formaton. The future steps wll nvolve the creaton of a lbrary of mn formaton descrptons n order to get some foundatons for descrbng more complcated refactorngs or desgn patterns. Our ntenton s to create the tool that would be able to automatcally calculate dependences and msmatchng between mn-formatons descrptons and to be able to generate a composte formaton descrpton out of these mn-formaton descrptons. References [] Opdyke, W. F., Refactorng Object-Orented Frameworks, Ph.D. thess, Unversty of Illnos at Urbana-Champagn, 99. [] Roberts, D., Practcal Analyss for Refactorng, Ph.D. thess, Unversty of Illnos at Urbana-Champagn, 999. [] Fowler, M., Refactorng: Improvng the Desgn of Exstng Programs, Addson-Wesley, 999. [4] Sunyé, G., Pollet, D., Le Traon Y., and Jézéquel J-M. Refactorng UML models, In Gogolla M. and Kobryn C., edtors, Proc. UML 00 - The Unfed Modelng Language. Modelng Languages, Concepts, and Tools. 4th Internatonal Conference, Toronto, Canada, volume 85 of LNCS, pages Sprnger, 00. [5] Ó Cnnéde, M., Automated Applcaton of Desgn Patterns: A Refactorng Approach, Ph.D. thess, Department of Computer Scence, Trnty College, Unversty of Dubln, 000. [6] Van Gorp, P., Stenten, H., Mens T., Demeyer, S.: Towards automatng source-consstent UML Refactorngs, UML 00. [7] Object Management Group. UML.0 Superstructure Specfcaton, September 00 [8] Object Management Group. UML.0 OCL Specfcaton, Fnal Adopted Specfcaton, October 00 [9] Gamma, E., Helm R., Johnson R. and Vlssdes, J. Desgn Patterns: Elements of Reusable Object-Orented Languages and Systems, Addson-Wesley, 994. [0] Object Management Group. MDA Gude Verson.0., OMG,. June 00 [] Knesel G., Koch H., Statc Composton of Refactorngs, In R. Lämmel, edtor, Scence n Computer Programmng; Specal ssue on program formaton. Elsever Scence, 004. To appear. [] Pollet D., Vojtsek D. and Jézéquel J-M. OCL as a core UML formaton language. WITUML 00 Poston paper, Malaga, Span, June 00. [] Sunyé, G., Le Guennec, A. and Jézéquel J-M. Usng UML Acton Semantcs for model executon and formaton. Informaton Systems Journal 7(6): , July 00 [4] Eclpse Project, [5] Object Management Group. Unfed Modelng Language (UML), verson.5, March 00.