Software refactoring is intended to enhance the quality of a software by improving its understandability, performance, as well as other quality attributes. We adopt the modelling framework of [14] in order to analyze software qualities, to determine which software refactoring transformations are most appropriate. In addition, we use software metrics to evaluate software quality quantitatively. Our framework adopts and extends work reported in [15]

D'Hollander, Erik

Leite, JC

Liu, Linda

Mylopoulos, John

Yu, Eric

Yu, Yijun

English

Ghent University Academic Bibliography

Software refactoring guided by multiple soft-goalsYijun Yu John Mylopoulos Eric YuJulio Cesar Leite Linda Lin Liu Erik D’Hollander*CS Department, University of Toronto, M5S 2E4 Canada∗ELIS Department, University of Ghent, B9000, BelgiumAbstractSoftware refactoring is intended to enhance thequality of a software by improving its understandabil-ity, performance, as well as other quality attributes.We adopt the modelling framework of [14] in orderto analyze software qualities, to determine which soft-ware refactoring transformations are most appropri-ate. In addition, we use software metrics to evaluatesoftware quality quantitatively. Our framework adoptsand extends work reported in [15].1 IntroductionFowler et al [7] define software refactoring as “theprocess of changing a software system in such a waythat it does not alter the external behavior of the codeyet improves its internal structure”. “Improvementsto its internal structure” amount to improvements tothe quality of the software system (also known as non-functional requirements). Examples of such improve-ments are “making the code easier to understand andcheaper to modify”. Their refactoring framework wasproposed mainly for improving understandability andmodifiability. However, the idea can also be appliedto other qualities [14], such as performance, security,usability and more.In this study, we adopt the process-oriented frame-work proposed in [3] for modelling software qualities.In this framework, qualities and the factors that affectthem are modelled as soft-goals, while functionalitiesare modelled as goals. Specifically, they can be opera-tionalized into tasks and resources. The dependenciesamong goals, soft-goals, tasks and resources are rep-resented in a soft-goal interdependence graph (SIG).Besides the functionality goals, we focus on perfor-mance and code complexity soft goals that are asso-ciated with a set of software metrics [6]. Constrainedby conflicting resources, multiple soft-goals have to betraded off, in situations such as “apply transforma-tions to speedup the program 20 times without sac-rificing the code complexity 4 times and introducingnew expense on hardware”; or “adding functionalitiesto the program until the performance is getting slow(e.g., longer than one hour) or the code becomes toocomplex to understand and maintain (e.g., more than10 classes in one header file)”.In a case study, we will show how SIG guides therefactoring towards high performance and code sim-plicity while keeping implementing more functional-ities. We have applied this approach in our headerrefactoring project [18] observing the progress (func-tionality), health (code complexity) and quality (per-formance) evolutions in the software development [4].2 Software refactoring processThe refactoring process [7] is a sequence of smalltransformation steps: “while each refactoring step issimple, yet the cumulative effect of these small changescan radically improve the design”. To achieve this suc-cess, our approach is an iterative process that meetsthe soft-goals gradually, as illustrated in Figure 1. Theprocess is subdivided into four consecutive steps:1. Setting up the goal-reasoning model as a SIG [3],quantifying the satisfy or denial attributes of eachsoft-goal in a [0,1] metric [8];2. Quantitatively measuring software metrics so asto claim which alternative soft-goal should be ap-plied first;3. Picking an effective refactoring among varioustransformations that contribute to the claimedsoft-goal;4. Applying the selected refactoring technique,which leads to iterative evaluations back in step 2,Figure 1: The overview of the soft-goal directed soft-ware refactoring process.until every top-level soft-goals are met to releasethe software product.3 A case studyIn this section, we report on a case study for per-formance and complexity soft-goals on a fixed func-tionality – consider the following Fortran program formultiplying two matrices A ∈ Rm×l and B ∈ Rl×ninto a matrix C ∈ Rm×n.real*8 A(512,512),B(512,512),C(512,512)M = L = N = 512do i = 1,Mdo j = 1, Ldo k = 1, NC(i,k) = C(i,k) + A(i,j) * B(j,k)3.1 Goal ModellingSoftware development aims to improve the speed ofsoftware (performance) and to reduce the code com-plexity. Achieving the performance soft-goal reducesthe operational cost while achieving the code sim-plicity soft-goal reduces the develop and maintenancecost [10].Here we establish a soft-goal interdependence graphfor the possibly conflicting higher performance andlower code complexity soft-goals and show how muchthe operationalized soft-goals contribute to them.Less code complexity Code complexity has effectson how difficult to test and to maintain, while goodFigure 2: A SIG model for code complexitytestability and maintainability lead to less defect rate.In literature [10], code complexity can be measuredin lines of code (LOC), McCabe’s cyclomatic numberV (G) = e − n + 2 [12] or in Halstead’s informationscience metrics [9] as (N1 + N2)log2(n1 + n2) wheren1 is the number of unique operators, N1 is the to-tal number of operators, n2 is the number of uniqueoperands and N2 is the total number of operands N2.Their SIG are shown in Figure 2.Higher time performance In order to achievea higher time performance system “Perf[System]”,both hardware (“Perf[Architecture]”) and software(“Perf[Algorithm]” and “Perf[Coding]”) improve-ments are useful. For software refactoring, we considermostly on the codings that fit programs on the givenarchitecture. The “Perf[architecture]” soft-goal is de-composed into “Perf[Processor]” and “Perf[Storage]”,and “Perf[Processor]” is decomposed into “FasterCPU frequency[Processor]”, “More CPU[Processor]”and “Deeper pipeline[Processor]”; “Perf[Storage]” isdecomposed into “Perf[Main Memory]”, “Perf[Cache]”subgoals, where ”Perf[Cache]” can be further decom-posed into “Larger cache size[Cache]”, “Larger cacheline[Cache]” and “More set associativity[Cache]”soft-goals. Soft-goals for coding have correspond-ing hardware constraints. For example, “MoreCPU[Processor]” soft-goal is required to implementparallelism, which can be improved by “Loop parti-tioning[coding]” [1, 5, 19] to achieve “More loop paral-lelism[coding]” soft-goal; “Larger cache[Cache]” soft-goal to resolve capacity cache misses; “Loop tilingand fusion[coding]” shortening the stack reuse dis-tances [2] so as to avoid capacity misses for a givencache size [16, 13, 2]. A detailed decomposition oftime performance soft-goal is shown in Figure 3.Figure 3: A SIG decomposed for time performance. The thinner cloud nodes are soft-goals while the heaviercloud nodes are operationalized (measurable or implementable) soft-goals. The solid arrows reflect top-downdecomposition of the soft-goal into “And”, “Or” or supporting soft subgoals such as “Make(++)” and “Help (+)”.The dashed arrows reflect correlational links between soft-goals on different decomposition paths to represent bothpositive and negative (“Hurt(−)/Break(−−)”) contributions.3.2 Claiming bottlenecks soft-goalsIn the SIG, transformations are the operational-ized soft-goals. Depending on the the problem andthe resources, different transformations contribute dif-ferently to the parent soft-goals. In our case study,for instance, we don’t welcome algorithm or architec-ture changes because they are claimed less return ofinvestment (expensive in human creativity or in ma-chine availability). Thus we consider the children ofthe “Perf[coding]” soft-goal. Which of them shouldbe addressed? According to Intel VTune white pa-per, hardware counter metrics help programmer to de-cide whether the execution time is intensive in mem-ory, I/O, communication or computation. One ofthe decision point is the ratio of the L2 cache missesover the number of load instructions: whenever theL2 cache miss ratio is higher than 20%, memory isthe bottleneck of performance. In our case study,this ratio is over 79.45%, which indicates that “Fewercache misses[coding]” is the soft-goal to address1. Us-ing a cache visualizing tool [17], we found that thedominate cache misses are capacity misses as well1All experiments are performed on an Intel P4 1.2GHz CPUwith 512KB cache and 128MB main memoryas conflict misses, which narrows us down to the“Fewer Capacity Misses[coding]” and the “Fewer Con-flict Misses[coding]” categories. Now just a few trans-formation techniques are suited.3.3 Selecting refactoring transformationsBottleneck measurement is still not enough to de-cide which refactoring should be made. Another fac-tor is meeting multiple soft-goals as the general aimof the refactoring. For example, the aim can be ex-pressed as “apply transformations to speedup the pro-gram 20 times without sacrificing the code complexity4 times”. One needs to see which transformation ismost effective.In the first step of refactoring process, we con-sider what operational soft-goals are applicable. Fixedhardware platform and algorithm already narrowedour search to the “Perf[coding]” subcategory in Fig-ure 3. Initially we considered five applicable transfor-mations to this program. Besides the above transfor-mations we also investigated the impact of differentoptimization techniques such as dynamic memory al-location, dot-product.Using the experiment data, the log scale view ofFigure 4: For the example programs, the quality spacewith time performance and code complexity indicesare shown at log scale. Each program in table 1 isprojected to a point in the space, each transformationproduces an arrow from the program to another. Itis clear that array padding, loop permutation, tilingand unrolling are effective optimizations when usedproperly, however, the last two increase complexity.the quality space of time and complexity indices areshown in Figure 4.Some techniques improve one soft-goal but harmseverely to the other, while others provide net im-provement to both soft-goals. The decision makercan choose the one suited for the intention. Figure 5shows five major transformations as decision makingalternatives. It is based on the initial soft-goals as“apply transformations to speedup the program 20times without sacrificing the code complexity 4 times”,which is indicated in Figure 4 as a shadowed region.4 ApplicationBy laws of software evolution, a software is nat-urally subjected to continuing change (law 1), in-creasing complexity (law 2) and declining quality (law7) [11]. We applied the proposed refactoring process toan on-going joint project with IBM Toronto lab [18].This project aims at delivering a restructuring toolthat speeds up the build processes within a reason-able time budget. We monitored the growth of thetool from scratch and plotted the metrics of changingfunctionality, performance and complexity in Figure 6,as it evolves from a code dependency graph partition-ing algorithm (version 1 to 3), to 269 KLOC VIM 6.2Figure 5: Two steps of refactoring are shown. Eachstep identifies the applicable tasks (operational soft-goals) for the given program (context), then decideson appropriate tasks for performance and complexity.The weights given to a branch result from multiplyingthe distribution weight through measurement with thesoft-goal dependence weight in the quantified SIG.in C (version 4 to 9) and to a 1580 KLOC commer-cial software package in C++ (version 10 to 13). Thefunctionality is measured as the number of programunits being correctly preprocessed. Here we use thenumber in version 13 as unit to normalize those atearlier versions. Performance and complexity metricsare also normalized as ratios against the largest datapoint and observed the versions where performancetuning and complexity refactoring taken places.5 Related work and summaryLadan Tahvildari et al [15] first applied the NFRframework for comparing performance and maintain-ability of OO software with/without design patterns.Her work emphasizes on comparing design patternson maintainability issue, while this paper focuses onthe performance tuning issues along with refactoringin the develop process. In order to make the trade-offbetween the two issues clear, we plot the metrics inan quality space so that the refactoring process canbe traced as one of the paths leading to the satisfiableregion by the soft-goals.Functionalities of a software system are concernedwith changes to the state of data, while non-functionalrequirements are with the changes to the state ofthe program without touching the state of the data.Figure 6: Goal guided refactoring on the software de-velopment for C/C++ header restructuring project.In this perspective, Zou et al [20] consider softwaremigration practice as a state transition system ofthe quality attributes. The assumption is that alegacy procedural program as a given product canbe migrated to leverage qualities promised by object-oriented paradigm.A case study in our work has shown that refactoringcan be measured as the transformation on the state ofprogram in the quality space. By further monitoringthe process developing a new software from scratch,we suggest measuring the quality space along withthe progress so that the refactoring goal is balancedwith the productivity goal on demand. The satisfi-able region in the quality space should be adjusteddynamically during the software evolution, i.e., devel-opment can be centric with a different top-priority at adifferent development phase. Because the refactoringchanges are non-functional, they are invertible if nofunctionality change happens. Mixing with the func-tionality changes, however, the invertibility does nothold. Therefore the steps of refactoring must be smallenough so that neither the productivity nor the invert-ibility would endanger the development goals.References[1] U. Banerjee, R. Eigenmann, A. Nicolau, and D. A.Padua. Automatic program parallelization. Proceed-ings of the IEEE, 81(2):211–243, feb 1993.[2] K. Beyls and E. H. D’Hollander. Reuse distance-based cache hint selection. Lecture Notes in Com-puter Science, 2400:265–274, 2002.[3] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos.Non-functional requirements in software engineering.Kluwer Academic Publishers, 2000.[4] H. Dayani-Fard. Quality-based software release man-agement. PhD thesis, Queen’s University, 2003.[5] E. H. D’Hollander. Partitioning and labeling of loopsby unimodular transformations. IEEE Transactionson Parallel and Distributed Systems, 3(4):465–476, jul1992.[6] N. Fenton and S. L. Pfleeger. Software Metrics -A Rigorous and Practical Approach. InternationalThomson Computer Press, London, 2 edition, 1996.[7] M. Fowler, K. Beck, J. Brant, W. Opdyke, andD. Roberts. Refactoring: Improving the Design ofExisting Code. Addison-Wesley, 1999.[8] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and R. Se-bastiani. Reasoning with goal models. Lecture Notesin Computer Science, 2503:167–??, 2002.[9] M. H. Halstead. Elements of Software Science. Else-vier North-Holland, New York, 1 edition, 1977.[10] D. L. Lanning and T. M. Khoshgoftaar. Modelingthe relationship between source code complexity andmaintenance difficulty. Computer, 27(9):35–40, Sept.1994.[11] M. M. Lehman. Laws of software evolution revis-ited. Lecture Notes in Computer Science, 1149:108–120, 1996.[12] T. J. McCabe. A complexity measure. IEEE Trans-actions on Software Engineering, 2(4):308–320, Dec.1976.[13] K. McKinley, S. Carr, and C. Tseng. Improv-ing data locality with loop transformations. ACMTransactions on Programming Languages and Sys-tems, 18(4):424–453, Jul 1996.[14] J. Mylopoulos, L. Chung, and B. Nixon. Represent-ing and using nonfunctional requirements: A process-oriented approach. IEEE Transactions on SoftwareEngineering, 18(6):483–497, Jun 1992. Special Issueon Knowledge Representation and Reasoning in Soft-ware Engineering.[15] L. Tahvildari and K. Kontogiannis. Requirements-driven software re-engineering framework. In WCRE2001, pages 71–80, 2001.[16] M. E. Wolf and M. S. Lam. A data locality optimizingalgorithm. SIGPLAN Notices, 26(6):30–44, 1991.[17] Y. Yu, K. Beyls, and E. D’Hollander. Visualizing theimpact of the cache on program execution. In 5thInternational Conference on Information Visualiza-tion (IV ’01), pages 336–341, Washington - Brussels- Tokyo, July 2001. IEEE.[18] Y. Yu, H. Dayani-Fard, and J. Mylopoulos. Removingfalse code dependencies to speedup software develop-ment processes. In Proceedings of the 13th CASCONconference, pages 288–297, Oct. 2003.[19] Y. Yu and E. D’Hollander. Partitioning loops withvariable dependence distances. In Proceedings of29th International Conference on Parallel Processing,Toronto, Canada, Aug. 2000. Ohio State Univ.[20] Y. Zou and K. Kontogiannis. Migration to objectoriented platforms: A state transformation approach.In International Conference on Software Maintenance(ICSM’02), pages 530–539, Oct. 2002.

Software refactoring guided by multiple soft-goals

Yu, Y

Mylopoulos, J

Leite, J.C.S.P

Liu, L

D'Hollander, E.H

Open Research Online

Open Research OnlineThe Open University’s repository of research publicationsand other research outputsSoftware refactoring guided by multiple soft-goalsConference or Workshop ItemHow to cite:Yu, Y; Mylopoulos, J; Leite, J.C.S.P; Liu, L and D’Hollander, E.H (2003). Software refactoring guided bymultiple soft-goals. In: 1st workshop on Refactoring: Achievements, Challenges, and Effects (REFACE’03), 13-16 Nov2003, Victoria, Canada.For guidance on citations see FAQs.c© 2003 IEEEVersion: Accepted ManuscriptLink(s) to article on publisher’s website:http://www.cs.toronto.edu/ yijun/literature/paper/yu03reface.pdfCopyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copyrightowners. For more information on Open Research Online’s data policy on reuse of materials please consult the policiespage.oro.open.ac.ukSoftware refactoring guided by multiple soft-goalsYijun Yu John Mylopoulos Eric YuJulio Cesar Leite Linda Lin Liu Erik D’Hollander*CS Department, University of Toronto, M5S 2E4 Canada∗ELIS Department, University of Ghent, B9000, BelgiumAbstractSoftware refactoring is intended to enhance thequality of a software by improving its understandabil-ity, performance, as well as other quality attributes.We adopt the modelling framework of [14] in orderto analyze software qualities, to determine which soft-ware refactoring transformations are most appropri-ate. In addition, we use software metrics to evaluatesoftware quality quantitatively. Our framework adoptsand extends work reported in [15].1 IntroductionFowler et al [7] define software refactoring as “theprocess of changing a software system in such a waythat it does not alter the external behavior of the codeyet improves its internal structure”. “Improvementsto its internal structure” amount to improvements tothe quality of the software system (also known as non-functional requirements). Examples of such improve-ments are “making the code easier to understand andcheaper to modify”. Their refactoring framework wasproposed mainly for improving understandability andmodifiability. However, the idea can also be appliedto other qualities [14], such as performance, security,usability and more.In this study, we adopt the process-oriented frame-work proposed in [3] for modelling software qualities.In this framework, qualities and the factors that affectthem are modelled as soft-goals, while functionalitiesare modelled as goals. Specifically, they can be opera-tionalized into tasks and resources. The dependenciesamong goals, soft-goals, tasks and resources are rep-resented in a soft-goal interdependence graph (SIG).Besides the functionality goals, we focus on perfor-mance and code complexity soft goals that are asso-ciated with a set of software metrics [6]. Constrainedby conflicting resources, multiple soft-goals have to betraded off, in situations such as “apply transforma-tions to speedup the program 20 times without sac-rificing the code complexity 4 times and introducingnew expense on hardware”; or “adding functionalitiesto the program until the performance is getting slow(e.g., longer than one hour) or the code becomes toocomplex to understand and maintain (e.g., more than10 classes in one header file)”.In a case study, we will show how SIG guides therefactoring towards high performance and code sim-plicity while keeping implementing more functional-ities. We have applied this approach in our headerrefactoring project [18] observing the progress (func-tionality), health (code complexity) and quality (per-formance) evolutions in the software development [4].2 Software refactoring processThe refactoring process [7] is a sequence of smalltransformation steps: “while each refactoring step issimple, yet the cumulative effect of these small changescan radically improve the design”. To achieve this suc-cess, our approach is an iterative process that meetsthe soft-goals gradually, as illustrated in Figure 1. Theprocess is subdivided into four consecutive steps:1. Setting up the goal-reasoning model as a SIG [3],quantifying the satisfy or denial attributes of eachsoft-goal in a [0,1] metric [8];2. Quantitatively measuring software metrics so asto claim which alternative soft-goal should be ap-plied first;3. Picking an effective refactoring among varioustransformations that contribute to the claimedsoft-goal;4. Applying the selected refactoring technique,which leads to iterative evaluations back in step 2,Figure 1: The overview of the soft-goal directed soft-ware refactoring process.until every top-level soft-goals are met to releasethe software product.3 A case studyIn this section, we report on a case study for per-formance and complexity soft-goals on a fixed func-tionality – consider the following Fortran program formultiplying two matrices A ∈ Rm×l and B ∈ Rl×ninto a matrix C ∈ Rm×n.real*8 A(512,512),B(512,512),C(512,512)M = L = N = 512do i = 1,Mdo j = 1, Ldo k = 1, NC(i,k) = C(i,k) + A(i,j) * B(j,k)3.1 Goal ModellingSoftware development aims to improve the speed ofsoftware (performance) and to reduce the code com-plexity. Achieving the performance soft-goal reducesthe operational cost while achieving the code sim-plicity soft-goal reduces the develop and maintenancecost [10].Here we establish a soft-goal interdependence graphfor the possibly conflicting higher performance andlower code complexity soft-goals and show how muchthe operationalized soft-goals contribute to them.Less code complexity Code complexity has effectson how difficult to test and to maintain, while goodFigure 2: A SIG model for code complexitytestability and maintainability lead to less defect rate.In literature [10], code complexity can be measuredin lines of code (LOC), McCabe’s cyclomatic numberV (G) = e − n + 2 [12] or in Halstead’s informationscience metrics [9] as (N1 + N2)log2(n1 + n2) wheren1 is the number of unique operators, N1 is the to-tal number of operators, n2 is the number of uniqueoperands and N2 is the total number of operands N2.Their SIG are shown in Figure 2.Higher time performance In order to achievea higher time performance system “Perf[System]”,both hardware (“Perf[Architecture]”) and software(“Perf[Algorithm]” and “Perf[Coding]”) improve-ments are useful. For software refactoring, we considermostly on the codings that fit programs on the givenarchitecture. The “Perf[architecture]” soft-goal is de-composed into “Perf[Processor]” and “Perf[Storage]”,and “Perf[Processor]” is decomposed into “FasterCPU frequency[Processor]”, “More CPU[Processor]”and “Deeper pipeline[Processor]”; “Perf[Storage]” isdecomposed into “Perf[Main Memory]”, “Perf[Cache]”subgoals, where ”Perf[Cache]” can be further decom-posed into “Larger cache size[Cache]”, “Larger cacheline[Cache]” and “More set associativity[Cache]”soft-goals. Soft-goals for coding have correspond-ing hardware constraints. For example, “MoreCPU[Processor]” soft-goal is required to implementparallelism, which can be improved by “Loop parti-tioning[coding]” [1, 5, 19] to achieve “More loop paral-lelism[coding]” soft-goal; “Larger cache[Cache]” soft-goal to resolve capacity cache misses; “Loop tilingand fusion[coding]” shortening the stack reuse dis-tances [2] so as to avoid capacity misses for a givencache size [16, 13, 2]. A detailed decomposition oftime performance soft-goal is shown in Figure 3.Figure 3: A SIG decomposed for time performance. The thinner cloud nodes are soft-goals while the heaviercloud nodes are operationalized (measurable or implementable) soft-goals. The solid arrows reflect top-downdecomposition of the soft-goal into “And”, “Or” or supporting soft subgoals such as “Make(++)” and “Help (+)”.The dashed arrows reflect correlational links between soft-goals on different decomposition paths to represent bothpositive and negative (“Hurt(−)/Break(−−)”) contributions.3.2 Claiming bottlenecks soft-goalsIn the SIG, transformations are the operational-ized soft-goals. Depending on the the problem andthe resources, different transformations contribute dif-ferently to the parent soft-goals. In our case study,for instance, we don’t welcome algorithm or architec-ture changes because they are claimed less return ofinvestment (expensive in human creativity or in ma-chine availability). Thus we consider the children ofthe “Perf[coding]” soft-goal. Which of them shouldbe addressed? According to Intel VTune white pa-per, hardware counter metrics help programmer to de-cide whether the execution time is intensive in mem-ory, I/O, communication or computation. One ofthe decision point is the ratio of the L2 cache missesover the number of load instructions: whenever theL2 cache miss ratio is higher than 20%, memory isthe bottleneck of performance. In our case study,this ratio is over 79.45%, which indicates that “Fewercache misses[coding]” is the soft-goal to address1. Us-ing a cache visualizing tool [17], we found that thedominate cache misses are capacity misses as well1All experiments are performed on an Intel P4 1.2GHz CPUwith 512KB cache and 128MB main memoryas conflict misses, which narrows us down to the“Fewer Capacity Misses[coding]” and the “Fewer Con-flict Misses[coding]” categories. Now just a few trans-formation techniques are suited.3.3 Selecting refactoring transformationsBottleneck measurement is still not enough to de-cide which refactoring should be made. Another fac-tor is meeting multiple soft-goals as the general aimof the refactoring. For example, the aim can be ex-pressed as “apply transformations to speedup the pro-gram 20 times without sacrificing the code complexity4 times”. One needs to see which transformation ismost effective.In the first step of refactoring process, we con-sider what operational soft-goals are applicable. Fixedhardware platform and algorithm already narrowedour search to the “Perf[coding]” subcategory in Fig-ure 3. Initially we considered five applicable transfor-mations to this program. Besides the above transfor-mations we also investigated the impact of differentoptimization techniques such as dynamic memory al-location, dot-product.Using the experiment data, the log scale view ofFigure 4: For the example programs, the quality spacewith time performance and code complexity indicesare shown at log scale. Each program in table 1 isprojected to a point in the space, each transformationproduces an arrow from the program to another. Itis clear that array padding, loop permutation, tilingand unrolling are effective optimizations when usedproperly, however, the last two increase complexity.the quality space of time and complexity indices areshown in Figure 4.Some techniques improve one soft-goal but harmseverely to the other, while others provide net im-provement to both soft-goals. The decision makercan choose the one suited for the intention. Figure 5shows five major transformations as decision makingalternatives. It is based on the initial soft-goals as“apply transformations to speedup the program 20times without sacrificing the code complexity 4 times”,which is indicated in Figure 4 as a shadowed region.4 ApplicationBy laws of software evolution, a software is nat-urally subjected to continuing change (law 1), in-creasing complexity (law 2) and declining quality (law7) [11]. We applied the proposed refactoring process toan on-going joint project with IBM Toronto lab [18].This project aims at delivering a restructuring toolthat speeds up the build processes within a reason-able time budget. We monitored the growth of thetool from scratch and plotted the metrics of changingfunctionality, performance and complexity in Figure 6,as it evolves from a code dependency graph partition-ing algorithm (version 1 to 3), to 269 KLOC VIM 6.2Figure 5: Two steps of refactoring are shown. Eachstep identifies the applicable tasks (operational soft-goals) for the given program (context), then decideson appropriate tasks for performance and complexity.The weights given to a branch result from multiplyingthe distribution weight through measurement with thesoft-goal dependence weight in the quantified SIG.in C (version 4 to 9) and to a 1580 KLOC commer-cial software package in C++ (version 10 to 13). Thefunctionality is measured as the number of programunits being correctly preprocessed. Here we use thenumber in version 13 as unit to normalize those atearlier versions. Performance and complexity metricsare also normalized as ratios against the largest datapoint and observed the versions where performancetuning and complexity refactoring taken places.5 Related work and summaryLadan Tahvildari et al [15] first applied the NFRframework for comparing performance and maintain-ability of OO software with/without design patterns.Her work emphasizes on comparing design patternson maintainability issue, while this paper focuses onthe performance tuning issues along with refactoringin the develop process. In order to make the trade-offbetween the two issues clear, we plot the metrics inan quality space so that the refactoring process canbe traced as one of the paths leading to the satisfiableregion by the soft-goals.Functionalities of a software system are concernedwith changes to the state of data, while non-functionalrequirements are with the changes to the state ofthe program without touching the state of the data.Figure 6: Goal guided refactoring on the software de-velopment for C/C++ header restructuring project.In this perspective, Zou et al [20] consider softwaremigration practice as a state transition system ofthe quality attributes. The assumption is that alegacy procedural program as a given product canbe migrated to leverage qualities promised by object-oriented paradigm.A case study in our work has shown that refactoringcan be measured as the transformation on the state ofprogram in the quality space. By further monitoringthe process developing a new software from scratch,we suggest measuring the quality space along withthe progress so that the refactoring goal is balancedwith the productivity goal on demand. The satisfi-able region in the quality space should be adjusteddynamically during the software evolution, i.e., devel-opment can be centric with a different top-priority at adifferent development phase. Because the refactoringchanges are non-functional, they are invertible if nofunctionality change happens. Mixing with the func-tionality changes, however, the invertibility does nothold. Therefore the steps of refactoring must be smallenough so that neither the productivity nor the invert-ibility would endanger the development goals.References[1] U. Banerjee, R. Eigenmann, A. Nicolau, and D. A.Padua. Automatic program parallelization. Proceed-ings of the IEEE, 81(2):211–243, feb 1993.[2] K. Beyls and E. H. D’Hollander. Reuse distance-based cache hint selection. Lecture Notes in Com-puter Science, 2400:265–274, 2002.[3] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos.Non-functional requirements in software engineering.Kluwer Academic Publishers, 2000.[4] H. Dayani-Fard. Quality-based software release man-agement. PhD thesis, Queen’s University, 2003.[5] E. H. D’Hollander. Partitioning and labeling of loopsby unimodular transformations. IEEE Transactionson Parallel and Distributed Systems, 3(4):465–476, jul1992.[6] N. Fenton and S. L. Pfleeger. Software Metrics -A Rigorous and Practical Approach. InternationalThomson Computer Press, London, 2 edition, 1996.[7] M. Fowler, K. Beck, J. Brant, W. Opdyke, andD. Roberts. Refactoring: Improving the Design ofExisting Code. Addison-Wesley, 1999.[8] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and R. Se-bastiani. Reasoning with goal models. Lecture Notesin Computer Science, 2503:167–??, 2002.[9] M. H. Halstead. Elements of Software Science. Else-vier North-Holland, New York, 1 edition, 1977.[10] D. L. Lanning and T. M. Khoshgoftaar. Modelingthe relationship between source code complexity andmaintenance difficulty. Computer, 27(9):35–40, Sept.1994.[11] M. M. Lehman. Laws of software evolution revis-ited. Lecture Notes in Computer Science, 1149:108–120, 1996.[12] T. J. McCabe. A complexity measure. IEEE Trans-actions on Software Engineering, 2(4):308–320, Dec.1976.[13] K. McKinley, S. Carr, and C. Tseng. Improv-ing data locality with loop transformations. ACMTransactions on Programming Languages and Sys-tems, 18(4):424–453, Jul 1996.[14] J. Mylopoulos, L. Chung, and B. Nixon. Represent-ing and using nonfunctional requirements: A process-oriented approach. IEEE Transactions on SoftwareEngineering, 18(6):483–497, Jun 1992. Special Issueon Knowledge Representation and Reasoning in Soft-ware Engineering.[15] L. Tahvildari and K. Kontogiannis. Requirements-driven software re-engineering framework. In WCRE2001, pages 71–80, 2001.[16] M. E. Wolf and M. S. Lam. A data locality optimizingalgorithm. SIGPLAN Notices, 26(6):30–44, 1991.[17] Y. Yu, K. Beyls, and E. D’Hollander. Visualizing theimpact of the cache on program execution. In 5thInternational Conference on Information Visualiza-tion (IV ’01), pages 336–341, Washington - Brussels- Tokyo, July 2001. IEEE.[18] Y. Yu, H. Dayani-Fard, and J. Mylopoulos. Removingfalse code dependencies to speedup software develop-ment processes. In Proceedings of the 13th CASCONconference, pages 288–297, Oct. 2003.[19] Y. Yu and E. D’Hollander. Partitioning loops withvariable dependence distances. In Proceedings of29th International Conference on Parallel Processing,Toronto, Canada, Aug. 2000. Ohio State Univ.[20] Y. Zou and K. Kontogiannis. Migration to objectoriented platforms: A state transformation approach.In International Conference on Software Maintenance(ICSM’02), pages 530–539, Oct. 2002.

http://oro.open.ac.uk/33847/1/Software_refactoring.pdf

Software refactoring guided by multiple soft-goals

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography

Open Research Online