Otto-von-Guericke-Universität Magdeburg. Faculty of Computer Science Department of Technical and Business Information Systems.

Transcription

1 Otto-von-Guericke-Universität Magdeburg Faculty of Computer Science Department of Technical and Business Information Systems Master Thesis Stepwise-Development Case Study with Refactoring Feature Modules Author: Jing Ouyang December 2, 2009 Advisor: Prof. Dr. rer. nat. habil. Gunter Saake, Dipl.-Inform. Martin Kuhlemann, University of Magdeburg Faculty of Computer Science Postfach 4120, D Magdeburg Germany

2 Ouyang, Jing: Stepwise-Development Case Study with Refactoring Feature Modules Master Thesis Otto-von-Guericke-Universität Magdeburg, 2009.

3 i Acknowledgements I would like to thank Prof. Dr. Gunter Saake for giving me the opportunity to work on master thesis in his group. I have been indebted in the preparation of this thesis to my advisor, Martin Kuhlemann, whose patience and kindness, as well as his academic experience, have been invaluable to me. I would like to especially thank Martin Kuhlemann for his helpful reviews and suggestions. I would to thank my parents because of whom this education is made possible for me. Lastly, I wish to thank my boy friend Xiaowei, who supported me and helped me to take care of my family.

4 ii

5 CONTENTS iii Contents Contents List of Figures List of Tables List of Abbreviations iii vii xi xiii 1 Introduction Motivation Goals Structure of the Thesis Background Software Development Process Software Development Activities Software Development Models Stepwise Development Feature Oriented Programming Feature Module GenVoca and AHEAD ATS The Jak Language Refactoring Feature Modules Refactoring Refactoring Feature Modules Summary

6 iv CONTENTS 3 Stepwise Development with FOP and RFM Tool Support Introduction of Cases Stepwise Development with FOP Software Program Pre-Processing Construction of Feature Diagram Typical process of FOP in Case Study Stepwise Development with RFM Combination of RFM and FOP Encountered Problems Summary Case Study Results Study Results for the Program JHotDraw Study Results for other Programs New Refactorings Evaluation Jak Extension Basic Concept Extension for multiple Layers Benefit from the Extension Related Work, Conclusion and Further work Related Work Conclusion and Further Work Bibliography 69 A Information for JHotDraw 75 A.1 Refinements Frequency in JHoDraw A.2 RFM in Step JHotDraw A.3 RFM Frequency in JHoDraw A.4 Problems in JHoDraw

7 CONTENTS v B Information for other Programs 81 B.1 Beck XML Mapper B.2 POJava B.3 ZK-Google Maps B.4 Euclide B.5 Cobertura B.6 TrueZip B.7 Java DjVu Viewer B.8 HyperSQL

8 vi CONTENTS

9 LIST OF FIGURES vii List of Figures 1.1 Stepwise Refinement Refinement chain Waterfall model Iterative model Classes and Refinements Relationships of Features Feature Diagram GenVoca constant and function GenVoca model Constant and function sets Composer tool Composing and Translating Jak files Mixin and Jampack Examples of Jak keywords Example of constructor refinement Error with new modifier RenameClassRefactoring in RFM Feature diagram with refactoring features The class List Refactoring feature modules R1,R2,R Refactored class LinkedList Example of added class Rename variable parent Feature diagrams of JHotDraw

10 viii LIST OF FIGURES 3.4 Class DrawApplet Class DrawApplet in FOP Composition of DrawApplet Composed DrawApplet RFM of RenameMethodRefactoring Result of RenameMethodRefactoring Refactoring modules in class LineConnection Schematic diagram of EncapsulateFieldRefactoring Refactoring and Refinement methods Feature Modules Annotation problem Constructor refinement in DrawApplicaton Example of Super problem Override Method Override Class Interesting perspective of overrides Change Actual Parameter Change Formal Parameter Type Encapsulated by Conditional Change within conditional statement Genericity Change Condition of Conditional Rename Formal Parameter Change Super Class Extract Method Remove Catch Exception Replace Conditional with Ternary Operator Inline Import Path Remove Implemented Interfaces Change For Loop to While Loop Consolidate methods Replace Interface with Class

11 LIST OF FIGURES ix 5.1 Sentence Keyword insert Keyword delete Keyword replace Insert sequential Sentences Insert in multiple layers Delete in multiple layers Replace in multiple layers Application of Jak Extension SWD with more Techniques

12 x LIST OF FIGURES

13 LIST OF TABLES xi List of Tables 3.1 Tools list of development Environment Projects for cast study Refinement features RenameMethodRefactoring in step JHotDraw Frequently Problems Implemented steps in case study Count of refinements and RFM in case study Method refinements and Overrides method Situations can be implemented by overrides Count of RFM and other refactorings Number of RFM and other refactorings Irrealizable Situations Steps introduce Genericity A.1 Refinements Frequency in JHoDraw A.2 RFM Frequency in JHoDraw A.3 Problems in JHoDraw B.1 Refinements Frequency in Beck XML Mapper B.2 RFM Frequency in Beck XML Mapper B.3 Problems in Beck XML Mapper B.4 Refinements Frequency in POJava B.5 RFM Frequency in POJava B.6 Problems in POJava B.7 Refinements Frequency in ZK-Google Maps

14 xii LIST OF TABLES B.8 RFM Frequency in ZK-Google Maps B.9 Problems in ZK-Google Maps B.10 Refinements Frequency in Euclide B.11 RFM Frequency in Euclide B.12 Problems in Euclide B.13 Refinements Frequency in Cobertura B.14 RFM Frequency in Cobertura B.15 Problems in Cobertura B.16 Refinements Frequency in TrueZip B.17 RFM Frequency in TrueZip B.18 Problems in TrueZip B.19 Refinements Frequency in Java DjVu Viewer B.20 RFM Frequency in Java DjVu Viewer B.21 Problems in Java DjVu Viewer B.22 Refinements Frequency in HyperSQL B.23 RFM Frequency in HyperSQL B.24 Problems in HyperSQL

15 xiii List of Abbreviations XP RUP SWD OOP FOP AHEAD RFM IDE SPL ATS AOP Extreme Programming Rational Unified Process Step-Wise Development Object Oriented Programming Feature Oriented Programming Algebraic Hierarchical Equations for Application Design Refactoring Feature Modules Integrated Development Environment Software Product Lines AHEAD Tool Suite Aspect Oriented Programminge

16 xiv

17 Chapter 1. Introduction 1 Chapter 1 Introduction 1.1 Motivation In software engineering, the software development process is the model imposed on the development of a software product. The first software development model is Waterfall Model, which is proposed by Winston Royce in 1970 [56]. In the past decades, along with the software becoming larger and more complex, many different models have been developed, such as Spiral Model [16], Iterative Model [42], Top-down and Bottom-up design [18], Agile Software Development [45], Extreme Programming(XP) [28] [11], Dynamic Systems Development Method [59], V-model [57]. In particular, the rapid change of requirements and the emergence of large development teams promote the development of iterative model [41]. There are many development models that have been built on the foundation of iterative development, and the notable are Rational Unified Process (RUP) [37] and Agile Software Development Process [45]. Each model has its own advantages, it is very important to choose a suitable software development model to the success of a software project. In this thesis, we will study another iterative and incremental development method: Stepwise Development (SWD). SWD is the program development process with stepwise refinement, which was proposed by Niklaus Wirth in his influential paper Program Development by Stepwise Refinement [71]. Stepwise refinement is a structured programming method and is also the synonym of top-down method. Structured programming can be seen as a subdiscipline of imperative programming, which is the major programming paradigms [73]. Top-down methods were favored in software engineering until the late 1980s, the object-oriented programming (OOP) assisted in demonstrating the idea that, in the stepwise refinement process both aspects of top-down and bottom-up programming could be utilized [55]. The concept of stepwise refinement is not new and has been used in many areas. Architects and engineers have used the method stepwise refinement successfully in manufacturing and engineering areas for many years as a method to control product complexity [70]. Architects used the stepwise refinement approach because they found out that, they can not go from the general to the specific at one time, but in steps. In the last thirty years people try to use the technique to develop systems and software. stepwise refinement is used to develop an object from a general overview to specific details gradually, and the development process of the project can be constructed with a series of refinement steps. In each step the given task can be decomposed into many subtasks.

18 Motivation Niklaus Wirth first brought stepwise refinement in programming classes in 1971 [71]. Stepwise refinement is about producing programs by sequence of refinement steps. The main idea of this method is to divided the one-step compilation of an executable program into several steps, which are carried out with stepwise refinement. First step edits a program with the highest abstraction, second step edits the program with relative lower abstraction, then repeats the second step until an executable program is edited. As shown in Figure 1.1, the producing process of a program can be expressed as a tree. On the top (Node 0) of the tree is a procedure or function, which can be written in a programming language or pseudo code. In each step, the instructions of the given programs are defined or divided into more detailed instructions. Every refinement step implies some design decisions, which must be explicit, such that the programmer knows the criteria of those decisions and all the existent solutions. The tree grows until all the given problems can be solved. Each leave of the tree is a possible solution to a given problem. Figure 1.1: Stepwise Refinement In this thesis, SWD is studied as top-down development method. SWD develops a complex program from a simple program by incrementally adding features [10]. It aims at evolving software over time without changing the existing modules. Since 1968 the software crisis is recognized, the software engineering has made a great progress [35]. But the crisis did not disappear [32] [67]. In the face of more and more complex software systems, the software reuse is considered the best solution to solve the software crisis [49]. Software reuse is the process of building new software systems using the existing software components [26]. In the recent ten years, OOP technology has appeared and provided elemental technology support for software reuse [19]. Software reuse can improve the efficiency and quality of software development. One of the most important goals of software engineering is the higher software reusability [58]. SWD develops software without changing the existing modules, that greatly enhances the reusability of software. So SWD is a significant method that is worth to study. As a software development method, SWD develops a complex program from a simple program by gradually adding increments, which is called feature refinements [10]. Refinements are modules that encapsulate the implementation of features, which can be composed to yield an entire application. With the concept of stepwise refinement, feature modules gradually add classes to a program, or add members to classes, or extend

19 Chapter 1. Introduction 3 members of classes. There are many different implementations of feature refinements, such as layers [5], feature modules [40], collaborations [54] [72], subjects [69], aspects [30] and concerns [65]. In this thesis we use the feature modules to implement features, this is called Feature Oriented Programming (FOP) [52]. FOP is a software development paradigm that refers to feature modularity, and inosculates programming language technology, program generation techniques, and SWD [10] [6]. FOP can improve the productivity of software development projects through standardizing the production process and realizing a software product line (SPL), which is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular domain [50]. There are many languages and tools, that support the specification and composition of features in FOP, such as AHEAD [7], FSTComposer [63], FeatureC++ [3]. AHEAD is a theory of FOP that expresses a set of programs and all representations (e.g. make files, documents, HTML files) as algebraic expressions [7]. AHEAD Tool Suite (ATS) is a suite of tools to implement the theory of AHEAD. Refactoring is also a SWD technique, which can transform the system architecture of a program without modifying its external functional behavior [46]. Refactoring can restructure the members and classes in the programs to remove conflicts that are caused by classes and members in order to increase their reusability. Refactoring is a disciplined, methodical technique, which can reduce conflicts during the process of restructure, and it has been widely used in the software development process [8]. Refactoring Feature Modules (RFM) are special feature modules that combine this refactoring technique and feature-oriented design [39]. In RFM a refactoring is defined in a refactoring unit. Each refactoring feature module encapsulates a refactoring unit or sequences of refactoring units. Users can select feature modules and RFM without distinguishing them to create a program. RFM can reduce the conflicts between applications and raise the reusability of software. Users can restructure a program by selecting according refactoring feature modules in a feature model. In this thesis we will use a case study to analyze the efficiency and practicality of RFM. Our primary intent is to evaluate the consequences of using the SWD techniques, like FOP and RFM, in the process of software evolution. We will choose open source software projects as our case studies, such as JHotDraw, TrueZip and Euclide, use SWD techniques to reconstruct a series of successive releases of these software. 1.2 Goals In this thesis we will analyze and evaluate the consequences of applying SWD to evolve software over time without changing existing modules. On the basis of a series of open source software projects we will use SWD techniques, like refactoring and FOP, to reconstruct successive releases of that software. The procedure can be divided into the following steps: (1) For a case project, we at first encapsulate all class files in Version1 (see Figure 1.2) as a basic feature module.

20 Structure of the Thesis (2) Version1 and Version2 of the software are compared to find out the difference between them. Afterwards SWD techniques, FOP and RFM, are used to reconstruct the successive release Version2. All incremental functions in Version2 are encapsulated in a feature module. (3) Use the same method as step (2) to reconstruct more successive releases of the software, that forms a refinement chain, as shown in Figure 1.2. Figure 1.2: Refinement chain In the case study, we should evaluate the consequences of applying SWD techniques, and summarize and analyze the problems occurred when applying SWD techniques to different non-trivial software products. 1.3 Structure of the Thesis Chapter 2 In this chapter we introduce the theoretical background of the whole thesis, includes software development process and models, SWD, FOP, RFM and the related concepts, such as features, feature modules, refactoring, AHEAD s theory and the tool set AST. Chapter 3 In this chapter, we present the stepwise development process with FOP and RFM. We will take the open source project JHotdraw as the example to display the process of SWD with FOP and RFM, and the combination format of FOP and RFM. We will realize the reconstructions of ten successive releases of JHotDraw. We will also analyze and summarize the implementation issues existing in the process. Chapter 4 In this chapter we at first analyze and summarize the interesting situations in the evolution processes of different programs. Then we will evaluate the consequences of using SWD techniques in the process of software evolution based on the results of different programs. Chapter 5 According to the case study, we present the concept of an extension of Jak language, with which many limitation of Jak could be eliminated. Chapter 6 Finally, we will present the related work, conclusions and the further work about the SWD with FOP and RFM.

21 Chapter 2. Background 5 Chapter 2 Background In this chapter, we describe the theoretical background for the remaining part of work. We first review the software development process and SWD. Then we review FOP and its related concepts, such as AHEAD model, Jak language and ATS. Afterwards we will explain what RFM are and the related theory. 2.1 Software Development Process SWD is a software development method, so we at first review the relative concepts of software development, such as the software development activities and models for software development process Software Development Activities A software development process is a structure imposed on the development of a software product [53]. It involves the following activities [1]: (1) Requirements analysis: The most important task in creating a software product is extracting the requirements of the desired software product. Customers typically have an abstract idea of what they want, but not what software should do. The skilled and experienced software engineers can recognize incomplete, ambiguous or contradictory requirements [15]. (2) Specification: Specification is the task of writing the precisely description of the software. Specifications are most important for external utilities that must remain stable. [33] (3) Architecture: Software architecture is an abstract representation of a system. Architecture is concerned with ensuring the software system will satisfy the requirements of the product, as well as making sure that future requirements and the interfaces between the software system and other software products can be addressed. [17] (4) Implementation: Implementation is the process of transforming a design to code based on a programming language. It may be the most obvious part of the software engineering, but it is not the largest portion. [51]

22 Software Development Process (5) Documentation:Documenting is an important task to record the internal design of software for the purpose of future maintenance and enhancement. [25] (6) Testing: Software testing is an important part of the software development process. The testing process ensures bugs are recognized as early as possible. [14] (7) Maintenance: Software maintenance is the modification of a software product after delivery to cope with newly discovered problems, to improve performance or other attributes, or to adapt the product to a modified environment. [31] Software Development Models Software development process is a systematic process consisting of various stages during which software is developed. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. The following enumeration introduces some process models. Waterfall Model Figure 2.1: Waterfall model The waterfall model is a sequential software development process, in which the progress is seen as flowing from the top to the bottom, like a waterfall. The original Waterfall Model was proposed in 1970 by Winston W. Royce [56]. The waterfall Model shows a software development process with the phases of Requirements, Design, Implementation, Integration, Testing, Installation and Maintenance, as shown in Figure 2.1. The Waterfall Model maintains that one should proceed to the next step only when a step is completed. The waterfall model is the most

23 Chapter 2. Background 7 structured of the methods, stepping through pre-planned sequence in a strict, so that it is difficult to react to changes in requirements. Iterative process Iterative development is also called incremental development [42]. It is a cyclic software development process. Iterative development is developed in response to the weaknesses of the waterfall model, and has higher success rate and productivity [41]. As shown in Figure 2.2, it starts with an initial planning and ends with deployment with the cyclic interaction in between. The main idea of iterative development is to develop a software system incrementally, and the developer can benefit from what was being learned during the development of earlier, incremental, deliverable versions of the system. The main steps in the iterative development process are to start with a initiative simple implementation of a part of the software requirements and incrementally increase the evolving sequence of versions until the whole system is implemented. At each iteration, the design of software is modified and new functions are added. Figure 2.2: Iterative model Iterative development is the foundation of many software development methodologies, such as the Extreme Programming [28], the Agile Software Development [45], the Rational Unified Process [37] and the Dynamic Systems Development Method [59]. In this thesis, we study on the method SWD, which belongs to the Agile Software Development. In the following items, we introduce the Agile Software Development and one of the agile methods Extreme Programming, which also uses refactorings in the software development process [61]. Agile Software Development Agile Software Development is a software development method, which was coined along with the formulating of Agile Manifesto in the year 2001 [34]. Agile Software Development Processes involves a group of a software development methodologies that are built on the foundation of iterative development. In agile processes developers not use planning, but using feedback, which is driven by regular tests and releases of the evolving software, as their primary control method [41]. Most agile methods have more efficient than older iterative methodologies. As opposed to non-agile, agile methods more emphasis on the close collaboration

24 Feature Oriented Programming between programmers and business experts, face to face communication (that is more efficient than written documentation), frequent delivery of new software versions, compact and self-organization team, coding and team organizational methods that can be well adapted to the changing requirements [45]. In this models development periods are measured in weeks rather than moths, agile methods even more emphasis on software development as a human role and emphasize the high cooperation of teams. Agile methods are applicable to the software that demand the rapid reaction to changes in requirements and the high cooperative of people and developers. Extreme Programming Extreme Programming (XP) is one of several popular Agile Processes. Its intention is to improve software quality and responsiveness to changing customer requirements [28]. It advocates frequent releases in short development periods. Coding, Testing, Listening and Designing are four basic activities of XP. Compared with traditional methods of project development, XP emphasizes that many of its practices (such as practice of test-first development, planning and writing tests before each micro-increment [41]) are made to extreme levels, and the other practices (such as the overall design in the earlier period of development etc.) that XP are not promoted will be totally ignored [11]. XP is similarly to spiral development approach, it decomposes the complex development process into several small cycles through active communication, feedback and a range of other methods. Programmers and customers can clearly hold the progress, change, potential difficulty of development, so that they can adjust the development process according to the influential issues [12] Stepwise Development In this thesis, we focus on the step of implementation. SWD is a powerful paradigm for developing a complex program from a simple program by gradually adding increments, which are called feature refinements [10]. A feature refinement usually encapsulates not sets of complete classes, but fragments of multiple classes. Figure 2.3 shows the relationship between classes and refinements. b is a base feature, which includes three classes c1, c2, c3, and r1, r2, r3 are three feature refinements, which cross-cut the three classes c1, c2, c3. Each of the refinements r1, r2, r3 encapsulates fragments of c1,c2,c3. According to SWD, we can incrementally add feature refinements r1, r2, r3 to b to develop a new program. There are many SWD techniques, such as component, refactoring, FOP, AOP. In this thesis, we focus on refactoring and FOP, which will be introduced in next sections. 2.2 Feature Oriented Programming Informally, a feature is a salient part of an object. There are many kinds of expressions for what a feature is in the software engineering literature. All these expressions of features are valid and relevant for different stages of software development [29] [40][20]. In this

25 Chapter 2. Background 9 Figure 2.3: Classes and Refinements thesis we focus on the definition: a feature is an increment in program functionality, which in feature-oriented design is implemented by a feature module Feature Module With the concept of stepwise refinement feature modules gradually add classes to a program, or add members to classes, or extend methods of classes. A set of feature modules, which are combined together is a feature model. A feature model can be represented as a feature diagram, in which all the features of a domain and the relationship of the features can be described. The relationship between a parent feature and a child feature is either mandatory or optional. Furthermore, when a feature has multiple child features, there are three different relationship types between them: and, alternative, or. Figure 2.4 shows the notations of the relationships in feature diagram. The following is a simple description of the relationships [44]. Optional - features that are optional Mandatory - features that are indispensable And - all child features must be selected Alternative - only one child feature can be selected Or - one or more child features can be selected Figure 2.4: Relationships of Features A feature diagram is a tree with the leaves and interior nodes. Figure 2.5 is a simple feature diagram. It defines a product-line rooted from A. A is a compound feature that contains two mandatory features B and D, and a optional feature C. B is an alternative

26 Feature Oriented Programming feature that only one of E, F, and G can be present in an application. D is a or feature that one or more features of H, I, and J can be present. Figure 2.5: Feature Diagram GenVoca and AHEAD GenVoca is a model where transformations are functions incrementally applied on programs [9]. GenVoca defines feature refinements as increments, and a complete program is composed of a set of refinements. Figure 2.6: GenVoca constant and function In GenVoca, Programs are constants and refinements are functions that add features to programs [10]. A program can be converted into a new program through the action of refinements. Figure 2.6 shows the representation of constant and function. A GenVoca constant (like e) is a set of classes. The constant e represents a program with feature e, if we add feature f to program e, it can be represented as: f(e), where e is a constant and f is a function. Furthermore, we can express a multi-featured application app as an equation, e.g., app=g(f(e)), denotes the program app has features g, f and e. Figure 2.7: GenVoca model Figure 2.7 shows the result of applying function f to e, and function g to f(e). The constant e encapsulates three classes a1, b1, c1. The function f(e) refines the classes

27 Chapter 2. Background 11 a2 and c2, and adds class d2. The function g(f(e)) refines the class c3. The linear chain e, f, g is called refinement chain, in which only the bottom-most classes (shaded in Figure 2.7) are instantiated, because these classes implement all capabilities. For example, the bottom-most class of the c refinement chain implements the capabilities defined in c1, c2, and c3 from features e, f, and g respectively. Stated another way, c1 is a class (constant) and c2 and c3 are class refinements (functions). So the classes can be expressed respectively as a=a2(a1), b=b1, c = c3(c2(c1)), d=d2. AHEAD (Algebraic Hierarchical Equation for Application Design) is the generalization of GenVoca. It generalizes GenVoca by considering features as hierarchical modules that can include other artifacts besides source code [10]. GenVoca expresses only the code representation of an individual program as an equation. As the successor of GenVoca, AHEAD expresses a set of programs and all representations as nested sets of equations. Generally, a program has many artifacts except source code, such as makefiles, documents, HTML files. AHEAD is the model to deal with all these representations. Figure 2.8 depicts an AHEAD model with constant i and function j. In consideration of the artifacts in AHEAD models, the constants are not only programs, but a set of base artifacts with different types (e.g. a i, b i, c i ), and the functions are refinements of the different artifacts. So the constant can be defined as a set of constants: i={a i, b i, c i } The function can be defined as a set of functions: j={a j, b j, d j } The notations of AHEAD are also extended to represent the constant and function sets. We use j i to denote the composition of j with i instead of j(i) in GenVoca. So j i can be represented as nested sets of equations: j i={a j, b j, d j } {a i, b i, c i }={{a j a i }, {bj b i }, c i, d j }. Figure 2.8: Constant and function sets In AHEAD model, a set of artifacts are composed by composition operators, and the artifact types are different, each representation of the artifact is written in its own language or Domain-Specific Language (DSL). For example, the code representation of a program may be represented in an programming language, a makefile representation may be an XML file. When a refinement is applied on a program, many or all of the

28 Feature Oriented Programming program s artifacts may be updated. It is undesirable to build a big generator to deal with all possible artifacts. Figure 2.9 shows a tool-composer, that can submit the whole equations to separate type-specific composition tools to generate the artifacts of the target system. Figure 2.9: Composer tool ATS ATS is a collection of java-based tools that implement the AHEAD theory [7]. ATS features also contain several types of non-code artifacts, but in this thesis, we focus on.jak files, which are written by Jak language. For example in Figure 2.11, there are four.jak files. composer is a tool of ATS, it invokes a variety of tools to compose different artifacts. jampack and mixin are two tools to compose the.jak files of different layers. Figure 2.10 shows the process of using jampack or mixin to compose.jak files, and then using jak2java to translate.jak file to.java file. We will specifically introduce the usages of these tools in the practical application process. Figure 2.10: Composing and Translating Jak files jampack and mixin are two composition tools. Figure 2.11 shows the different composition results with jampack and mixin. The class constants and functions are defined inside Jak files. Figure 2.11(a) shows a class Animal, which belongs to layer F1. Figure 2.11(b) shows the refinement of the class Animal, which belongs to layer F2. The refinement of the class Animal adds a new data member weight and a new method eat, and extends the method sleep. The composition result of using jampack is shown in Figure 2.11(d). All the package imports, data members, and methods are composed in one class. The composition result

29 Chapter 2. Background 13 of using mixin is shown in Figure 2.11(c). All the package imports, data members, and methods that in the refinement chain are composed in a.jak file, which has an inheritance hierarchy. The bottom-most declaration (like class Animal in layer F2) is concrete and all others are abstract (like class Animal in layer F1). The different composition results of jampack and mixin will cause different programs in practice, that will be referred in our case study. Figure 2.11: Mixin and Jampack The Jak Language The programs in FOP are written in Jak language, which is an extension of Java language [10]. In the following the extended features in Jak are illustrated. Refinement: Jak uses the keyword refines to indicate the incremental feature code of a class. In Figure 2.12, Base/figure.jak defines a base interface Figure, the keyword refines in Zvalue/figure.jak indicates it is a refinement of the interface

30 Feature Oriented Programming Figure. Figure 2.12: Examples of Jak keywords Feature containment: Jak uses the keyword layer to define which feature an incremental function belongs to. In Figure 2.12, Base/figure.jak belongs to layer base, Zvalue/figure.jak belongs to layer zvalue. Super construct: This construct has two kinds of explanations: (1) Super appears in a base class and has the same meaning as in Java. super can not be recognized by ATS tools. Both jampack and mixin will report an error whenever super is used. (2) Super appears in a class refinement as a keyword of Jak language. Its form is as follows: Super(paramtypes).method(actparams) Super(paramtypes) prefaces a Super call, that invokes the previously defined method in the refinement chain, paramtypes lists the argument types of the method to be called, actparams lists the actual parameters of method. Constructor refinement: As a special method, constructor can be extended with a special declaration in Jak. Figure 2.13 shows a extension of the class Figure. It adds a new member test and refines the integer constructor to initialize this member. Figure 2.13: Example of constructor refinement New modifier: A refinement with the modifier new means that the refinement introduces a new method, and the name of the new method should not be used by any

31 Chapter 2. Background 15 previously defined method in a refinement chain. The expression in Figure 2.14 is not correct, because the method draw is already defined, jampack will report an error. Unlike jampack, mixin ignores the new modifiers, and does not report errors. Figure 2.14: Error with new modifier Overrides modifier: A refinement with the modifier overrides means that the refinement overrides an existing method. When the method has not been defined, jampack will report an error, while mixin ignores the overrides modifiers. 2.3 Refactoring Feature Modules Refactoring is an important SWD technique. It is widely used in the evolution process of software to reconstruct successive releases. In this section, we introduce the concepts of refactoring [46] and RFM [39] Refactoring Refactoring is a process of transforming the architecture of program without modifying its external functional behavior. It can improve software s quality, performance, extensibility and maintainability [46]. The major factor affects software is: demands transformation. Software always is produced to meet some kind of specific demands, but the customer s demands are transforming all the way. In the software s life cycle, some demands are relative stable, but some demands transformation is quite large, and even some demands have vanished or transformed to other new demands. In these cases, the software must be transformed correspondingly to the transformed demands. This lead to a bad phenomenon: the software product, which was elaborate designed with good structure, must be transformed to meet new demands, and it will cause problems for the software architecture, such as some new bugs are difficult to remove, the new demands are difficult to be achieved. Finally the development cost for the new demands will exceed the cost of developing new software. Refactoring is one method that can avoid the above-mentioned phenomenon. Refactoring is a kind of transformation that maintains the behavior of the software. It is a method to improve the internal structure of software. Refactoring process involves remove the duplication, simplify the complex logic and clarify the ambiguous code and so on. In the process of refactoring, the main task is to determine code smells of the program [46]. We should find out those code smells and then reconstruct the code with refactorings, and in this process ensure the visible behavior of software does

32 Refactoring Feature Modules not make changes. In the following are some code smells that need to be refactored [46]. Existing duplicate code Duplicate code will cause to produce inefficient software. So we need to refactor the code to remove the duplication. If two methods have the same code block in the same class, the code block can be refined as an independent method of the class. Too large classes or methods Too large classes are often caused by an irrational definition of class, which may reduce the reusability of the code. Too long methods are often caused by complex logic, and it may raise the error rate and decrease the readability. Briefly, too large classes or methods may reduce the flexibility of the software. Thus, we need to use the relative refactoring methods to divide a large class into small classes or divide a long method into small methods. Too many communications between classes When class A needs to call too many methods of class B to access the internal data of class B, the relationship between the two classes is too close. Perhaps the communication of these classes is better than separation of these classes. Of course, there are also many situations need to be refactored, and each situation has a corresponding refactoring method. Martin Fowler proposed software refactoring rules based on summing up his related works. According to his relevant experience he summarized 72 classics refactoring methods in his book Refactoring: Improving the Design of Existing Code [46]. These refactoring methods involve many aspects, such as reorganization of function, characteristic migration between the objects, reorganize the data, simplify condition expression, simplify function call, handle the generalized and the specialized questions. We can achieve many purposes through refactorings, such as improve software design, make code easier to understand, discover hidden defect Refactoring Feature Modules In FOP, a feature is an increment in program functionality, which is implemented by a feature module. Customers can synthesis a set of feature modules to derive a efficient program without knowing the program s implementation. But there may be conflicts when the program is combined with another program, and the programs need to be reconstructed in the process of software evolution [39]. Object-oriented refactoring is a method to remove conflicts caused by classes and members in the software evolution process and to improve the software s extensibility and maintainability [46]. RFM are to define refactorings in refactoring units and encapsulate these refactoring units in feature modules, which are special feature modules that combine refactoring technique and feature-oriented design [39]. Each refactoring unit in feature modules is a class-like entity that implements a refactoring interface. Figure 2.15 shows a RFM with a refactoring unit RenameClassRefactoring, which rename the class List to LinkedList. It implements

33 Chapter 2. Background 17 Figure 2.15: RenameClassRefactoring in RFM the refactoring interface RenameClassRefactoring and declares the getter methods getoldclassid() and getnewclassname(). The method getoldclassid() returns the identifier of the class to rename and getnewclassname() returns the new class name. Figure 2.16: Feature diagram with refactoring features Figure 2.17: The class List Figure 2.16 shows a feature model with refactoring features. M1 and M2 are two feature modules, M3 is a refactoring feature module. In a feature model, we can select them but not distinguish between them. A feature module can encapsulate one or more refactoring feature modules. In the Figure 2.16 the feature module M3 is a composite feature module, R1 and R2 are nested in the feature module M3. We use a simple example to introduce the usage of RFM. Figure 2.17 shows the class List, which is encapsulated as basic feature. Figure 2.18 shows three refactoring feature modules, which will apply in the basic feature. R1 renames the method get() in class List to pop(). R2 renames the class List to LinkedList. R3 renames the method pop() in LinkedList to topmost(). Figure 2.19 shows the composition result of the basic class List and the RFM R1, R2, R3, we can see that all the three refactorings are achieved successfully.

34 Refactoring Feature Modules Figure 2.18: Refactoring feature modules R1,R2,R3 Figure 2.19: Refactored class LinkedList

35 Chapter 2. Background Summary We have reviewed the software development process and SWD. We have also introduced two SWD techniques FOP and RFM, which are the focus of this thesis. For FOP, we have introduced the models GenVoca and AHEAD, and showed how to develop an individual program with the theories of the models. We also introduced the ATS and the Jak language. Then we introduced the concept RFM and showed how the refactoring feature modules are integrated into FOP.

36 Summary

37 Chapter 3. Stepwise Development with FOP and RFM 21 Chapter 3 Stepwise Development with FOP and RFM Following the software development process, developers usually at first develop a prototype system, then modify and improve the system by adding next features according to the users requirement [43]. In this chapter, we will introduce the SWD process with FOP and RFM, and at the same time we pay attention to the existing problems in the evolution process. 3.1 Tool Support In this section we will introduce the program development environment of FOP. We will also introduce a comparison tool, which is useful for the case study. ATS is a suite of tools that base on the AHEAD model of FOP. the programs of FOP are written in Jak language. In order to build the program development environment, we need to install a set of tools. As shown in Table 3.1, JDK 1 is a development environment for building applications, applets, and components using the Java programming language; Cygwin 2 makes the Linux-like environment in Windows; Ant 3 is the Java building tool; AHEAD tool suite 4 provides the support of ATS tools. Beyond Compare 5 is a folder and file comparison tool. It can be used to compare two folders or files and find out the difference between them. In our case study, we need to compare the source code of different versions

38 Introduction of Cases Table 3.1: Tools list of development Environment Name Version Function 1 JDK ea Java Development Kit 2 Cygwin Linux-like environment for Windows 3 Ant Pure Java build tool 4 AHEAD Support ATS commands 5 Beyond Compare 3.0 Professional folder and file comparison tool 3.2 Introduction of Cases In order to obtain a reasonable result, we evaluate the consequences of using SWD techniques in different non-trivial software products. The cases should include various scales software products, not only large software but also small software. Table 3.2 lists the open source software projects that will be taken as study objects. Table 3.2: Projects for cast study Project Release-Steps Nr. of LOC steps 1 Beck XML Mapper 2 POJava ZK-Google Maps Euclide Cobertura TrueZip Java DjVu Viewer JHotDraw b1 5.4b2 6.0b HyperSQL rc4 rc Beck XML Mapper constructs Java objects from an XML document, or generates an XML document from Java objects. The mapping is configurable (via XML) and customizable (in Java)

39 Chapter 3. Stepwise Development with FOP and RFM 23 POJava is a simple, light-weight Java-based API for rapid application development 7. ZK-Google Maps has integrated the Google Maps into a gmaps ZK component, so developers can now use this originally javascript component with pure Java code 8. Euclide is a dynamic geometry application written in Java. It allows the creation of geometric shapes (lines, points, circles, conics...) and transform actions (rotation, symmetry...), which depend on each other 9. Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of a Java program lacks test coverage 10. TrueZIP is a Java based Virtual File System, which enables client applications to access ZIP, TAR and derivative archive types transparently as if they were just directories in a file s path name 11. Java DjVu Viewer is an open source implementation of DjVu viewer, which has different functions including an applet and standalone viewer 12. JHotDraw is a GUI-based editor, which includes lots of functionality of the tool palette, different views, user-defined graphic elements, as well as the save, load and print images. Users can customize the application framework through inheriting or combining components 13. HyperSQL is like a doxygen for SQL, hypermapping SQL views, packages, procedures, and functions to HTML source code listings and showing all code locations where these are used