Workshop on Software Evolution

Proceedings of the Third International

Edited by Tom Mens, Kim Mens, Ellen Van Paesschen, Maja D'Hondt

2007 Technical Papers

2007

ECEASST

Reuse-Based Analysis of Open-Source Software Component Evolution and Its Application to Version Control *

Liguo Yu 1, Kai Chen 2 and Srini Ramaswamy 3

1. Computer Science and Informatics, Indiana University South Bend, South Bend, IN 46615, USA. Email: [email protected] 2. Motorola Incorporation, Schaumburg, IL 60196, USA. Email: [email protected] 3. Computer Science Department, University of Arkansas at Little Rock, Little Rock, AR, USA. Email: [email protected]

Abstract: Software evolution and configuration management are two important issues of software project management. This paper applies a two-dimensional reuse-based evolution model, which describes the evolution of an individual component from two perspectives (white-box reuse and black-box reuse), in the version control of open-source components. In the case study, we investigate the evolution of twelve Linux kernel components and explain how the reuse-based evolution model can facilitate configuration management of Linux kernel components.

Keywords: Component Evolution, Version Control, Open-Source Software

1 Introduction Software evolution [1] [2] is a process that a software system changes from a simpler or worse state to a higher or better state [3]. Since changes need to be made on software to fix defects or to satisfy new requirements, its evolution is inevitable. It is originally considered, and still commonly agreed on, that the evolution process of a software system is a maintenance process of that system. On the other hand, software reuse always occurs in software evolution, which could be an ad hoc small scale reuse or a systematic large scale reuse. Therefore, software evolution can also be considered as a reuse process. Traditionally, the reuse and maintenance processes are considered as two different processes. The reuse process is usually considered as occurring in software development: reusable components are identified and adapted to the new system. The maintenance process is considered occurring during software evolution — change to the software product after it is delivered. Therefore, for the develop- then-evolve model of closed-source software development; reuse, which happens during development, and maintenance, which happens during subsequent evolution, are largely viewed as two independent processes. Recently, open-source software, i.e., the software program whose source code is available under a copyright license that permits users to freely study, change, and utilize, has growing impacts on both the software engineering community and our society. Because of its importance, a lot of research has been performed to study the evolution patterns of open-source software [4] [5]. The evolution process of open-source software is different from that of closed-source software. Usually, the documentation of

* An earlier version of this paper appears in the 18th International Conference on Software Engineering and Knowledge Engineering.

2 / 11 Volume X (2007)

Short Article Title open-source software on requirement, analysis, and design is limited and incomplete [6]. The quality assurance of open-source software is not achieved through systematic testing by the programmers. Instead, it is the feedback of users that usually contributes to the quality improvement of open-source software. Accordingly, open-source software is characterized by the philosophy, “release early and release often” [7]. For example, from 1994 to 2006, Linux has released over 500 versions. Due to the frequent update of open-source software, an evolution process is also a development process. In the develop-and-evolve model of open-source software, the software reuse, which usually happens during development, is mixed with software maintenance, which usually happens during evolution. Therefore, considering software evolution as a reuse process is especially important for research on open-source software systems. On the other hand, configuration management is a disciplined approach to manage the evolution of software and its components [8] [9] [10]. One of the most important issues in configuration management is version control (also called revision control or source control), which manages multiple revisions of the same unit of information. Examples of traditionally widely used version control systems are CVS [11] and PRCS [12]. In previous work [13], we investigated the evolution of open-source software components from the reuse perspective and proposed a reuse-based evolution model. In this paper, this model is applied in version control of open-source software components in order to improve their configuration management and evolution process.

2 Software Component Evolution and Version Control Software evolution is a process of making changes to software artifacts in order to improve their functional or nonfunctional requirements. The evolution of a software product consists of the evolution of its individual components. Because closed-source and open-source software systems have different properties, the evolution processes of their corresponding components are also different. This accordingly influences their selections of version control techniques.

2.1 Closed-source component evolution and version control Basili [14] first proposed three evolution models for closed-source software: quick-fix, iterative- enhancement, and full reuse-models. All these models consider reuse as the major activity in software development. They are reuse-oriented software development models and lay the foundations for component-based software development (CBSD). Both Basili’s reuse models and the latest CBSD model require complete documentation of requirement, analysis and design, which is a property of closed-source software. However, these software development models do not fit in well with open- source software, because (1) open-source software does not have complete documents on requirement, analysis, design, and systematic testing; (2) open-source software does not promote planned reuse, there is no artifact repository for open-source software. Just like the traditional software development, reuse-based closed-source software development (either CBSD or product line) also needs configuration management because a component or a product may have many versions. Considerable research has been performed to study configuration management in CBSD. For example, Mei et al. [15] proposed a configuration model by analyzing the objects that need to be managed in order to improve the CBSD process. In their model, components, as the integral logical constituents of a system, are managed as the basic configuration items. Relationships

Proc. Software Evolution 2007 3 / 11

ECEASST between/among components are defined and maintained to support version control of large objects and logical modeling of system architecture. Generally, in reuse-based software development, a linear structure is used in version control of software components. Figure 1 shows an example demonstrating the evolution of three components (C1, C2, and C3) in a repository. In the figure, each component is versioned separately because components in closed-source component-based software are usually independent, which makes them easy for adaptation and reuse. Branching and merging also happen in the evolution process of the component C3, where version V1.1 is branched into two versions, V1.2 and V1.1.1, and version V1.3 and version V1.1.3 are merged into a single version V2.0.

Figure 1. The versioning scheme of components in closed-source component-based development.

The versioning scheme shown in Figure 1 fits well in closed-source component-based software development, because an individual component in closed-source component-based software has few dependencies on others (except for the inclusive relationship, such as C1 is part of C2) and evolves independently.

2.2 Open-source component evolution and version control As mentioned before, open-source software is characterized by the frequent release property [5]. Although it has many versions, each new release is based on a previous release. Its evolution can be modeled as an evolutionary streamline. For example, suppose an open-source software product has nine consecutive versions, V1 through V9. Its evolution can be represented as a one-dimensional streamline shown in Figure 2. To simplify the problem, in this paper, we ignore the branching and merging of software versions and only consider consecutive versions.

Figure 2. One-dimensional evolution process for open-source software [13].

Figure 2 shows the evolution of the entire software system from a maintenance perspective. Every new release (version) is based on the modification of the previous version, which is a widely accepted view of open-source software evolution. A more complete model may include version branching and merging, which will be a two-dimensional tree structure. However, both the one-dimensional streamlined model and the two-dimensional tree model are maintenance-based and the reuse process is largely ignored. Most importantly, the model in Figure 2 only captures the evolution process of the product as a whole. However, different components within the product may evolve differently. For example, while

4 / 11 Volume X (2007)

Short Article Title some components may never be changed, others may be changed several times during the same period. Therefore, the maintenance-based evolution model for open-source software does not represent the evolution of individual components accurately. In fact, an open-source software product may have many versions and the individual components of a product may also have many sub-versions. Hence, it is important for open-source software to have an efficient version control system. Here, we review the version control of three leading open-source software systems, Linux [16], FreeBSD [17] and Apache HTTP [18], where different versioning schemes are employed. In Linux, all components share the same version number with the product. A new product release not only results in a new version number for the entire product, but also results in a new version number for each component. Figure 3 shows the versioning scheme of Linux, in which the dashed arrow is utilized to indicate that the difference between two consecutive versions of the same component is not clear. In other words, we do not know if a component has been changed in a new release or not. Hence, this versioning scheme has the following drawbacks: (1) we cannot determine whether a component has been changed in a new release merely by the version number of the component, because the version number of a component will always increase no matter whether the component is changed or not in a new release; (2) we do not know which components are modified together in one release. Because components in open-source software are usually not designed for reuse, there are many interdependencies among components: changes of one component may require changes of other components at the same maintenance activity. Therefore, the information on which components are modified together is especially useful for predicting change propagations in open-source software [19] [20].

Figure 3. The versioning scheme of Linux.

Figure 4 presents the versioning scheme of FreeBSD: the version of each individual component is managed separately from that of the entire product. The solid arrow in the figure indicates that two versions of the same component are different. The version number of a component will be updated only when the component itself is changed. The product has its own version number, which is independent from the version number of its components. One version of the product may consist of different versions of components. For example, as shown in Figure 3, three components (C1, C2 and C3) in the product version V2 have three different version numbers (V4, V3 and V5, respectively). This versioning scheme solves the first drawback of the Linux versioning scheme, but it still fails to indicate which components are modified together in one maintenance activity. Figure 5 describes the versioning scheme of Apache HTTP Server: each maintenance activity is assigned a revision number. All components modified in the same maintenance activity are given the same revision number. If a component is not involved in a maintenance activity, it keeps its original revision number. In this scheme, the revision number of a component may be discontinuous and a component is assigned a new revision number only if it is modified during a maintenance activity. The

Proc. Software Evolution 2007 5 / 11

ECEASST advantage of this scheme is that, from the revision numbers of the components, it is easy to determine which components are modified together. However, the revision number of a component has no relation with the version number of the product. It is difficult to know whether two components appear in the same product release or not just according to their revision numbers.

Figure 4. The version scheme of FreeBSD.

Figure 5. The versioning scheme of Apache HTTP.

Based on the previous discussion, we can conclude that the three leading open-source software use the similar one-dimensional version scheme adopted from closed-source software. However, as we have discussed above, all of them have certain weaknesses in configuration management of open-source software.

3 Reused-Based Evolution Model A software system consists of a collection of components. Our study of open-source software evolution is component-oriented, which means we are more interested in the evolution of individual software components. Software reuse always happens in the software evolution process. In each release, some components are modified, others may remain unchanged. In order to study software evolution from the perspective of reuse, we proposed a two-dimensional reuse-based evolution model [13], in which the reuse of software components is classified into two categories: white-box reuse and black-box reuse . In one software evolution step, which is marked by a new version release, components that are modified in the new release are classified as white-box reuse while those unchanged are classified as black-box reuse. Therefore, the evolution of a component in the software lifetime can be represented as a trace of a two- dimensional diagram. Figure 6 shows the evolution of a component C1 in nine consecutive versions of the software. The value in the vertical axis indicates how many times a component is black-box reused, while the value in the horizontal axis gives the times that a component is white-box reused in the research period.

6 / 11 Volume X (2007)

Short Article Title

V8 V9

V4 V5 V6 V7 box reuse box

Black

V1 V2

White -box reuse Figure 6. The reuse-based evolution model for component C1 in nine versions of the product [13].

Different components in a product may be modified in different evolution steps. Accordingly, they may have different evolution traces. The reuse-based evolution model depicts the evolution trace of each individual component instead of the entire product. Compared to the maintenance-based model, this reuse-based model has the following advantages: (1) the vertical steepness of a component trace indicates the potential that this component can be reused without change. Therefore, by studying the reuse-based evolution of software components, we can identify potential reusable components; (2) reuse-based evolution model incorporates the maintenance process, because white-box reuse of a component also depicts the maintenance history of a component. In fact, our reuse-based evolution model for open-source software components can be applied in version control. Here, we propose a two-dimensional versioning scheme derived from the reuse-based evolution mode. In this scheme, the version number of a component is a 2-tuple (x, y), where x records the number of the white-box reuse and y denotes the number of the black-box reuse. We use two components C1 and C2 shown in Figure 7 as an example to explain how this versioning scheme works. The dashed line indicates the release of a new version of the whole product. In each new release, every component will be given a new version number. If a component is modified in the new release, the x value will be increased by one while the y value will remain unchanged; otherwise the x value will remain unchanged while the y value will be increased by one. This two-dimensional versioning scheme has the following advantages: • It is easy to judge whether a component is modified or not in different versions of a product from the version number of the component. For example, the source code of C1(2, 2) and C1(2, 5) is same because the x values of their version numbers are equal, while the source code of C1(2, 6) and C1(3, 6) is different because the x values of their version numbers are different. • It is easy to judge the relationship between the component version and the product version. The component with the version number (x, y) is included in the product whose version number equals x+y-1 (suppose the product is versioned sequentially). For example, C1(4, 2) is included in the 5th version. • It is easy to judge which versions of two components should appear in the same release. If two components have the same total version value (x plus y), they must appear in the same release. For example C1(3, 1) and C2(2, 2) are in the same product release. • It is easy to judge whether two components are modified together in the same release. For example, in Figure 7, C1(4, 2) and C2(2, 4) are modified in the same release because they appear in the same product release and their x values are increased in the next product release.

Proc. Software Evolution 2007 7 / 11

ECEASST

Figure 7. Two-dimensional versioning scheme.

To summarize, our reuse-based versioning scheme can solve some drawbacks in the existing versioning schemes used by Linux, FreeBSD, and Apache HTTP; and aid in the process of studying open-source software systems evolution.

4 The Evolution of Linux Kernel Components Linux, which is one of the most active open-source projects, has released about 600 versions. A lot of research [5] [7] has been performed on the evolution pattern of Linux, including the growth of size, changes of kernel structure, and community properties. From version 1.0.0 to version 2.6.11, there are 597 formal releases of Linux. If considered as a maintenance process, the evolution of the whole Linux product can be represented as a streamline with 597 nodes (again, we ignore the branching and the merging). Due to the simplicity of this streamline structure, it does not provide much useful information about the evolution pattern of Linux. Therefore, we need to study the evolution of individual components using the two-dimensional reuse-base evolution model (Figure 6) described in Section 3. The most important components in Linux are kernel modules (components), which contain the key functions of the operating system and are architecture independent. The Linux 1.0.0 version has 23 kernel modules. In the evolution process, some kernel modules are removed, while some new modules are added. In version 2.6.11, there are 58 kernel modules, in which only 12 modules continuously evolve from version 1.0.0. This means 12 kernel modules have experienced the entire evolution of Linux. Our next step is to study the evolution of these 12 kernel modules in all 597 releases. Our research investigates the entire evolution history of Linux. First, the 597 versions are indexed from 1 to 597, which are shown in Table 1. Next, we consider the evolution of these 12 kernel modules from the perspective of reuse. Table 2 shows the number of white-box reuse and black-box reuse of the 12 kernel modules in 597 releases. It indicates that dma.c has the smallest number of white-box reuse, while sched.c has the largest number of white-box reuse.

8 / 11 Volume X (2007)

Short Article Title

Table 1. The version index of Linux [13].

Version 1.0 1.1 1.2 1.3 2.0 2.1 2.2 2.3 2.4 2.5 2.6 Index 1-12 13-108 109-122 123-223 124-264 265-397 398-424 425-477 478-509 510-585 586-597

Table 2. The number of white-box reuse and black-box reuse of 12 kernel modules [13]. Number of m1 m2 m3 m4 m5 m6 m7 m8 m9 m10 m11 m12 White-box reuse 21 165 196 26 97 48 86 41 234 110 149 63 Black-Box reuse 576 432 401 571 500 549 511 556 363 487 448 534 Key to modules: m1: dma.cl; m2: exit.c; m3: fork.c; m4: itimer.c; m5: module.c; m6: panic.c; m7: ptrintk.c; m8: ptrace.c; m9: sched.c; m: signal.c; m11: sys.c; m12: time.c

Figure 8 presents the evolution traces of the 12 kernel modules using the two-dimensional reuse- based evolution model. From the figure, we find that the traces of dma.c, itimer.c, ptrace.c and time.c have longer vertical paths than the others. This means these modules (components) have experienced more black-box reuse in the past, and it is also reasonable to assume that they possess more potential to be black-box reused in the future as well.

Figure 8. The evolution of 12 kernel modules from the perspective of reuse.

Furthermore, by observing Figure 8, we find that the recent versions of fork.c and sched.c are more frequently white-box reused than black-box reused. As we have mentioned before, kernel modules in Linux are most important and architecture independent. Hence, they should be designed with greater potential for reuse. According to our study of 12 kernel modules that have experienced the entire Linux evolution, each module has a different reuse history, which is probably due to the differences in its reusability. Because white-box reuse always requires more developer efforts than black-box reuse, to improve the evolution process and reduce the reuse cost of Linux, modules such as exit.c , fork.c , and sched.c may need to be redesigned to enable more black-box reuse.

Proc. Software Evolution 2007 9 / 11

ECEASST

In addition, by applying the two-dimensional versioning scheme, which is derived from the two- dimensional reuse-based evolution model, Figure 9 shows part of the versioning and evolution history of the 12 Linux kernel modules. For example, it shows product version 50 (1.1.36) contains sched.c (10, 41), fork.c (8, 43), exit.c (9, 42), sys.c (8, 43), signal.c (4, 47), module.c (3, 48), printk.c (1, 50), time.c (2, 49), panic.c (1, 50), ptrace.c (4, 47), dma.c (2, 49), and itimer.c (1, 50). It also shows sys.c is modified in the release of the product version 51 (1.1.37) because the x value of the version of sys.c is increased in this release.

Figure 9. Part of the evolution path of the 12 Linux kernel modules.

5 Conclusions and Limitations In this paper, we extended our previous work of studying the evolution of open-source software components from the reuse perspective and applied the two-dimensional reuse-based evolution model in version control of open-source components. The kernel modules in Linux are used as an application study. As with other research, applying the two-dimensional reuse-based evolution model to version control has its limitations. First, currently our model does not support branching and merging. It is common that one version of a component may branch to multiple versions while multiple versions may merge into a single version. Second, our model can be applied very well for open-source software systems, in which the components evolve with the entire software system. It does not perform well for software with component repositories, which is a major property of closed-source software systems,

10 / 11 Volume X (2007)

Short Article Title because each component in a component repository may evolve independently from other components and the entire software system.

6 References 1. M. M. Lehman, “Life Cycles and Laws of Software Evolution”, Proceedings of IEEE (Special Issue on Software Engineering) , 1980, pp. 1060–1076. 2. D. E. Perry, “Dimensions of Software Evolution”, Proceedings of International Conference on Software Maintenance , Sorrento, Italy, 1994, pp. 296–303. 3. [3] L.J. Arthur, Software Evolution: the Software Maintenance Challenge , John Wiley and Sons, New York, NY, USA, 1988. 4. M. W. Godfrey and Q. Tu, “Evolution in Open Source Software: A Case Study”, Proceedings of International Conference on Software Maintenance , San Jose, CA, 2000 pp. 131–142. 5. S. R. Schach, B. Jin, D. R. Wright, G. Z. Heller, and A. J. Offutt, “Maintainability of the Linux Kernel”, IEE Proceedings—Software, 149, 2002, pp. 18-23. 6. K. Chen, S. R. Schach, L. Yu, J. Offutt, and G. Z. Heller, “Open-Source Change Logs”, Empirical Software Engineering , vol. 9, no. 3, 2004, pp. 197–210. 7. E. S. Raymond, The Cathedral & the Bazaar , First Edition, O’Reilly, February 2001. 8. C. Burrows, G. George, and S. Dart, Configuration Management , Ovum Ltd., 1996. 9. S. Dart. Spectrum of Functionality in Configuration Management Systems , Technical Report CMU/SEI-90- TR-11, Software Engineering Institute, Pittsburgh, Pennsylvania, December 1990. 10. S. Dart, “Concepts in Configuration Management Systems,” Proceedings of the Third International Workshop on Software Configuration Management , ACM SIGSOFT, 1991, pp. pages 1–18. 11. Current Version System Website, http://www.nongnu.org/cvs/. 12. Project Revision Control System Website, http://prcs.sourceforge.net/ . 13. L. Yu and K. Chen, “Two Perspectives on Open-Source Software Evolution: Maintenance and Reuse”, Proceedings of the 18 th International Conference on Software Engineering and Knowledge Engineering. San Francisco, CA. July 2006, pp. 737–742. 14. V.R. Basili, “Viewing Maintenance as Reuse-Oriented Software Development”, IEEE Software , vol. 7, no. 1, 1990, pp. 19–25. 15. H. Mei, L. Zhang, and F. Yang, “A software configuration management model for supporting component- based software development”, ACM SIGSOFT Software Engineering Notes , vol. 26, no. 2, 2001, pp. 53 – 58. 16. The Linux Website, http://www.linux.org/ . 17. The FreeBSD Website, http://www.freebsd.org/ . 18. The Apache HTTP Website, http://httpd.apache.org/ . 19. A. T. T. Ying, R. Ng, M. C. Chu-Carroll, and G. C. Murphy, “Predicting Source Code Changes by Mining Change History”, IEEE Transactions on Software Engineering , vol. 30, no. 9, pp. 574–586. 20. T. Zimmermann, P. Weissgerber, S. Diehl, and A. Zellers, “Mining Version Histories to Guide Software Changes”, IEEE Transactions on Software Engineering , vol. 31, no. 6, 2005, pp. 429–445.

Proc. Software Evolution 2007 11 / 11 ECEASST

Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environments

Gautier Bastide1, Abdelhak Seriai2 and Mourad Oussalah3

1 [email protected] 2 [email protected] Ecole des Mines de Douai 941 rue Charles Bourseul, 59508 Douai, France

3 [email protected] LINA, Universit´ede Nantes 2 rue de la Houssini`ere, 44322 Nantes, France

Abstract: Deployment is a crucial issue for ubiquitous applications. In fact, due to the perpetual context-evolution, an application must adapt its deployment in order to guarantee its service continuity. In component-based software engineering, where applications are built using existing components, a ﬂexible deployment of components can be required in many cases as in resource-constrained environments where the software architecture must always match with the hardware architecture. To deal with this issue, we propose an approach aiming at generating a self-adaptive software component from an existing component. This property allows a component to adapt its deployment according to its current context. Keywords: Software component, deployment, restructuring, context-awareness

1 Introduction

For several years, ubiquitous computing and pervasive computing has emerged as a challenge ﬁeld for application design. In fact, due to the huge development of mobile devices, application designers have to take into account the execution context in order to adapt them. For example, a user’s device can have scarce resources, such as low battery power, slow CPU speed or limited memory. So, the application must be able to adapt itself to these constraints. In addition, more and more applications are created by assembling reusable parts. In Com- ponent Based Software Engineering (CBSE), an application consists of existing components [Szy98]. So, to be executed in ubiquitous environments where the context is perpetually evolving, a component must be able to adapt itself to its context from its deployment because of the volatility of device connection, resource-constrained, etc. Adaptation can concern component behavior or component deployment. Most existing work focuses on adapting component behavior and few works are related to the deployment adaptation. Moreover, a component is usually considered as a monolithic deployment unit. So, existing work related to application deployment focuses on the placement of components within an infrastructure. However, in many cases, it can be useful to be able to achieve a ﬂexible deployment of component services. To illustrate this, let us consider an example of a component which is deployed on a resource-constrained

1 / 11 Volume X (2007) Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environ- ments device included in a distributed infrastructure. Imagine that, during runtime, a sudden fall in the available memory involves a breakdown of its service continuity. Due to the disconnections of the user device, it cannot be envisaged to deploy the entire component on a remote site. So, the component can be adapted by redeploying some of its services on the available infrastructure. While being based on the above considerations, we propose an approach aiming at generating components whose structure can adapt itself according to its use context, from the existing component. This adaptation is achieved through a context-aware deployment of its services. We discuss our approach in the rest of this paper as follows. Section 2 presents the context- aware deployment of software components. Section 3 details the decision-making mechanisms. Section 4 reviews related works. Conclusion and future works are presented in section 5.

2 Context-aware deployment of software component services

2.1 Context-aware deployment overview Context-aware component deployment consists in deploying component services on selected sites in order to guarantee service continuity or to improve service quality. The site selection is achieved taking into account all context elements on which the component structure depends: Hardware architectural context: first, component deployment depends on the infrastructure technical features. In fact, a component service can be deployed on a site only when the resources required by this service are provided by this site. Besides, as some of these resources are perpetually evolving, they can become insufficient to ensure the continuity of services deployed on a site. So, these data must be used to initiate an adaptation process. For example, if the available memory becomes lower than a rate defined by the component designer, an adaptation phase has to be initiated in order to guarantee service continuity. Environmental context: second, the component deployment depends on its environment. In fact, services whose use probability is the highest have to be deployed on the user device or on its neighborhood when required technical features are enough to ensure service continuity. The use probability must be determined by comparing similarities between the user-target profile and the current user profile, and between the foreseen use-conditions and the current conditions. Neighboring nodes are determined according to infrastructure features (e.g. best bandwidth). This strategy can be useful in ubiquitous environments because of the connection volatility and the variations of network performances. Furthermore, the fixed devices must be privileged so as to limit the risks of connection/disconnection. So, the environmental context contains the user profile and the use conditions (i.e. data used to characterize the situation of users). Software context: finally, the component deployment depends on the component structure (e.g. existing components, connections) and behavior (e.g. service call, adaptation-release context). For example, in order to optimize the component execution, the component services which are closely dependent should be deployed on the same site. Once each service is associated with a deployment site according to the current context, the component must adapt its structure by generating new sub-components (i.e. fragmentation of the initial component) which provide each the services associated with a component. For example, figure 1 shows a component, called C1, which is deployed on a resource constrained device called site1. Let us consider that, during component runtime, existing load bal-

Proc. Software Evolution 2007 2 / 11 ECEASST

ancing has become unﬁt because of the deployment infrastructure evolution. In this case, C1 must adapt itself in order to guarantee service continuity. A solution can be based on fragment- ing the component into four new components called C2, C3, C4, C5 providing each a subset of services provided by C1. Then, the new components are deployed on the available infrastructure: C2 is deployed on site3, C3 and C4 on site2 and ﬁnally C5 on site1. Thus, C1 preserves its service continuity on site1 although its sub-components are distributed on the available infrastructure1 .

Figure 1: Context-aware deployment of software components

2.2 Self-adaptive component model To achieve a context-aware deployment, a component must be able to take into account its context to generate an adapted structure specification then it must be able to reconfigure its structure. So, such a component must be self-adaptive and structural-adaptive. In order to be structural-adaptive, a component must be conformed to a model, defined in [BSO06], which allows it to update its structure. In fact, such a component is a component whose each provided interface is reified into a primitive sub-component called interface-component. In order to generate self-adaptation mechanisms, we introduce three new components: Context-manager: first, a self-adaptive component must be able to describe its service use- cases. So, each interface-component is assigned, using the context-manager, to a description which contains two kinds of data: first, the list of required resources needed for the component deployment, second, data related to the user-target profile and the use conditions. Data related to required resources are specified by the component designer or by the component itself. Whereas data related to user-target profile and use-conditions are specific to the application in which the component is assembled. So, these data are specified by the application administrator. All these contextual data are acquired using dedicated interfaces. Second, the component must be able to acquire data related to its execution context: on the one hand, it must be able to collect data related to its structure and its behavior. First, the structural data are obtained using controller interfaces through component introspection. Concerning the behavioral data, they are acquired by saving metadata related to the messages which are sent among components. This operation is achieved using dedicated connectors between the composite-component and its sub-components or among sub-components. On the other hand, the component must be able to acquire data related to its external context (i.e. environmental and hardware architectural context). This acquisition is achieved using

1 Composite distribution mechanisms are described in [SBO06].

3 / 11 Volume X (2007) Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environ- ments sensors which can be software (e.g. battery) or hardware (e.g. GPS). All these contextual data are interpreted, aggregated then sent to the decision engine which aims at determining the best adaptation strategy. Decision engine: this component provides decision-making mechanisms allowing the component to specify automatically the adaptation script used by the structural adaptation process [BSO06] for generating the adapted component. This script is a description of the component structure, formulated through an ADL defined in [BSO06]. It contains a description of the components to generate: for each component, its services and its deployment site are specified. For example, the script presented below can be used to generate from a component called C1, a ′ composite-component composed of two sub-components: C1 providing services S1 and S3, de- ′′ ployed on site2; C1 providing services S2 and S4, deployed on site1. < component name = ”C1” > ′ < component name = ”C1” site = ”site2” > < service name = ”S1”/> < service name = ”S3”/> ′′ < component name = ”C1 ” site = ”site1” > < service name = ”S2”/> < service name = ”S4”/> < /component > Adaptation engine: once the script defining the new structure has been generated, structural adaptation has to be achieved by the component using the reconfiguration engine then the de- ployer engine. The functionalities of these two engines are described in [BSO06]. To generate such a component from an existing one, we use our structural adaptation process described in [SBO06]. This process, achieved in an automatic way, is composed of three stages (Fig. 2): first, the initial component is fragmented into a set of new components providing each only one service, while guaranteeing component integrity and coherence. Then, the interface- components are assembled, taking into account their dependences (i.e. horizontal assembly). Finally, the obtained assembly is encapsulated into a composite-component, providing the same services as those of the initial component (i.e. vertical assembly). Finally, the new components dedicated to the self-adaptation of the component are introduced.

Figure 2: Structural-adaptive component generation

3 Context-aware component deployment decision-making

As was explained previously, to achieve a context-aware deployment, a component has to acquire information related to its execution context. Then, these context data are interpreted to initiate an adaptation phase and also to set-up an adaptation strategy.

Proc. Software Evolution 2007 4 / 11 ECEASST

3.1 Context-aware deployment strategy Contextual data are used by the component to generate a specification corresponding to a new component structure which matches with the current context: each service provided by the component to adapt must be associated with a deployment site. Each set of services associated with a site is merged into a same sub-component. To generate such specification of the new component structure, we identify three kinds of classification tasks which differ according to their impact on the component structure. First, the environmental context is used for classifying services provided by the adapted component according to their priority of deployment on the user device. In fact, this priority depends on similar points between the context target (defined by the application administrator) and the current context (acquired using sensors or user data). However, these classification tasks cannot be generated automatically because events and decisions are specific to the application. In this case, the selection strategy must be designed by the application administrator using rules like (< condition >⇒< action >). The second task is based on selecting sites where services are able to be deployed, taking into account the resources available on the different nodes of the distributed infrastructure. This task is achieved by matching the service requirements (defined by the component designer) with the contextual data. We aim at generating a configuration which maximizes the number of high- priority services deployed on the user device or on its neighborhood. So, each subset of services associated with a site corresponds to a component generated during the structural adaptation. It will be redeployed on the corresponding site. However, this selection task cannot be entirely automated because of the specificity of the resources required by each service. In fact, this selection is achieved using adaptation policies defined by the component designer. The last task is based on classifying the component services according to the data related to the component structure and behavior. This classification aims at optimizing service distribution by evaluating dependences among services. In fact, the optimization is based on minimizing remote connections between the new specified components by merging the most dependent services within sub-components which are deployed on sites according to the dependences with other application components. Contrary to the two preceding tasks, where a treatment specific to the application is required, this task can be entirely automated. This operation is detailed below.

3.2 Service-dependence awareness The objective of software-awareness is to merge the most dependent services within sub components deployed on only one device. Dependences between services are of two kinds [SBO06]: functional dependences and dependences related to the resource-sharing. They require the introduction of remote communications between components (e.g. remote service call, shared- resource synchronization); whose cost can be substantial. So, sub-components must be speciﬁed taking into account these dependences in order to minimize the remote communications.

3.2.1 Evaluable context-elements To set up such selection mechanisms, we need to quantitatively evaluate dependences among components. To do so, we use the software context. This context contains a history of commu-

5 / 11 Volume X (2007) Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environ- ments

nications among sub-components. Data collected for each service (Si) of the adapted component are the following: 1. the probability that the service Si calls S j with S j ∈ Sprovided ∪ Srequired , noted Puse(Si,S j). This probability is related to the number of S j call during Si execution (direct or indirect call) compared to the service Si call number, 2. the average number of calls from Si to S j with S j ∈ Sprovided ∪ Srequired , noted Maver(Si,S j), 3. the average number of parameters used when a service S j is called by Si, noted Nbparam(Si,S j) as well as the average memory size (in bytes) of these parameters, noted Tparam(Si,S j), 4. the probability to update a resource, in Si, shared with S j such as S j ∈ Sprovided , noted Pupdate(Si,S j), 5. the probability to initiate a critical section in Si related to a resource shared with S j such as S j ∈ Sprovided , noted Pcritical (Si,S j).

3.2.2 Service-dependence evaluation The software-context elements are used to evaluate proximities between the various services provided by the adapted component. In fact, the proximity between two services depends on their coupling (i.e. evaluation of the functional dependences) and on their cohesion (i.e. evaluation of the dependences related to resource-sharing). The coupling between two different services Si and S j noted Ccoupling(Si,S j) is evaluated according to the probable number of calls of the service S j since the execution of Si and inversely balanced by the number and the type of parameters exchanged between these two services. In fact, this weight is computed according to the average number of parameters used for the service call and the average memory size of these parameters.

Ccoupling(Si,S j )= α(Si,S j ) ∗ β(Si,S j)+ α(S j,Si) ∗ β(Si,S j )

Where α(x,y)= Tparam(x,y) ∗ (Nbparam(x,y)+ 1) and β(x,y)= Maver (x,y) ∗ Puse(x,y)

The cohesion between two different services Si and S j, noted Ccohesion(Si,S j) is evaluated according to the number of critical sections started in each service and the frequency of update of resources shared between Si and S j and inversely, balanced by the number and the type of resources. The weight related to the type of resources corresponds to their average memory size expressed in byte and noted Tsr(Si,S j).

Ccohesion(Si,S j )= γ(Si,S j) ∗ η(Si,S j )+ χ(Si,S j )

Where χ(x,y)= Pcritical(x,y)+ Pcritical (y,x) and η(x,y)= Pupdate(x,y)+ Pupdate(y,x) and γ(x,y)= Nbsr (x,y) ∗ Tsr (x,y)

The proximity between two services Si and S j contained in a set S is a binary relationship, noted Pr(Si,S j) deﬁned as follow:

1 if Si = S j α ′ β ′ Pr(Si,S j )= ( ∗Ccoupling(Si,S j)+ ∗Ccohesion(Si,S j)) ( α+β else Where

0 if C = 0 0 if C 0 ′ coupling max ′ cohesion max = C (S ,S )= C (S ,S ) and C (S ,S )= C S S coupling i j coupling i j else cohesion i j cohesion( i, j) else ( Ccoupling max ( Ccohesion max

Ccoupling max = max( Ccoupling(x,y), ∀x,y ∈ S / x 6= y ) and Ccohesion max = max({Ccohesion(x,y), ∀x,y ∈ S / x 6= y}) Proc. Software Evolution 2007 6 / 11 ECEASST

The proximity between two services varies from zero, when the two services are not dependent, to one. The value one means that the two services are the same one (by convention). The closer to one the proximity between two services is, the more dependent these services are. α and β are the impact factors respectively for coupling and cohesion. According to usage requirements, the application administrator instantiates these factors by giving more weight to the coupling (α > β) or to the cohesion (α < β). By default, we suppose that these two dependences have identical impacts (α = 1 and β = 1).

3.2.3 Clustering-service algorithm The evaluation of proximities between the services provided by the adapted component is used to merge services in subsets containing the most dependent services, among themselves. Each subset constitutes a component whose provided services are the ones contained in this subset. In addition, the dependences between provided and required services can be used to determine the deployment site of each generated component. The goal is to minimize remote communications with the other application components providing the services required by the component to adapt. In fact, the generated components must be deployed on the sites which provide services close to services provided by the adapted component. To obtain an interface partition whose elements are associated with a deployment site, we use a hierarchical clustering algorithm (Fig. 3). It requires as a parameter, an array whose cells contain an evaluation of proximities between provided services and with deployment nodes of the infrastructure. So we can note that there are two kinds of clusters: on the one hand, service- clusters which contain a set of services provided by the adapted component, and, on the other hand, site-clusters which contain the set of services provided by components which are deployed on it and which are required by the adapted component.

Clinit ← {Set o f initial clusters} While ∃Cli ∈ Clinit such as Cli ∩ Sites 6= ⊘ Do ∀Cli ∈ Clinit , ∀Cl j ∈ Clinit ∪ Sites, T[Cli,Cl j ] ← Pr(Cli,Cl j ) Find Clmaxi and Clmaxj such as ∀Cli ∈ Clinit , ∀Cl j ∈ Clinit ∪ Sites, Cli 6= Cl j and T (Clmaxi,Clmaxj ) ≥ T(Cli,Cl j ) and |Clmaxi ∩ Site|≤ 1 Clinit = Clinit ∪ (Clmaxi,Clmaxj ) If Clmaxj ∈ Clinit then Clinit = Clinit − Clmaxi,Clmaxj If Clmaxj ∈ Sites then Clinit = Clinit − {Clmaxi} Sites = Sites − Clmaxj Return Clinit Figure 3: Service-clustering algorithm

The main idea behind this algorithm is to merge the services provided by the adapted component, in clusters, according to their proximity. And, each cluster must be associated with only one deployment site. Initially, the maximal value of the array is searched. Two cases can appear: if this value corresponds to the proximity between two service-clusters, these two clusters are merged into a same one. If this value corresponds to the proximity between a service-cluster and a site-cluster then the service-cluster is associated with the corresponding site. If the cluster is already associated with a site, this value is ignored and the algorithm searches the maximal value of

7 / 11 Volume X (2007) Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environ- ments this array except this cell. Once a fusion or an association has been achieved, the proximity array is evaluated again according to the new clusters. Two solutions are possible to calculate the proximities between two clusters: either all proximity values (coupling and cohesion) are evaluated again according to the services contained in each cluster, or an approximation of the proximity between two clusters is done. The former cannot be considered because of its complexity (O(n6)) which cannot be acceptable for runtime adaptation. That is why, we chose a lower-complexity strategy (O(n2)) based on the average proximities between the cluster elements:

1 Pr(Cl1 ,Cl2 )= ∑ Pr(Si,S j ) |Cl1 ||Cl2 | S C S C i∈ l1 , j∈ l2 These operations are reiterated until each cluster is associated with a deployment site. Then, the result corresponds to the different clusters obtained and their associated site.

3.2.4 Example of service-clustering

If we consider the following application part: three components called C1 (provided services: S1, S2, S3 and S4; required services: S5 and S6; deployment site: site 1), C2 (provided services: S5; deployment site: site 1) and C3 (provided services: S6; deployment site: site 2) are assembled (Fig. 4). When the structural adaptation is released, ﬁrst, we evaluate proximities between service-clusters ((S1), (S2) and (S3)) and with site-clusters (Site1 = {S5} and Site2 = {S6}). So, we obtain the following result: Pr (S1) (S2) (S3) (S4) Site1 Site2 (S1) 1 0.1203 0.4972 0 0.059 0 (S2) − 1 0.0409 0.1622 0.0218 0 (S3) − − 1 0.0727 0 0.3454 (S4) − − − 1 0.1909 0 First step: we observe that the maximal proximity value between different clusters corresponds to the proximity between two service-clusters (S1) and (S3). So, these two clusters are merged into a new one and proximity is evaluated again. Pr (S1,S3) (S2) (S4) Site1 Site2 (S1,S3) 1 0.0806 0.0363 0.0295 0.1727 (S2) − 1 0.1622 0.0218 0 (S4) − − 1 0.1909 0 Second step: in this case, we observe that the maximal proximity value between different clusters corresponds to the proximity between one service-cluster (S4) and one site-cluster (Site1). So, the cluster (S4) is associated with site 1. Pr (S1,S3) (S2) (S4) 7→ Site1 Site2 (S1,S3) 1 0.0806 0.0363 0.1727 (S2) − 1 0.1622 0 (S4) 7→ Site1 − − 1 0 Third step: the cluster called (S1,S3) is associated with site 2. Pr (S1,S3) 7→ Site2 (S2) (S4) 7→ Site1 (S1,S3) 7→ Site2 1 0.0806 0.0363 (S2) − 1 0.1622 (S4) 7→ Site1 − − 1 Fourth step: the two clusters (S2) and (S4) are merged into a new one which is associated with site 1 because (S4) has already been associated with this site. Pr (S1,S3) 7→ Site2 (S2,S4) 7→ Site1 (S1,S3) 7→ Site2 1 0.0585 (S2,S4) 7→ Site1 − 1

Proc. Software Evolution 2007 8 / 11 ECEASST

Figure 4: Service clustering according to their dependences

As all service-clusters are associated with one site, the algorithm is ﬁnished. We obtain two clusters: the ﬁrst one, associated with site 1 contains services S1 and S3; the second one which contains S2 and S4 is associated with site 2. So, the adaptation of the component C1 consists ′ ′′ in its fragmentation into two new components called C1 (provided services: S1 and S3) and C1 (provided services: S2 and S4) which will be deployed respectively on site 2 and site 1.

4 Related work

We classiﬁed related work according to two criteria. First, we present the works related to our approach goal which is the context-aware deployment. The other criterion focuses on the works which propose creating self-adaptive components in order to take into account execution context.

4.1 Context-aware deployment Many works focus on context-aware deployment. Most of them are based on determining the best strategy for the application component placement into sites according to the context. Dearle et al propose in [DKM04] a framework for deployment and subsequent autonomic management of component-based applications. The deployment goal is specified by an administrator using a declarative language. Then, a constraint solver is used to generate a valid configuration. Each solution is in the form of a configuration, which describes a particular mapping of components to sites and interconnection topology that satisfies the constraints. AMPROS [ATSB04] is a platform for context-aware deployment of component based applications in mobile environments. The deployment adaptation is carried out by a set of adaptive components able to modify the application architecture together with the component attributes. However, few approaches offer a flexible strategy for deploying a component on a device whose resources are not enough to ensure service continuity. Such approaches give partitioning

9 / 11 Volume X (2007) Software Component Reengineering for their Context-Aware Deployment in Ubiquitous Environ- ments components to distribute them. The Coign project [HS99] is a partitioning system based on Microsoft’s COM model. It aims at transforming applications built from distributable COM component into distributed ones. Coign constructs a graph model of the component communications through scenario-based pro- filing. Then, it applies a graph-cutting algorithm for partitioning components according to the infrastructure. However, Coign does not take all partitioning issues into account. Jamwal and Iyer propose in [JI05] creating breakable objects, called BoBs, in order to build flexible architectures. A BoBs is an entity that can be split into sub entities. It has a simple structure which allows an easy code partitioning and its redeployment. However, Bob imposes restrictions on breakable objects (e.g. no public field). All existing approaches which aim at partitioning component structure are based on specific component models. Moreover, no approach proposes generating a new component structure taking into account service-dependences although it can be useful for improving service quality.

4.2 Self-adaptive components Many approaches have been proposed achieving self-adaptive components. Safran [DL03] is an extension of the Fractal component model to support the development of self-adaptive components. Safran is based on the introduction of a reflective extension in order to modify the component behavior according to the context. The adaptation process is achieved using an adaptation policy for each component. Each adaptation policy is a set of ECA rules which can be updated since runtime. Adaptation actions consist of the component re-assembling. The K-component [DC01] model aims at creating dynamic software architectures for building adaptive systems. The reified architecture is presented as a graph whose nodes represent interfaces and are annotated through the component name in which they are contained; each arc represents connectors between two interfaces and is annotated by connection properties. Recon- figuration consists of graph transformations. However, only annotations can be modified. So, this system allows only component replacement or connection updates. However, in spite of this diversity of proposed approaches, all those interested in the component adaptation focus on behavior adaptation and few works aim at adapting component structures. In addition, to our knowledge, all these works focus on the adaptation of the component implementation by the runtime replacement of an implementation by another. The result is that no approach proposes techniques for restructuring software components, although this adaptation can be required in many cases.

5 Conclusion and future work

We presented in this paper an approach aiming at reconfiguring component structure to allow a flexible deployment of its services. Such components must be conformed to a canonical format which is based on interface reification. Besides, it must contain components enabling it to acquire and analyze its context to determine an adapted structure, guaranteeing its service continuity and improving service quality. Then, the specified structure is generated by encapsulation of interface-components within new sub-components which can be redeployed.

Proc. Software Evolution 2007 10 / 11 ECEASST

The context-aware deployment process has been implemented using the Julia software component framework which is a Java implementation of the Fractal component model [BCL+04]. As mentioned previously, our approach aims at guaranteeing service continuity of components. However, our adaptation process involves an overhead related to the management of the communication and synchronization between the generated sub-components and decision- making mechanisms. Currently, we evaluate this overhead. Our approach allows us to adapt software component deployment. However, as an application is built by assembling components, adapting an application requires coordinating the adaptation of its components. This issue is a future work.

Bibliography

[ATSB04] D. Ayed, C. Taconet, N. Sabri, G. Bernard. Context-Aware Distributed Deployment of Component-Based Applications. In Proc. of OTM Works. Pp. 36–37. 2004. [BCL+04] E. Bruneton, T. Coupaye, M. Leclercq, V. Qu´ema, J.-B. Stefani. An Open Com- ponent Model and Its Support in Java. In Proc. of the Symp. on Component-Based Software Engineering (CBSE). Pp. 7–22. 2004. [BSO06] G. Bastide, A. Seriai, M. Oussalah. Dynamic adaptation of software component structures. In Proc. of the Int. Conf. on Information Reuse and Integration (IRI). Pp. 404–409. 2006. [DC01] J. Dowling, V. Cahill. The K-Component Architecture Meta-model for Self-Adaptive Software. In Proc. of the Int. Conf. on Metalevel Architectures and Separation of Crosscutting Concerns. Pp. 81–88. 2001. [DKM04] A. Dearle, G. N. C. Kirby, A. J. McCarthy. A Framework for Constraint-Based De- ployment and Autonomic Management of Distributed Applications. In Proc. of the Int. Conf. on Autonomic Computing. Pp. 300–301. 2004. [DL03] P.-C. David, T. Ledoux. Towards a Framework for Self-adaptive Component-Based Applications. In Proc. of the Int. Conf. on Distributed Applications and Interoperable Systems (DAIS). Pp. 1–14. 2003. [HS99] G. C. Hunt, M. L. Scott. The Coign automatic distributed partitioning system. In Proc. of the Int. Symp. on Operating Systems Design. Pp. 187–200. 1999. [JI05] V. Jamwal, S. Iyer. BoBs: breakable objects. In Proc. of OOPSLA ’05, systems, languages, and applications. Pp. 98–99. ACM Press, New York, NY, USA, 2005. [SBO06] A. Seriai, G. Bastide, M. Oussalah. Transformation of Centralized Software Com- ponents into Distributed Ones by Code Refactoring. In Proc. of the Int. Conf. on Distributed Applications and Interoperable Systems (DAIS). Pp. 332–346. 2006. [Szy98] C. Szyperski. Component software: beyond object-oriented programming. ACM Press/Addison-Wesley, 1998.

11 / 11 Volume X (2007) ECEASST

On the resilience of classes to change

Rajesh Vasa1, Jean-Guy Schneider1, Oscar Nierstrasz2 and Clinton Woodward1

1 Faculty of Information & Communication Technologies Swinburne University of Technology P.O. Box 218, Hawthorn, VIC 3122, AUSTRALIA [email protected], [email protected], [email protected]

2 Institute of Computer Science University of Bern Bern, CH-3012, SWITZERLAND [email protected]

Abstract: Software systems evolve over time incrementally and sections of code are modified. But, how much does code really change? Lehman’s laws suggest that software must be continuously adapted to be useful. We have studied the evolution of several public domain object-oriented software systems and analyzed the rate as well as the amount of change that individual classes undergo as they evolve. Our observations suggest that although classes are modified, the majority of changes are minor and only a small proportion of classes undergo significant modification. Keywords: Open-source, change, metrics.

1 Introduction

It is a well-established fact that software systems change and become more complex over time as they are used in practice [LB85]. However, it is less well-understood how change and complexity are distributed over time, and there has been little research conducted into understanding how change is distributed over the parts of object-oriented software systems. In previous work, we have studied typical growth and change patterns in open-source, object- oriented software systems and shown that although software grows and changes over time, the structure and scope of both growth and change is, in general, predictable rather than erratic or purely random [VSWC05, VLS07, VSN07]. This leads us to ask whether we can gain a more detailed insight into where change occurs, and the degree to which change can be expected. Not only do we need a suitable distance measure to indicate how much a class or component changes, but we should also collect information about change at a ﬁne-grained level and perform a general landscape analysis. This will then allow us to address questions like:

• What proportion of a release contains code that has never been touched since creation?

• What is the probability that a class is modiﬁed after it is created?

• How is modiﬁcation frequency distributed for classes that do change?

1 / 11 Volume X (2007) On the resilience of classes to change

• Does a class or component tend to change a lot or are most modiﬁcations minor adjustments? Continuing our previous work, we have analyzed a number of open source applications that have evolved over at least 18 releases during a period of at least 28 months. For each of these applications we have collected information on the amount of change individual classes go through as they evolve over time. The key results of our studies show that:

1. Most classes will be modified at least once during their lifetime, but a substantial proportion of classes stay unchanged during their entire history. 2. Of the classes that are modified, the probability that a class is modified multiple times is quite low. 3. The amount of change that most classes undergo is also minimal. However, a small proportion of classes is modified significantly.

The rest of this paper is organized as follows: in Section2 we provide an overview of our experimental method, and we justify the selection of the case studies. Section3 presents the results of our studies. In Section4 we suggest possible interpretations and consequences of our observations, followed by a discussion of some limitations of our approach in Section5. Section6 provides a brief overview of related work. We conclude in Section7 with some remarks about future work.

2 Experimental method

In this section, we brieﬂy present the systems studied. Next, we describe the means by which measurements are performed, followed by a discussion about the measures that we collected. Finally, we illustrate the approach used to detect clones and measure change.

2.1 Input data set selection As in our previous work [VSWC05, VLS07, VSN07], we have restricted our study to open- source software developed using the Java programming language. The main reasons for selecting open source software are their availability, access to change logs (e.g., such as developer release notes), as well as licensing practices that allow access to both source and object code. The choice of the systems using the Java programming language was inﬂuenced by its use in a variety of application domains, as well as by the availability of a suitable infrastructure to implement the necessary metrics tool. Although there is a large pool of candidate systems, we have limited our selection to 12 representative systems (cf. Table1) for this study. Our data set contains a total of 310 releases. All systems analyzed in this study have at least 18 releases and a development history of 28 months or more. A Release Sequence Number (RSN) [CL66] is used to uniquely and consistently identify each release version of a given system. The ﬁrst version of a system is numbered 1 and then each subsequent version increases by one. Hence, RSNs are universally applicable and independent of any release numbering schedule and/or scheme.

Proc. Software Evolution 2007 2 / 11 ECEASST

Name Releases Time Span Initial Size Current Size Description Axis 23 65 mo. 166 636 Apache SOAP server Azureus 21 41 mo. 103 4780 Bittorent Client Castor 27 48 mo. 483 691 Data binding framework Checkstyle 26 75 mo. 18 309 Coding standard checker Findbugs 20 36 mo. 308 839 Automated bug ﬁnding application Groovy 20 38 mo. 170 886 Dynamic language for JVM Hibernate 47 73 mo. 120 1055 Object-relational mapping framework Jung 21 44 mo. 157 705 universal network/graph framework Spring 42 43 mo. 386 1570 Light-weight container Struts 18 28 mo. 106 300 Servlet/JSP framework Webwork 20 36 mo. 75 473 Web application framework Wicket 25 30 mo. 181 631 Web application framework

Table 1: Systems under analysis for this study with size being the number of classes and interfaces.

2.2 Extracting Measures In order to perform the analysis, we developed a metrics extraction tool [VSWC05], which analyzes Java Bytecode and extracts data to capture the degree of change of a system with respect to its size and complexity. Java Bytecode generally reveals almost as much about a system as its source code, and only some subtle changes to a software system cannot be detected using this approach (e.g., use of local variables). Our metrics extraction tool takes as input the core JAR ﬁles for each release of a system, and extracts metrics by processing the raw Java Bytecode. This approach allows us to avoid running a potentially complex build process for each release, and limits analysis to “code” that has been correctly compiled as the developers intended. For each class1 in a system under analysis, we extract simple measures such as the number of methods, ﬁelds, branches as well as the set of classes that this class depends upon, either as direct client or direct subclass. Type dependency graph analysis [VCS02] can then be used to compute other measures such as Fan-In [VSN07].

2.3 Software measures Using the metrics extraction tool, we have extracted 43 different count measures for each class in each system analyzed. The names we have given to these measures are listed in Table2 and include, amongst others, Fan-Out and Branch Count (i.e., the number of branch instructions in the Java Bytecode), Load Instruction Count (i.e., the number of load instructions), and Store Instruction Count (i.e., the number of store instructions). A detailed discussion of all these measures is beyond the scope of this work. However, they naturally align with the most common instructions of the Java Bytecode as well as covering some basic structural relationships. Furthermore, to support a more detailed comparison, we store the name of each class, its superclass name, all method names (including full signatures), ﬁeld names and the name of all

1 To improve readability we will refer to “classes” when we mean “classes or interfaces”. We will only refer to “types” in the context of the formal measures.

3 / 11 Volume X (2007) On the resilience of classes to change

abstractMethodCount branchCount constantLoadCount exceptionCount externalMethodCallCount fanOutCount fieldCount finalFieldCount finalMethodCount iLoadCount incrementOpCount innerClassCount interfaceCount internalFanOutCount internalMethodCallCount isAbstract isException isInterface isPrivate isProtected isPublic iStoreCount loadFieldCount localVarCount methodCallCount methodCount privateFieldCount privateMethodCount protectedFieldCount protectedMethodCount publicFieldCount publicMethodCount refLoadOpCount refStoreOpCount staticFieldCount staticMethodCount storeFieldCount superClassCount synchronizedMethodCount throwCount tryCatchBlockCount typeInsnCount zeroOpInsnCount

Table 2: Java Bytecode measures extracted for analysis. other classes that a class depends upon. This information is then used in our clone detection method discussed in the next section.

2.4 Detecting clones and measuring change In order to perform our analysis, in particular to detect clones and measure changes between versions of a given system, we consider the following information for each class under analysis: (i) the fully qualified class name, including its class modifier (i.e., public, private, protected, interface, final or abstract) (ii) the name of its direct super class, (iii) the name, types and class modifier(s) of all fields, (iv) the name, signature and class modifier(s) of all methods, and (v) the set of classes this class depends upon. Additionally, we extract all 43 class level measures for each version of a class under investigation. For our analysis, we consider two classes to be clones of each other (we treat them as being identical) if all metrics for each class are identical (i.e., all 43 measures have the same value, same class name with the same modifiers etc.). Furthermore, the distance between two classes is defined as the number of measures (out of the 43) that differ (i.e., if two of the 43 measures differ between two classes, then they have a distance of 2). Note that even if two classes have a distance of 0, they may not be identical (e.g., the name of a field is modified). However, our analysis has revealed that this is only rarely the case and over all 310 versions we analyzed, at most 4% of modified classes have a distance of 0. Finally, we consider the history of a system as the set of versions, ordered by RSN, whereas a version is the set of all classes contained in a particular release. We compare the final version of each system with all previous versions (i.e., over the entire evolutionary history) in order to compute the following information:

• The proportion of classes in the ﬁnal version that remain unchanged since creation as well as the proportion that are modiﬁed after being created.

• The number of times a class has been modiﬁed since its creation.

• The amount of modiﬁcation that each class has undergone since its creation (i.e., modiﬁ- cation amplitude).

Proc. Software Evolution 2007 4 / 11 ECEASST

The information gathered from the ﬁrst point gives us an overall picture of the number of classes that stay unchanged over their lifetime. The last point indicates if changes are substantial, and can provide an indication of the distribution of small and large changes.

3 Observations

We now summarize our observations from analyzing the 12 systems listed in Table1. First, we analyze the percentage of classes that have not changed since being added into the respective system. We then consider the set of modified classes and analyze the number of times they have been modified. Finally, we illustrate how much modified classes change over time.

3.1 Probability of change At a class level, systems evolve by addition of new classes, modification of existing classes or removal of classes. Hence, given an evolutionary history, for any given version we can identify three types of classes: new classes, classes that have been modified at some point in their life, and classes that have not changed since their creation. In our analysis, we use the last release of a given system as the base-line for comparison. We consider a class as being unchanged if it is a clone of its first release, i.e., the release in which it was first defined. Any potential changes in between are not analyzed in our approach. Similarly, we consider a class as having changed (at least once) if it is not identical to its first release. A class is considered to be new if it did not appear in any release before the last one. The results of our analysis are illustrated in Figure1. Except for Webwork and Jung, the percentage of unchanged classes is lower than the percentage of modified classes. However, it is interesting to see that the percentage of unchanged classes ranges between 20% and 55%, depending on the system. The lower end of the range indicates that in general there is a certain proportion of classes that are never touched and the average, which is closer to 40%, suggests that there is a certain inherent resistance to change in many of the classes once they have been added. Also, our analysis shows that the number of new classes introduced in the last release is small and generally tends to be under 5%.

3.2 Rate of modification As noted in the previous section, only a small proportion of all classes undergoes some change. However, how often are these classes modified? What does the distribution of this modification look like? Again, we use the last release as our base-line and only report on classes that are part of this release – any classes that have been removed before then are not considered. From our previous work [VSN07] we know that only about 2% to 5% of classes fall into this category. Only considering classes that have been modified at some point in their life cycle and counting the number of times that they have been modified, we can observe that, on average, 50% thereof are modified less than 3 times. In Jung, for example, 90% of modified classes are changed less than 3 times. Furthermore, as shown in Figure2, all of the systems have a similar modification profile. Due to the way we have charted the values using absolute modification count, Axis and

5 / 11 Volume X (2007) On the resilience of classes to change

100.0%

90.0%

80.0%

70.0%

60.0%

Unchanged 50.0% Modified New % Classes 40.0%

30.0%

20.0%

10.0%

0.0%

vy yle et Axis Jung Struts Castor Spring Wick Azureus Groo ebwork Hibernate Findbugs W Checkst

Figure 1: Proportion of new, unchanged, and modiﬁed classes using ﬁnal version as base-line.

Jung show up as minor outliers. On average, 5% or less of all modified classes are changed more than 8 times in their life cycle. This suggests that the probability that a class is modified multiple times is quite low and that this probability reduces non-linearly, as is shown in Figure2. Please note that only 0.01% of classes were modified more than 25 times.

3.3 Distribution of the amount of change As software evolves, we have observed that there is a proportion of code that changes, but the number of modifications is in most cases minimal. But how much change does happen, i.e., how many measures do actually change? Is there a typical profile for most systems, like the one we observe in the modification frequency? In order to detect the amount of change, we focus on the classes in the final version that have been modified at least once in their life cycle. We then compute the number of measures (out of the 43 possible) that have changed between the version the class was first defined and the final version. This high-level approach allows us to see if there is a common profile across the various systems, but does not indicate how big the changes in each of the 43 measures are. Our observations for all systems under analysis are shown in Figure3. The reader may first notice that a few classes do not indicate a change in any of the measures at all. This is possible since the clone detection technique that we apply also takes into consideration method signatures, field names etc. (cf. Section 2.4). However, there is a probability that some other measure that we do not collect has changed in such a situation. On average, in our data less than 4% of the classes fall into this category. When exploring the data for a profile, we observed that 6 systems are much more closely aligned than the other 6 systems, and one of the systems, Groovy, has a substantially different profile. However, despite the broad range, much of the cumulative growth is fairly linear for 90%

Proc. Software Evolution 2007 6 / 11 ECEASST

100%

90%

80%

Axis 70% Azureus Castor 60% Checkstyle Findbugs Groovy 50% Hibernate Jung 40% Spring Struts % Classes (Cumulative) Webwork 30% Wicket

20%

10%

0% 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Modification Count

Figure 2: Cumulative distribution of the modification frequency of classes that have undergone a change in their lifetime. of the classes across multiple systems and only 10% of the modified classes have more than 23 measures modified. The cumulative growth for the remaining 10% is not linear any more and needs further analysis. The reader may note that as some of the measures are closely related (e.g., a store instruction is generally aligned with at least one load instruction), it can be expected that they change in a similar way. Early analysis indeed suggests that the number of load instructions and the number of store instructions have a very close relationship. However, further analysis is required to clarify the correlation between the various measures.

4 Interpretation

Probability of change: In all of the systems that we have studied, a good proportion of classes remained unchanged. This indicates that some abstractions tend to stay very stable after they are created. The range of values for different systems suggests that this stability depends on the domain and possibly the development approach as well as the architectural style that the team has adopted early in their life cycle.

Rate of modification: Of the classes that have changed, most have been touched a few times – only a small proportion is modified several times. This modification profile is very similar in all systems under analysis, suggesting that most classes in a system tend to reach a stable state very quickly. Combined with our earlier observation that a good proportion of code is never touched, this suggests that development teams tend to create a stable set of abstractions very quickly. Our findings provide further support to a similar conclusion reached by Kemerer et al. [KS97].

7 / 11 Volume X (2007) On the resilience of classes to change

100.0%

90.0%

80.0%

Axis 70.0% Azureus Castor 60.0% Checkstyle Findbugs Groovy 50.0% Hibernate Jung 40.0% Spring Struts

% Classes (Cumulative) Webwork 30.0% Wicket

20.0%

10.0%

0.0%

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 Number of metrics modified

Figure 3: Number of measures that change for modiﬁed classes.

Distribution of the modifications: Modifications are unavoidable as systems evolve. How- ever, very few of the classes tend to experience a high level of modification (as computed by the number of measures that change). Although our approach does not reveal the actual amount of code changed, it provides us a broad indicator which may serve as a starting point for further analysis.

5 Limitations

In order to place our study in context, we highlight some of the known limitations of our approach in addition to our findings. The clone detection method used in this work may pick up false positives since there may be changes to a class that our 43 metrics are unable to detect. We intend to improve this by adding further metrics and additional aspects like the method calls and the call sequence. Furthermore, our distance measure compares the initial version of a class to the final version. This may miss edits where a class is modified and returned back to its original shape, as seen by the metrics. This limitation can be addressed by looking at distance incrementally. As a consequence, the analysis approach would have to be adjusted to take into consideration the way the metric information is being collected. Our method of computing modification misses classes that have been renamed; they will be considered as a deletion and an addition. This is a weakness that we are addressing in future work by improving clone detection to accept a certain level of name changes (e.g., package name change). We have restricted our input data set to open-source software targeting the Java VM. This lim-

Proc. Software Evolution 2007 8 / 11 ECEASST its the ability to interpret our ﬁndings in other languages, since every language tends to promote a certain culture and a different language may have a different outcome. Furthermore, com- mercially developed software systems, or systems that are substantially larger than those in our investigation, may reveal different patterns of stability and maintenance proﬁles.

6 Related work

Kemerer and Slaughter have studied the profile of software maintenance in five business systems at the granularity of modules. They conclude that very few modules change frequently, and those that do are considered to be strategic [KS97]. Gˆırba has noted that classes that have changed in the past are also those most likely to change in the future, but these classes are in the minority [Gir05]. A number of researchers have studied methods of detecting existence of a class in previous versions (i.e., a clone) using a range of different techniques from string matching [DNR06, Joh94, RD03], abstract syntax trees [BYM+98] and metrics-based fingerprinting [ACCD00, KDM+96]. In our study we detect clones by combining metrics as well as string matching. We collect string information to the extent possible by bytecode analysis (for example, method signatures and dependent type names). Although definitions and methods to detect clones have been provided, a comprehensive study with an intention of understanding change and stability using clone detection has not previously been done. Origin analysis [ZG05] uses a semantic perspective of the context and usage of code in order to determine where, why and how changes have occurred. The technique also makes use of version control log data to determine the true origin of code components and changes. Their technique is in contrast to metrics-based methods, such as our own and those proposed by Demeyer et al. [DDN00] designed to identify specific components rather than origins. Barry et al. [BKS03] describe software volatility as a concept with 3 dimensions: amplitude (size of change), periodicity (frequency of change) and deviation (consistency of change). Using a phase sequence analysis approach, they detected a distinct set of volatility patterns. Their data set involved studying maintenance activity log from 23 different systems. In our approach, we have focused on information that can be collected automatically rather than by parsing log files.

7 Conclusions and Future Work

In this paper, we have investigated where change occurs within 12 open-source Java systems that have evolved over a period of at least 2 years at the granularity of classes through bytecode analysis. Our study shows that when we look at the latest version of a given system, around a third (or more) of the classes are unchanged since being added into the code base. Of the modified classes, very few are changed multiple times, suggesting an inherent resistance to change. Further analysis suggests that only a small minority of the classes tend to undergo substantial change. These findings show that maintenance effort, which is considered to be a substantial proportion of the development effort (post initial versions) is spent on adding new classes. Furthermore, when existing classes need to be modified, the probability of large alterations is generally quite low.

9 / 11 Volume X (2007) On the resilience of classes to change

Our work leads us to ask the following questions as possible future work: is there an inherent profile for classes that tend to change significantly? Are there any factors that correlate with classes becoming stable? When changes are made, are large modifications made in a single version or do they tend to make these over multiple versions? When a class is modified a few times, are the changes minor? Is there any strong correlation that suggests that either size or complexity play a role in the tendency for a class to be modified? Can one characterize the nature of frequently occurring changes?

Acknowledgements: The authors would like to thank Orla Greevy for her comments on a draft of this paper. Oscar Nierstrasz gratefully acknowledges the ﬁnancial support of the Swiss National Science Foundation for the project “Analyzing, capturing and taming software change” (SNF Project No. 200020-113342, Oct. 2006 - Sept. 2008).

Bibliography

[ACCD00] G. Antoniol, G. Canfora, G. Casazza, A. De Lucia. Information Retrieval Models for Recovering Traceability Links between Code and Documentation. In Proceedings of the International Conference on Software Maintenance (ICSM 2000). Pp. 40–49. 2000. doi:10.1109/ICSM.2000.883003

[BKS03] E. J. Barry, C. F. Kemerer, S. A. Slaughter. On the Uniformity of Software Evolution Patterns. icse 00:106–113, 2003. doi:10.1109/ICSE.2003.1201192

[BYM+98] I. Baxter, A. Yahin, L. Moura, M. S. Anna, L. Bier. Clone Detection Using Abstract Syntax Trees. In Proceedings of the International Conference on Software Mainte- nance (ICSM 1998). Pp. 368–377. IEEE Computer Society, Washington, DC, USA, 1998. doi:10.1109/ICSM.1998.738528

[CL66] D. Cox, P. Lewis. The Statistical Analysis of Series of Events. In Monographs on Applied Probability and Statistics. Chapman and Hall, 1966.

[DDN00] S. Demeyer, S. Ducasse, O. Nierstrasz. Finding Refactorings via Change Metrics. In Proceedings of 15th International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA ’00). Pp. 166–178. ACM Press, New York NY, 2000. Also appeared in ACM SIGPLAN Notices 35 (10). doi:10.1145/353171.353183

[DNR06] S. Ducasse, O. Nierstrasz, M. Rieger. On the Effectiveness of Clone Detection by String Matching. Journal of Software Maintenance and Evolution: Research and Practice (JSME) 18(1):37–58, Jan. 2006. doi:10.1002/smr.317

Proc. Software Evolution 2007 10 / 11 ECEASST

[Gir05] T. Gˆırba. Modeling History to Understand Software Evolution. PhD thesis, Univer- sity of Berne, Berne, Nov. 2005.

[Joh94] J. H. Johnson. Substring Matching for Clone Detection and Change Tracking. In Proceedings of the International Conference on Software Maintenance (ICSM 94). Pp. 120–126. 1994. doi:10.1109/ICSM.1994.336783

[KDM+96] K. Kontogiannis, R. DeMori, E. Merlo, M. Galler, M. Bernstein. Pattern Matching for Clone and Concept Detection. Journal of Automated Software Engineering 3:77– 108, 1996. doi:10.1007/BF00126960

[KS97] C. F. Kemerer, S. A. Slaughter. Determinants of Software Maintenance Proﬁles: An Empirical Investigation. Software Maintenance: Research and Practice 9(4):235– 251, 1997.

[LB85] M. Lehman, L. Belady. Program Evolution: Processes of Software Change. London Academic Press, London, 1985.

[RD03] F. V. Rysselberghe, S. Demeyer. Reconstruction of Successful Software Evolution Using Clone Detection. In Proc. of International Workshop on Principles of Software Evolution (IWPSE). Pp. 126–130. 2003.

[VCS02] S. Valverde, R. F. Cancho, R. Sole. Scale-free networks from optimal design. Euro- physics Letters 60(4):512–517, 2002.

[VLS07] R. Vasa, M. Lumpe, J.-G. Schneider. Patterns of Component Evolution. In Lumpe and Vanderperren (eds.), Proceedings of the 6th International Symposium on Soft- ware Composition (SC 2007). Pp. 244–260. Springer, Braga, Portugal, Mar. 2007.

[VSN07] R. Vasa, J.-G. Schneider, O. Nierstrasz. The Inevitable Stability of Software Change. In Proceedings of 23rd IEEE International Conference on Software Maintenance (ICSM ’07). IEEE Computer Society, Los Alamitos CA, 2007. To appear.

[VSWC05] R. Vasa, J.-G. Schneider, C. Woodward, A. Cain. Detecting Structural Changes in Object-Oriented Software Systems. In Verner and Travassos (eds.), Proceedings of 4th International Symposium on Empirical Software Engineering (ISESE ’05). Pp. 463–470. IEEE Computer Society Press, Noosa Heads, Australia, Nov. 2005. doi:10.1109/ISESE.2005.1541855

[ZG05] L. Zou, M. Godfrey. Using Origin Analysis to Detect Merging and Splitting of Source Code Entities. IEEE Transactions on Software Engineering 31(2):166–181, 2005. doi:10.1109/TSE.2005.28

11 / 11 Volume X (2007) ECEASST

Refactoring of UML models using AGG

Alessandro Folli, Tom Mens

Universite´ de Mons-Hainuat

Abstract: Model refactoring is an emerging research topic that is heavily inspired by refactoring of object-oriented programs. Current–day UML modeling environments provide poor support for evolving UML models and applying refactoring techniques at model level. As UML models are intrinsically graph–based in nature we propose to use graph transformations to specify and apply model refactoring. More in particular, we use a speciﬁc graph transformation tool, AGG, and provide recommendations of how AGG may be improved to better support model refactoring. Keywords: UML, Model Refactoring, AGG, Graph Transformation

1 Introduction

Model–driven engineering (MDE) is a software engineering approach that allows to accelerate development, to improve systems quality, and also to enable reuse. Its goal is to tackle the complexity of developing, maintaining and evolving complex software systems by raising the level of abstraction from source code to models. The mechanism of model transformation is at the heart of this approach, and represents the ability to transform and manipulate models. [SK03] Model transformation definition, implementation and execution are critical aspects of this process. The problem goes beyond having languages to represent model transformations, because the transformations also need to be reused and to be integrated into software development methodologies and development environments that make full use of them. The term refactoring was originally introduced by Opdyke in his seminal PhD dissertation [Opd92] in the context of object–oriented programming. Martin Flower [Fow99] defines this activity as “the process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure”. Current–day refactorings focus primarily on the source code level and do not take into account the earlier stages of design. A need exists for tools that enable designer to better manipulate their model, not just their source code. Furthermore, there is a need to synchronise and maintain consistency between models and their corresponding code; source code refactorings may need to be supplemented with model–level refactoring to ensure their consistency. This article will focus on the problem of model refactoring, which is a particular kind of model transformation. The Unified Modeling Language (UML) [Obj05b, Obj05a] can be used to specify, visualize, and document models of software systems, including their structure and design. UML allows to manipulate software models using model transformations. Therefore, the goal of this article is to explore the refactoring of UML models. We use graphs to represent UML models and graph transformations to specify and apply model transformations. This choice is motivated by the fact that graphs are a natural representa-

1 / 12 Volume X (2007) Refactoring of UML models using AGG tion of models that are intrinsically graph–based in nature (e.g., Class diagrams, State Machine diagrams, Activity diagrams, Sequence diagrams). Graph transformation theory has been developed over the last three decades as a suite of techniques and tools for formal modeling and very high-level visual programming. It allows to represent complex transformation in a compact visual way. Moreover, graph transformation theory provides a formal foundation for the analysis and the automatic and interactive application of model transformations. One of the advantages of this is the ability to formally reason about such refactorings, for example by analysing their parallel and sequential dependencies. [MTR07, Men06] AGG [Tae99, TU 06] is a rule–based visual programming environment supporting an algebraic single–pushout approach [EM93] to graph transformation. AGG may be used as a general purpose graph transformation engine in high–level Java applications employing graph transformation methods. In this article, we show that the use of graph transformations for the purpose of model refactoring is possible and useful. As a proof of concept, we implement a number of complex model refactorings in AGG. Based on our experience, we provide recommendations on how AGG may be improved.

2 Motivating Example

In the field of software engineering, the Unified Modeling Language (UML) is a non–proprietary specification language for object modeling. UML is a general–purpose modeling language that includes a standardized graphical notation used to create an abstract model of a system, referred to as a UML model. UML is officially defined by the Object Management Group (OMG) [Obj05b, Obj05a] by means of the UML metamodel. UML has been designed to specify, visualize, construct, and document software–intensive systems. As an example, Figure 1 shows the metamodel of UML State Machine diagrams. Model refactoring is a special kind of model transformation that aims to improve the structure of the model, while preserving (certain aspects of) its behaviour. Like the process of source code refactoring, the process of model refactoring is a complex activity. In [Fol07] we have discussed eight primitive model refactorings for UML Class diagrams and UML State Machine diagrams. This clearly shows that it is possible to formalise the specification and execution of model refactoring using graph transformation rules. Table 1 shows the list of model refactorings that we have discussed and implemented.

UML Class diagram UML State Machine diagram Pull Up Operation Introduce Initial Pseudostate Push Down Operation Introduce Region Extract Class Remove Region Generate Subclass Flatten State Transitions

Table 1: List of model refactorings

Proc. Software Evolution 2007 2 / 12 ECEASST

Figure 1: UML State Machine Diagram Metamodel

In [Fol07] each model refactoring has been formalised, explained and motivated using a concrete example. A detailed explanation of when it should be used and how it can be realized precedes a discussion of the list of mechanisms to accomplish the refactoring itself. In this article, we shall explore the Introduce Initial Pseudostate model refactoring in more detail in order to explain and illustrate the main concepts. As suggested by the name, it adds an initial pseudostate to a composite state, or region. The Introduce Initial Pseudostate refactoring is used to improve the structure of a State Machine diagram. Figures 2 and 3 show a simple example of this kind of refactoring. An initial pseudostate has been added to the ACTIVE composite state. The target of the transition that initially referred to the Ready state has been redirected to its enclosing region. An automatic transition has been deﬁned between the initial pseudostate and the Ready state. The Ready state has thus become the default initial state of the ACTIVE region; a transition whose target is the ACTIVE state will lead the State Machine to the Ready state. For reasons of simplicity, the representation of UML models used for this article does not consider the actions attached to states, such as do, entry and exit actions.

3 / 12 Volume X (2007) Refactoring of UML models using AGG

Figure 2: UML State Machine Diagram - Before refactoring

Figure 3: UML State Machine Diagram - After refactoring

Figure 4 shows the control flow of this model refactoring that is composed of more primitive refactoring actions. The syntax of UML Interaction Overview diagrams has been used to formally depict the control flow and to specify in which order the action must be executed. Some custom notations have been added to enrich the diagram with all necessary information. In particular, input and output parameters for each atomic step have been specified. In order to apply the refactoring, it is necessary to provide two input parameters r and s. The parameter r specifies which composite state, or region, will be modified by the refactoring. The parameter s specifies which will be the default state of the region. Before applying the refactoring it is necessary to verify that the composite state does not contain an initial pseudostate; this check will be implemented as a pre–condition. If the pre–condition is respected, the refactoring proceeds by creating the initial pseudostate

Proc. Software Evolution 2007 4 / 12 ECEASST

Figure 4: Introduce Initial Pseudostate model refactoring, speciﬁed as UML Interaction Overview diagram

inside the composite state. Subsequently, the refactoring changes the target of all transitions pointing to the default state. The new target state of those transitions will become the composite state that contains the region r. For technical reasons, a ﬁnal cleanup phase is needed in order to remove auxiliary elements that have been added during the transformation process.

3 Formal representation as graph transformation

UML models can be represented as a graph–based structure, and graphs must conform to the corresponding type graph just like the models must conform to their metamodel.A type graph corresponding to the UML metamodel is required to formally represent the UML models as graphs and to formally define the UML model refactoring. 1 For the purpose of this article, we have chosen to take into account a subset of the concepts defined by the UML metamodel. In particular, we focus on UML State Machine diagrams only. Figure 5 shows the type graph corresponding to the UML metamodel of figure 1. This type graph has been created using the AGG graph transformation tool. AGG offers many concepts that are useful to define a type graph very close to the corresponding UML metamodel. AGG allows enrichment of the type graph with a generalisation relation between nodes, and each node type can have one or more direct ancestors (parents) from which it inherits the attributes and edges. Moreover, it is also possible to define a node type as an abstract type, thereby prohibiting creation of instance nodes of this abstract type.

1 For a detailed account on the relation between refactoring and graph transformation, we refer to [Men05].

5 / 12 Volume X (2007) Refactoring of UML models using AGG

Figure 5: UML State Machine diagram – Type Graph

The primitive refactoring actions shown in figure 4 can be implemented by means of graph transformation rules. Transformation rules are expressed mainly by two object structures: the left–hand side (LHS) of the rule specifies a sub–graph to search for, while the right–hand side (RHS) describes modifications generated by the transformation. The LHS and the RHS of a rule are related by a partial graph morphism. The applicability of a rule can be further restricted by additional negative application conditions (NACs). The LHS or a NAC may contain constants or variables as attribute values, but no Java expressions, in contrast to an RHS. The first step, named Create Initial Pseudostate is shown in figure 6. It contains a NAC to ensure that the region does not contain an initial pseudostate. The state s provided as input parameter (node number 3 in the figure) will become the default state of the region. The strName variable used in the rule is not an input parameter but is needed in order to define the name of the initial pseudostate.

Figure 6: Introduce Initial Pseudostate - Create Initial Pseudostate Input Parameters r : Region ⇒ node1; s : State ⇒ node3

Proc. Software Evolution 2007 6 / 12 ECEASST

The state s provided as input parameter must be part of a composite state otherwise application of this kind of refactoring is no longer possible. If the pre–condition is respected, the transformation rule marks the default state with an auxiliary “Refactoring” node in order to recognize it during the execution of the subsequent steps. The second step, named Move Incoming Transition, is shown in figure 7. It takes into account the transitions which have the default state defined as target (the auxiliary “Refactoring” node is used to identify the default state). The transformation rule replaces the target edge of a transition by one pointing to the composite state. For this transformation rule a NAC has been added in order to ensure that only the transitions that are defined outside the region will be modified. The rule must be repeated as long as possible (i.e., until no further match can be found).

Figure 7: Introduce Initial Pseudostate - Move Incoming Transition

The last step, named Remove Temporary Reference is shown in ﬁgure 8. It removes the auxiliary “Refactoring” node that has been attached to the default state during the execution of the ﬁrst rule.

Figure 8: Introduce Initial Pseudostate - Remove Temporary Reference

4 Tool support

In this section, we illustrate the possibility of developing model refactoring tools using graph transformations. For this purpose, we have developed a prototype application that serves as a feasibility study. The AGG graph transformation engine [TU 06] is delivered together with an API (Application Programming Interface) that allows to integrate the internal graph transformation engine into other environments.

7 / 12 Volume X (2007) Refactoring of UML models using AGG

We used this API to develope our prototype application. That way, deﬁnition of the graph transformation rules presented in section 3 has been possible. Figure 9 shows the graphical user interface of the model refactoring application that we developed in Java by making use of the AGG API.

Figure 9: Model Refactoring Application

The application internally loads a file containing the model refactoring specifications and the necessary graph transformation rules. It then allows to open files containing the UML models to be refactored that respect the type graph. Using the “Refactoring” context menu, the user can apply the different model refactorings. When necessary the user will be prompted to enter the input parameter values and possibly to supply a match if the model refactoring can be applied to different parts of the UML model. The representation of the control flow explained in figure 4 has been a crucial point for the implementation of the prototype application. The control flow describes the order in which the individual graph transformation rules of each model refactoring have to be executed. At the moment, the AGG tool does not provide a satisfactory solution for organizing and combining rules, and the supplied mechanisms were not sufficient for describing model refactorings. The prototype application avoids the underlying problem by using a custom control structure that represents the control flow of model refactorings. Based on the UML Interaction Overview diagram syntax, we have represented the control flow as a graph structure, which is used to drive the application of graph transformation rules. Figure 10 presents the type graph that we have defined in AGG in order to represent this control flow. When the prototype application needs to apply a model refactoring, it first loads the corresponding graph representing the control flow. It searches the starting point and walks through the graph to determine which graph transformation rules have to be applied. It continues exploring the graph until it reaches a final point, and reports the result to the user.

Proc. Software Evolution 2007 8 / 12 ECEASST

Figure 10: Interaction Overview Diagram – Type Graph

Figure 11 shows the control ﬂow we have implemented for the Introduce Initial Pseudostate refactoring. It corresponds to the UML Interaction Overview diagram reported in ﬁgure 4.

Figure 11: Control Flow – Introduce Initial Pseudostate

The prototype application has been enriched with an interpreter in order to evaluate the expression of decision points. That way, implementation of complex transformations is made possible.

5 Discussion

For the purpose of model refactoring, an important advantage of graph transformation is that rules may yield a concise visual representation of complex transformations. Unfortunately, as

9 / 12 Volume X (2007) Refactoring of UML models using AGG identified by [HJV06], the current state–of–the–art in graph transformation does not suffice to easily define model refactorings, and their expressive power must be increased. Two mechanisms have been proposed so far: one for cloning, and one for expanding nodes by graphs. Concerning the AGG tool in particular, there are some limitations. The AGG tool does not allow to represent concepts like Aggregation and Composition used by the UML metamodel. Therefore, the type graph has been simplified by using the more generic concept of association. Moreover, AGG does not have the notion of Enumeration type. The property kind of the Pseudostate element has been represented using a String value. The AGG tool does not allow to specify optional patterns inside graph transformation rules. Therefore, it is necessary to create similar graph transformation rules that take into account the different optional patterns. For example, the “Guard” nodes may be associated or not to a transition. In order to match transitions with an associated “Guard” and transitions without “Guard”, creation of two different graph transformation rules is necessary. The AGG tool does not provide a satisfactory control structure for organizing and combining rules, and the supplied mechanisms for composing rules were not sufficient to describe model refactorings. In order to reach our goal we have represented the execution order of rules by means of graphs that are used to drive the control flow of model refactorings. That way, we have added the notion of “controlled” graph transformation, which was not previously available in AGG. As an alternative to AGG, we have also explored the MOFLON meta modeling framework [Rea06] in order to give a better advice about the possibility to implement model refactorings using graph transformation. The MOFLON tool allows a better representation of UML models, due to the similarities between the UML metamodel and the MOFLON concepts. Moreover, the MOFLON tool supports a number of advanced transformation concepts and additional forms for structuring rule sets.

6 Conclusion and Related work

[MT04] provided a detailed survey of research on software refactoring, and suggested model refactoring as one of future challenges. In this article, we have shown how the formalism of graph transformation can be used as an underlying foundation for the specification of model refactoring. We have developed a prototype application in order to verify the usability of graph transformations for the purpose of model refactorings. The prototype application shows that it is possible to develop model refactoring tools this way. However, it is necessary to improve the graph transformation notation in order to better support the specification of model refactorings. Future work should formally explore the characteristics of model refactoring paying more attention on the preservation of the behaviour. Model refactoring is a rather recent research issue and such definitions of behaviour preservation properties have not yet been completely given. There are some proposals about behaviour preservation but, in the context of the UML, such definitions do not exist because there is no consensus on a formal definition of behaviour. A UML model is composed of different diagrams that address different aspects of a software system. The application of model refactorings may generate inconsistencies between these UML

Proc. Software Evolution 2007 10 / 12 ECEASST diagrams. Future work should explore the possibility to preserve the consistency among different kind of UML models after the application of model refactoring expressing inconsistency detec- tions and their resolutions as graph transformation rules. Mens, Van Der Straeten and D’Hondt [MVD06] propose to express inconsistency detection and resolutions as graph transformation rules, and to apply the theory of critical pair analysis to analyse potential dependencies between the detection and resolution of model inconsistencies. The Object Constraint Language (OCL) is a formal language used to impose additional well– formedness constraints on UML models. These constraints typically specify invariants that must hold for the system being modeled. OCL expressions need to be taken into account when specifying model refactorings in AGG. This can be achieved by expressing them using so-called “graph constraints” in AGG. Other researchers are exploring the possibility to implement the automatic conversion of UML models to graphs and vice versa. One in particular, made by Laurent Scolas, presents a possible approach for the conversion of UML State Machine diagrams to graphs. [Sco07] Future work should integrate model refactoring support in standard UML modeling environments. For example, the Tiger EMF transformation framework, developed in Berlin by the AGG Team, is a tool environment that allows to generate an Eclipse editor plugin based on the Eclipse Modeling Framework (EMF) and the Graphical Editing Framework (GEF) using AGG as underlying engine. [BEK+06]

Bibliography

[BEK+06] E. Biermann, K. Ehrig, C. Kohler,¨ G. Kuhns, G. Taentzer, E. Weiss. Graphical Deﬁ- nition of In-Place Transformations in the Eclipse Modeling Framework. Pp. 425–439. 2006.

[EM93] H. Ehrig, Michael Lowe.¨ Parallel and distributed derivations in the single-pushout approach. Theoretical Computer Science 109:123–143, 1993.

[Fol07] A. Folli. UML Model Refactoring using Graph Transformation. 2007. Master Thesis, Universite´ de Mons-Hainaut.

[Fow99] M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.

[HJV06] B. Hoffmann, D. Janssens, N. Van Eetvelde. Cloning and Expanding Graph Transfor- mation Rules for Refactoring. Proc. Int’l Workshop on Graph and Model Transfor- mation (GraMoT 2005) 152:53–67, 2006.

[Men05] T. Mens. On the use of graph transformations for model refactoring. In Ralf Lammel¨ (ed.), Generative and transformational techniques in software engineering. Pp. 67– 98. Departamento di Informatica, Universidade do Minho, 2005.

[Men06] T. Mens. On the Use of Graph Transformations for Model Refactoring. In GTTSE. Pp. 219–257. 2006.

11 / 12 Volume X (2007) Refactoring of UML models using AGG

[MT04] T. Mens, T. Tourwe.´ A Survey of Software Refactoring. IEEE Transactions on Soft- ware Engineering 30(2):126–162, February 2004.

[MTR07] T. Mens, G. Taentzer, O. Runge. Analysis refactoring dependencies using graph transformation. Software Systems Modeling (SoSyM), 2007.

[MVD06] T. Mens, R. Van Der Straeten, M. D’Hondt. Detecting and Resolving Model Incon- sistencies Using Transformation Dependency Analysis. In Proc. Int’l Conf. MoDELS 2006. Lecture Notes in Computer Science 4199, pp. 200–214. Springer-Verlag, Oc- tober 2006.

[Obj05a] Object Management Group. Uniﬁed Modeling Language: Infrastructure version 2.0. formal/2005-07-05, August 2005. www.omg.org

[Obj05b] Object Management Group. Uniﬁed Modeling Language: Superstructure version 2.0. formal/2005-07-04, August 2005. www.omg.org

[Opd92] W. F. Opdyke. Refactoring: A Program Restructuring Aid in Designing Object- Oriented Application Frameworks. PhD thesis, University of Illinois at Urbana- Champaign, 1992.

[Rea06] Real-Time Systems Lab, Darmstadt University of Technology. MOFLON, version 1.0.0. December 15 2006. www.moﬂon.org

[Sco07] L. Scolas. Conversion de modeles` UML en format de graphes. 2007. Master Thesis, Universite´ de Mons-Hainaut.

[SK03] S. Sendall, W. Kozaczynski. Model transformation: The heart and soul of model- driven software development. IEE Software, pp. 42–45, 2003.

[Tae99] G. Taentzer. AGG: A tool environment for algebraic graph transformation. In Appli- cations of Graph Transformations with Industrial Relevance. Lecture Notes in Com- puter Science 1779, pp. 481–488. Springer-Verlag, 1999.

[TU 06] TU Berlin. The Attributed Graph Grammar System, version 1.5.0. 2006. tfs.cs.tu-berlin.de/agg/index.html

Proc. Software Evolution 2007 12 / 12 ECEASST

Lightweight Visualisations of COBOL Code for Supporting Migration to SOA

Joris Van Geet1 and Serge Demeyer2

[email protected], [email protected] http://www.lore.ua.ac.be/ University of Antwerp, Belgium

Abstract: In this age of complex business landscapes, many enterprises turn to Service Oriented Architecture (SOA) for aligning their IT portfolio with their business. Because of the enormous business risk involved with replacing an enterprise’s IT landscape, a stepwise migration to SOA is required. As a ﬁrst step, they need to understand and assess the current structure of their legacy systems. Based on existing reverse engineering techniques, we provide visualisations to support this process for COBOL systems and present preliminary results of an ongoing industrial case study. Keywords: SOA migration legacy reverse-engineering visualisation COBOL

1 Introduction

Mismatches between business and IT pose a threat to the agility with which enterprises can adapt to changing requirements. In an attempt to ensure their competitive advantage, some enterprises are turning to Service Oriented Architectures as a means to align their IT portfolio with their business. Because of the enormous business risk involved with replacing an enterprise’s IT landscape, a stepwise migration to SOA is required. The Service Oriented Migration and Reuse Technique (SMART) [LMS06] is an existing methodology for defining a migration process consisting of five distinct phases. First you should (1) establish the stakeholder context, (2) describe the existing capabilities, (3) and describe the target SOA state in an iterative and incremental manner. Based on these results you can (4) analyse the gap between the existing capabilities and the target state, after which you can (5) develop a migration strategy. All these phases can — and should — be supported by reverse engineering techniques and tools. As a first step, enterprises need to assess the current structure of their legacy system(s). Such a First Contact [DDN02] typically aims at building an overall mental model of the system at a high level of abstraction. During this process exceptional entities become apparent, which can be studied afterwards. As building a mental model of large legacy systems is not a trivial task, this process is usually supported by (visualisation) tools [SFM97]. Studies show that COBOL mainframes process more than 83% of all transactions worldwide and over 95% of finance and insurance data [AAB+00]. Needless to say that maintaining these systems is of vital importance, which is why we focus our efforts on COBOL. Unfortunately,

1 / 12 Volume X (2007) there is not one standard COBOL language: many variants and dialects have manifested themselves over the years. To cope with this plethora of COBOL variations, lightweight parsing techniques are preferred. In this position paper we present such a lightweight technique for visualising functional dependencies and data dependencies between COBOL programs. After a short introduction to services and what it could (should?) mean for reengineering legacy systems (Section 2) we present our data model on COBOL, deﬁne structural properties of this data and explain their usefulness in the context of migration to SOA (Section 3). Then we deﬁne views on this structure and explain how they should be interpreted (Section 4). We provide an initial experience report of an ongoing industrial case study in Section 5 and suggest improvements to our approach in Section 6. Related work is discussed in Section 7 after which we conclude.

2 The Service Concept

As a result of the increasing interest in SOA, many interpretations have been given to the concept of a service. Ranging from an enabler of a capability accessible through a prescribed interface and consistent with predeﬁned constraints and policies [OAS06] to technical, network-centric implementations typically based on web-services1. In fact, the term services science has been coined as it reaches far beyond software engineering or even computer science [SR06]. In an enterprise context, however, a service can be best described as a way to specify encapsulated business functionality independent from concrete implementations. In this context, a service is more of a business concept than an IT concept. This means that we cannot simply identify services from the source code of a legacy system, because a thorough understanding of the organisation and the domain is required. We can, however, make the functional dependencies within the legacy system explicit and highlight the exceptional entities. This information can generate discussion with the domain experts and enterprise architects to ﬁnd out which of these entities pose a threat for migrating to SOA. In this context a service would, ideally, be implemented as a loosely coupled component [KBS04]. Indeed, the effort required to extract a ‘service’ can reasonably be expected to increase with the number of dependencies originating from or targeting the associated source code.

3 Characterising Source Dependencies

3.1 COBOL Artefacts As a means to characterise functional and data dependencies in COBOL source code, the following artefacts are of interest. • A program is a functional block of COBOL code uniquely identiﬁed by a Program-ID. Programs are the basic building blocks of a COBOL system. • A copybook is a reusable snippet of COBOL code, contained within one source ﬁle, that usually consists of a data declaration to be shared by different programs.

1 http://www.w3.org/2002/ws/

Proc. Software Evolution 2007 2 / 12 ECEASST

• A CALL statement is responsible for invoking a program from within another program using its unique Program-ID. The thread of execution is then passed on to the called program until the execution ends and the control returns to the calling program. • A COPY statement is responsible for copying the contents of a copybook directly into the COBOL source. This construct enables code level reuse of data declarations. • A missing program or copybook is a program or copybook that is referenced from within the system under study but not part of the system itself. They have been identiﬁed as IDs used in CALL and COPY statements which we could not map to available source ﬁles. Currently, we extract this information from the COBOL sources with a PERL script using simple regular expression functionality implemented in the standard UNIX tool GREP. This provides us with the necessary robustness for parsing COBOL. Note that there are typically two usage modes of COBOL programs on mainframe, namely online and in batch. In online mode programs interact via COBOL calls, in batch these programs can also be invoked from mainframe scripts, usually JCL2. We have not taken into account the JCL artefacts, thus we are missing some, perhaps important, information.

3.2 Structural Properties

Using the same PERL script, we extract the following dependencies from these source code artefacts. • A functional dependency is a relationship between two programs implemented by a CALL statement in the first program referencing the second program. This dependency has a weight associated with it equalling the number of CALL statements from the first to the second program. • A data dependency is a relationship between a program and a copybook implemented by a COPY statement in the program referencing the copybook. The same dependency can occur between two copybooks. These functional dependencies are interesting because they provide a measure for the ease of separating programs: a group of programs sharing a lot of functional dependencies will be harder to separate than a group of programs sharing little or no dependencies. Furthermore, strongly interdependent programs might be working together to implement a certain functionality. In the same way, data dependencies might reveal groups of programs working on the same data. Besides these dependencies, we also define metrics on a COBOL program. • The number of incoming calls (NIC) measures the total number of CALL statements referencing that program. • The number of outgoing calls (NOC) measures the total number of CALL statements within that program to any other program. We study these metrics because they are an indicator for the types of usage of COBOL pro- grams3. Programs with a high NIC can be seen as suppliers as they supply a functionality that is popular among other programs. As a special case of suppliers, programs with a high NIC and a NOC of zero can be seen as libraries as they are likely to supply core functionalities since they do not rely on other programs. Programs with a high NOC, on the other hand, can be

2 JCL stands for Job Control Language. 3 The terminology of suppliers , clients and libraries has been adopted from [MM06].

3 / 12 Volume X (2007) seen as clients as they use a lot of functionality from other programs. Putting these concepts in a service-oriented mindset, suppliers (and libraries) might provide good starting points for services whereas clients will most likely be service consumers.

4 Views

We use a visual representation of this information as it provides the ability to comprehend large amounts of data [War00]. More specifically, directed graphs have been shown to be natural representations of software systems. Enriching these entities with metrics information provides valuable visual clues for early structure comprehension [LD03]. To obtain such visualisations we export the structural information to GDF (Guess Data For- mat) after which it can be visualised in GUESS [Ada06], a flexible graph exploration tool. This environment assists a user in exploring graphs by providing capabilities such as applying graph layouts, highlighting, zooming, moving and filtering. In what follows we define two views based on the structural relations defined in Subsection 3.2, namely the Functional Dependency View and the Data Dependency View. For each view we identified some visual indicators of structural properties and grouped them according to a specific task. We motivate the task, present visual indicators and interpret them in light of the specific task.

4.1 Functional Dependency View The building blocks of this view are COBOL programs and the functional dependencies between them. To distinguish programs from missing programs we use white rectangles and black rectangles respectively. A functional dependency between two programs is implemented as a directed edge between two nodes. Furthermore, the height and width of the nodes are relative to the NIC and NOC metrics of the corresponding program respectively. We use the Graph EM- bedder (GEM) algorithm [FLM94] as a layout algorithm because it tries to minimise the sum of the edge lengths in order to provide an easy to interpret layout. This layout positions highly connected nodes closer together thereby providing a visual indication of possible clusters and groups.

4.1.1 Overall Design

Intent — Get a feel for the overall design of the system. Motivation — Functional dependencies reveal ﬁrst hand information on the complexity of the design. Identifying strongly interdependent groups of programs can reveal opportunities or risks early in the project. Visual Indicators (Figure 1) — Isolated nodes (a) have no edges, whereas a monolith (d) has an abundance of edges between all nodes. Disconnected clusters (b) are isolated groups of interconnected nodes, whereas with connected clusters (c) the groups are connected by few edges.

Proc. Software Evolution 2007 4 / 12 ECEASST

(a) Isolated nodes (b) Disconnected Clusters (c) Connected Clusters (d) Monolith Figure 1: Overall Design Indicators

Interpretation — Assuming that functional dependencies are the only way to access a program, isolated nodes and small disconnected clusters would reveal dead code. On the other hand, if there are other functional dependencies which are not part of our model, these nodes might reveal clearly separated functional blocks. Connected but loosely coupled clusters of nodes indicate functional blocks that are easy to separate.

4.1.2 Exceptional Entities

Intent — Locate clients, suppliers and libraries. Motivation — Easily detecting exceptional entities helps in quickly gaining focus in the usual abundance of information. Visual Indicators (Figure 2) — Clients are visually represented as very wide nodes (a), usually with many outgoing edges, whereas suppliers can easily be identiﬁed as very tall nodes (b), usually with many incoming edges. A combination of both results in a tall and wide node (c). Libraries are a special form of supplier as they have no outgoing edges (d).

(a) Client (b) Supplier (c) Client & Supplier (d) Library Figure 2: Exceptional Entities

Interpretation — Suppliers and libraries, both characterised by a high NIC, indicate a popular functionality in the system. In the best case it could be an interface into an important functionality, although it might as well be a smell indicating bad separation of concerns. Clients (characterised by a high NOC), indicate more high level functionalities. Typically, (graphical) user interfaces exhibit such characteristics. A combination of both client and supplier possibly indicates an interface into lower level functionality (thus, making it a supplier) but delegating the real work to the core programs (thus, making it a client). A library is a lowest level functionality as it does not delegate anything, thus indicating a core functionality of the system.

4.2 Data Dependency View The building blocks of this view are COBOL programs, (missing) COBOL copybooks and the data dependencies between them. To distinguish programs from copybooks we use the rectangu-

5 / 12 Volume X (2007) lar and circular shape respectively. The distinction between copybooks and missing copybooks is implemented using white and black nodes respectively. A data dependency between a program and a copybook or between two copybooks is implemented as a directed edge between two nodes. Note that we do not show missing programs in this view, as they will never contain any data dependencies. As with the Functional Dependency View, we also use the GEM layout for positioning the nodes. Also note that the colour and the dimensions of a program node are intentionally kept in accordance with the Functional Dependency View to easily identify the same programs in the two views.

4.2.1 Data Usage

Intent — Get a feel for the data usage between different programs. Motivation — Especially in data driven environments, data dependencies can provide an entry point into the organisational structure of a company. Quickly identifying common data dependencies or facades clearly separating data usage can provide necessary focus in the remainder of the project. Visual Indicators (Figure 3) — A common data concept is visually represented as a group of programs directly connected to the same copybook (a). A data facade is represented as a program connected to a set of copybooks which are only connected to that program. If the copybooks are mainly missing copybooks we call it an external data facade (c), otherwise it is an internal data facade (b).

(a) Common Data (b) Internal Data Facade (c) External Data Facade Figure 3: Data Usage

Interpretation — As opposed to grouping programs by shared functional dependencies (Sub- subsection 4.1.1), we can also group them according to shared data dependencies. Programs sharing data are likely to work on a similar concept, especially when the data represents a business concept. On the other hand, programs hogging data for themselves are likely to encapsulate certain data and the corresponding functionality, making them more easy to separate.

5 Experience Report

This section describes some preliminary results we obtained during an ongoing case study at a Belgian insurance company. The system under study is a document generation and management system consisting of 200k lines of COBOL code with embedded SQL (including whitespace and comments), divided over 401 COBOL programs and 336 COBOL copybooks, and 38k lines of JCL (from which we did not extract any information). Extraction of the COBOL artefacts and

Proc. Software Evolution 2007 6 / 12 ECEASST

Figure 4: Functional Dependency View, height and width of the nodes represent NIC and NOC respectively. creation of the data model, as described in Section 3, was completed in less than five seconds indicating that the approach is indeed very lightweight and likely to scale well on even bigger systems. Figure 4 depicts the Functional Dependency View of the system. The first thing you notice is the typical monolithic nature of the legacy system. Almost everything seems to be interconnected with no apparent order or hierarchy. There are some isolated nodes on the bottom and the right (A) that would seem to constitute dead code, as they have no functional dependencies. Although closer investigation did reveal some empty files, not all nodes are by definition dead code as they can be called directly from JCL scripts running on mainframe. The small disconnected clusters on the right show a distinct pattern (B): one parent node functionally depending on three child nodes. Closer investigation revealed that each cluster is responsible for accessing and modifying a specific part of the documents database. Each group of three child nodes is responsible for respectively inserting, deleting and updating corresponding records. When looking for exceptional entities, the most pertinent supplier is the tallest white node (S1). Closer investigation revealed that this program is indeed a supplier as it provides the interfacing program into all the disconnected clusters on the right. It collects all user and application requests for adjusting the documents database and forwards those request to the correct cluster. Although

7 / 12 Volume X (2007) Figure 5: Data Dependency View. one would expect a functional dependency between this supplier and the clusters, this is not the case because processing the request is performed asynchronously (in batch). Therefore, the functional dependency is not visible in the COBOL files, but rather in JCL scripts running on mainframe. Other suppliers include a program for visualising errors (S2) and an interface into other databases (S3). Besides the white suppliers there are also missing programs (black nodes) that are classified as suppliers. The tallest of them (S4), for example, provides an interface into core mainframe functionality. Many other tall black nodes (e.g., S5, S6) are core programs of the organisation. Besides the very pertinent suppliers, Figure 4 also contains two clients that stand out. The first one (C1), connected to several missing programs, is responsible for automatically filling in documents with information from different databases outside the system under study. This program is classified as a client as it seems to be extensively using data services of other systems. Another client (C2) is responsible for checking the correctness of documents. Although, it delegates its functionalities to three child nodes, the main contribution for classifying it as a client are numerous calls to a module that visualises error messages (S2). One last node that really stands out is the big white rectangle (D) classified as both a client and a supplier. It is the interface into the core of the system under study. It is a supplier for all

Proc. Software Evolution 2007 8 / 12 ECEASST the end programs that feed (graphical) user interface, and wide because it delegates a lot of its responsibilities to lower level suppliers. Figure 5 depicts the Data Dependency View of the system. Besides the monolithic structure on the left, there is one group of nodes that is clearly separated from the rest. This cluster reveals one data concept (E) used by several programs. Closer investigation revealed that the programs in this cluster are the same programs that are responsible for managing the documents database (the disconnected clusters in Figure 4). The central copybook has the capability of uniquely defining one row within this entire documents database. So this database management responsibility is not only functionally clearly separated from the rest of the system, but also with regard to the data dependencies. When consulting the domain experts, they supported this observation and explained that this is actually a subsystem used by other systems as well. For historical reasons it is part of this bigger legacy system, but it was designed to be used as a separate system. Client C3 has many data dependencies with copybooks that have no dependencies with other programs, therefore it acts as an internal data facade. Closer investigation revealed that C3 is the only program responsible for (re)creating and correctly formatting all types of documents. Client program C1, on the other hand, has a lot of data dependencies with missing copybooks (the black nodes above). This is the program that retrieves information from other systems to automatically fill in documents and was characterised by a lot of functional dependencies with missing programs in Figure 4. This link between functional and data dependencies over the two views is not surprising since data definitions are necessary to communicate with these programs. When looking at group1 of copybooks, C1 acts like a data facade for the external data. The copybooks from group2, on the other hand, are also used by other programs, thereby apparently violating the facade property. Closer investigation revealed that the shared copybooks (group2) are necessary for creating the terminal screens, indicating that C1 not only implements business logic on top of external data, but also its GUI functionality.

6 Room for Improvement

Both views suffer from unnecessary cluttering. We will try to eliminate this by identifying and removing omnipresent programs [MM06]. Furthermore, some of the programs classiﬁed as missing programs result from unresolved dynamic calls rather than really being a program outside the system scope. We will try to resolve them if possible (using static techniques), otherwise we will remove them from the model. After uncluttering the views, we believe more meaningful visual patterns will become apparent. Also, the synergy between the two views (e.g., the link between depending on missing programs and using missing copybooks) is something we would like to make more explicit, maybe by using a clearly focussed combined view. Furthermore, our model is far from complete, therefore we would like to take other source code artefacts into account as well. For example, the functional dependencies resulting from the JCL scripts or the data dependencies implemented by global data accesses. Finally, we would like to merge our scripts with FETCH [DV07] — an open-source fact extraction tool chain currently geared towards C(++) but easily allowing extension via its pipe and ﬁlter architecture — as we can then take advantage of more advanced querying mechanisms and

9 / 12 Volume X (2007) and a collection of views already available in FETCH.

7 Related Work

We based our views on the ideas of Lanza’s polymetric views [LD03], aiming at both a lightweight and a visual approach. Although the views as proposed by Lanza are independent from the implementation language, they are mainly targeted at the object oriented paradigm. We apply this polymetric view concept to COBOL and target our views to anlysing the reuse potential in a service oriented context. Nyary´ et. al. [NPHK05] support the maintenance of legacy COBOL applications by setting up a COBOL repository. While using much of the same artefacts and dependencies as we use, they go into more COBOL detail (including file references and data fields). Their tool focuses on the repository with simultaneous code browsing resulting in low level abstractions, whereas we aim to create more high level abstractions and uncover visual patterns. Another tool capable of reverse engineering COBOL code is RIGI [MTW93, WTMS95]. They also present graph based visualisations of the system. But while they aim at more general program comprehension activities, our approach is specifically targeted to finding opportunities and risks for migrating to SOA. Furthermore, RIGI has a finer-grained approach to extracting COBOL artefacts, making our approach more lightweight. O’Brien et. al. [OSL05] support migration to services using software architecture reconstruction techniques. While they also visualise functional and data dependencies (using their tool ARMIN), they perform these analyses mainly on object-oriented systems and not on legacy COBOL systems.

8 Conclusion

While enterprises are turning to Service Oriented Architectures for aligning their IT portfolio with their business, migrating the current systems to such an architecture is not trivial. Therefore a stepwise migration is necessary. This research constitutes the initial steps for investigating COBOL systems in the early stage of such a migration project. In preparation of talking to domain architects, it is important for a reengineer to quickly gain an understanding of the COBOL source code structure. The explorative views presented in this paper are a ﬁrst contribution towards this goal as they aim at identifying areas obstructing or facilitating migration to SOA. We already described some noticeable phenomena and use them to make concrete observations. In the future we will conduct more empirical studies to evaluate this approach. The logical next step in the migration process would be to inject domain and organisational knowledge into the views. This way we can see to what degree the structure of the existing systems corresponds to the target SOA state as proposed by the domain experts.

Acknowledgements: This work has been carried out in the context of the ‘Migration to Service Ori- ented Architectures’ project sponsored by AXA Belgium NV and KBC Group NV.

Proc. Software Evolution 2007 10 / 12 ECEASST

References

[AAB+00] E. Arranga, I. Archbell, J. Bradley, P. Coker, R. Langer, C. Townsend, M. Weathley. In Cobol’s Defense. IEEE Software 17(2):70–72,75, 2000. doi:10.1109/MS.2000.10014

[DDN02] S. Demeyer, S. Ducasse, O. Nierstrasz. Object Oriented Reengineering Patterns. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2002.

[DV07] B. Du Bois, B. Van Rompaey. Supporting Reengineering Scenarios with FETCH: an Experience Report. In Third International ERCIM Symposium on Software Evo- lution. October 2007. to appear.

[FLM94] A. Frick, A. Ludwig, H. Mehldau. A Fast Adaptive Layout Algorithm for Undi- rected Graphs. In GD ’94: Proceedings of the DIMACS International Workshop on Graph Drawing. Pp. 388–403. Springer-Verlag, London, UK, 1994.

[KBS04] D. Krafzig, K. Banke, D. Slama. Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series). Prentice Hall PTR, Upper Saddle River, NJ, USA, 2004.

[LD03] M. Lanza, S. Ducasse. Polymetric Views-A Lightweight Visual Approach to Re- verse Engineering. IEEE Trans. Softw. Eng. 29(9):782–795, 2003. doi:10.1109/TSE.2003.1232284

[LMS06] G. Lewis, E. Morris, D. Smith. Analyzing the Reuse Potential of Migrating Legacy Components to a Service-Oriented Architecture. In CSMR ’06: Proceedings of the Conference on Software Maintenance and Reengineering. Pp. 15–23. IEEE Com- puter Society, Washington, DC, USA, 2006. doi:10.1109/CSMR.2006.9

[MM06] B. S. Mitchell, S. Mancoridis. On the Automatic Modularization of Software Sys- tems Using the Bunch Tool. IEEE Trans. Softw. Eng. 32(3):193–208, 2006. Brian S. Mitchell and Spiros Mancoridis. doi:10.1109/TSE.2006.31

[MTW93] H. A. Muller,¨ S. R. Tilley, K. Wong. Understanding software systems using reverse engineering technology perspectives from the Rigi project. In CASCON ’93: Proceedings of the 1993 conference of the Centre for Advanced Studies on Collab- orative research. Pp. 217–226. IBM Press, 1993.

11 / 12 Volume X (2007) [NPHK05] E. Nyary,´ G. Pap, M. Herczegh, Z. Kolonits. Supporting the Maintenance of legacy COBOL Applications with Tools for Repository Management and Viewing. In ICSM (Industrial and Tool Volume). Pp. 5–10. 2005.

[OAS06] OASIS Consortium. Reference Model for Service Oriented Architecture 1.0. July 2006. http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED. pdf

[OSL05] L. O’Brien, D. Smith, G. Lewis. Supporting Migration to Services using Software Architecture Reconstruction. step 0:81–91, 2005. doi:10.1109/STEP.2005.29

[SFM97] M.-A. D. Storey, F. D. Fracchia, H. A. Mueller. Cognitive Design Elements to Sup- port the Construction of a Mental Model during Software Visualization. In WPC ’97: Proceedings of the 5th International Workshop on Program Comprehension. P. 17. IEEE Computer Society, Washington, DC, USA, 1997. doi:10.1109/WPC.1997.601257

[SR06] J. Spohrer, D. Riecken. Services science. Commun. ACM 49(7), July 2006.

[War00] C. Ware. Information visualization: perception for design. Morgan Kaufmann Pub- lishers Inc., San Francisco, CA, USA, 2000.

[WTMS95] K. Wong, S. R. Tilley, H. A. Muller, M.-A. D. Storey. Structural Redocumentation: A Case Study. IEEE Software 12(1):46–54, 1995. doi:10.1109/52.363166

Proc. Software Evolution 2007 12 / 12

ECEASST

Package Evolvability and its Relationship with Refactoring

A. Mubarak1, S. Counsell1, R.M. Hierons1 and Y. Hassoun2

1 {asma.mubarak, steve.counsell, rob.hierons} @brunel.ac.uk Department of Information Systems and Computing Brunel University, Uxbridge, Middlesex, UK

2 [email protected] Department of Computer Science, King’s College, London, UK

Abstract In this paper, we address a set of research questions investigating trends in changes to an open-source system (OSS). An interesting ‘peak and trough’ effect trend was found to exist in the system studied, suggesting that developer activity comprises of a set of high and low periods. Trends in overall changes applied to the system were complemented with empirical evidence in refactoring data for the same system; this showed a similar peak and trough effect but at different versions of the same system. This result suggests a contrasting motivation between regular maintenance practice and that of refactoring. Our analysis of high-level package trends informed some interesting cross-comparisons with refactoring practice, and some insights into why refactoring might be applied after a burst of regular change activity, rather than consistently.

1. Introduction A software system is modified and developed many times throughout its lifetime to maintain its effectiveness. In general, it grows and changes to support increases in information technology demands. While from a research perspective, we know a reasonable amount about facets of Object-Oriented (OO) and procedural system evolution Belady and Lehman (1976), Bieman et al., (2003), Arisholm et al., (2006), relatively less well-understood is whether changes at the package level exhibit any specific trends. The benefits of such a study are clear. Understanding changes at higher levels of abstraction may give a project manager a much more broad-brush idea of likely, future maintenance or refactoring opportunities. In particular, such a study may also be able to focus developer effort in specific areas of packages susceptible to large numbers of changes. A further area of interest to OO researchers and practitioners is the link between maintenance as part of every system’s evolution and that dedicated to refactoring Fowler (1999), Mens and Tourwe (2004). In this paper, we investigate the trends in versions of the ‘Velocity’ Open-Source System (OSS), with respect to added classes, methods, attributes and lines of code. To support our analysis, we also looked at empirical refactoring data for the same system and associated trends for two other Java OSSs. We suggest that if the set of regular (i.e., essential) maintenance changes exhibit specific characteristics then a set of specific refactorings will also exhibit similar features. Results showed an interesting discrepancy between trends in those regular changes made to the system

2 / 11 Volume X (2007)

Package Evolvability and Refactoring studied and those as part of a specific set of changes according to refactorings specified in Fowler (1999).

2. Related Work From an empirical stance, the relationship between OO classes and packages is not well- defined. Ducasse et al. (2005) suggest that it is necessary, for the re-engineering and development of OO systems, to recognize and investigate both sets of classes and packages. Focusing on the latter provides a means of comparison with previous work focusing on class changes only. The same authors also suggest that packages have varying functions: they may include utility classes or they may include some fundamental sub-classes enlarging a framework. Ducasse et al. (2004) suggest that the cost of modifying a program may be influenced by the relationship between packages and their enclosed classes. To support the developer in achieving a mental image of an OO system and understanding its packages, they introduce a top-down engineering method based on visualization. Consequently, they raise the abstraction level by detecting packages rather than classes; classifying packages at a high-level prevents developers from being flooded with information. Bieman et al., (2003) found a relationship between design structures and development and maintenance changes. The same study tried to examine whether potential changes to a class could be predicted by the architectural design context of a class. They found that in four of five case-studies, classes which have function in design patterns were modified more frequently than other classes Gamma et al., (1995). In terms of the architecture of a system, Bieman et al., (2001), found that classes belonging to a design pattern were the most change-prone classes in a system (this might also suggest that change-prone classes are implemented by design patterns). Finally, Demeyer et al. (2000) identified refactoring indicators when comparing different releases of a software system. They used four heuristics to find refactorings; each was identified as a mixture of change metrics.

3. Data Analysis

The main objective of the research described is to assess how a system changes through the analysis of packages in the system and to compare that data with corresponding results from refactoring the same system. Knowledge of trends and changes within packages is a starting point for an understanding of how effective the original design may have been, how susceptible types of packages may be to change and can also inform our knowledge of facets of software such as coupling and cohesion. To this end, a case study approach was adopted using multiple versions of an evolving system. This system was a large OSS called ‘Velocity’ – a template engine allowing web designers to access methods defined in Java. For each version, we collected the number of added classes, lines of code (LOC), methods and attributes. Hereafter, we define a LOC as a single executable statement; we therefore disregard comment lines and white space from calculation of LOC.

3.1 The Three Research Questions

Proc. Software Evolution 2007 3 / 11

ECEASST

• RQ1: Does the number of new classes over the course of nine selected versions increase constantly? This question is based on the notion that a system will grow over time in a constant fashion in response to regular changes in requirements. • RQ2: Is the increase in LOC over the course of the nine versions constant? This question in based on the assumption that the change in LOC over the nine versions will always increase due to evolutionary forces. • RQ3: Is the increase in the number of attributes and methods in a package constant across the versions of a system? This question is posed on the assumption that the change in the number of attributes and methods will increase consistently over time in response to constant changes in requirements.

3.1.1. Research Question 1 (RQ1)

Table 1 shows the number of packages in each of the nine versions, the number of new classes across those packages, the number of new classes in total, the maximum increase in classes and the package name where that increase took place. In each of the nine versions, new classes were added to packages and the number added varied significantly from one version to another. Between versions three and four and six and seven, relatively little change can be seen, while the peak of added classes is reached in the fifth version with 2032 new classes added. Clearly, the addition of classes to this system over the versions investigated is not constant. Interestingly, the version with the highest number of new classes was also accompanied by a drop in the number of packages (from 42 to 36). Equally, some of the largest additions to classes were made after only minor changes to the numbers of packages. Both effects may possibly be due to classes being moved around in the same package and simply renamed.

Table 1. Packages and the new classes over the course of nine versions No. of No. of new Max Version Package name packages classes inc. 1st 28 788 176 Editor 2nd 32 1116 207 Java 3rd 38 17 5 Core 4th 42 11 3 Javadoc 5th 36 2032 329 Debuggerjpda 6th 39 45 13 Openide 7th 39 297 92 Core 8th 38 1274 357 Web 9th 39 1386 217 Core

A feature not immediately apparent from the data in Table 1 is the peak and trough effect of this data. A graph was therefore used to present the changes in the number of the new added classes (Figure 1). We suggest that this trend is symptomatic of a burst of developer change activity followed by a period of relative stability and accumulation of new requirements, before another burst of change activity. For RQ1, we conclude that the number of new classes over the course of the nine versions increases at an inconsistent rate, rather than remaining

4 / 11 Volume X (2007)

Package Evolvability and Refactoring constant. It is not the case that there is constant addition of classes to the Velocity system over the nine versions investigated; RQ1 cannot thus be supported.

Figure 1. Line chart of new classes added to the packages over the nine versions

3.1.2. Research Question 2 (RQ2)

To investigate RQ2, the ‘maximum’ increase in the number of LOC among all the versions was used. The data is presented in Table 2. It can be seen that there are increases in LOC over the course of the versions but these increases fluctuate wildly. Interestingly, the Core and Vcscore packages were the packages that saw the maximum increases in LOC for five of the versions. The Core package is the only common package to Tables 1 and 2, suggesting that the addition of a large number of classes does not necessarily imply the addition of a correspondingly large number of LOC. One explanation for this feature might simply be that one class has been split into two (c.f., the ‘Extract Class’ refactoring of Fowler (1999)).

Table 2. Max. increase in the number of LOC over the course of the nine versions

Version Max inc in LOC Package name 1st 3955 Core 2nd 5077 Form 3rd 889 Vcscore 4th 910 Javacvs 5th 6985 Vcscore 6th 1109 Vcsgeneric 7th 369 Core 8th 6418 Core 9th 6743 Schema2beans

Figure 2. Line chart of the max increase in the number of LOC (nine versions)

Proc. Software Evolution 2007 5 / 11

ECEASST

Figure 2 confirms that the increases in the number of lines of code over the course of the nine versions fluctuates across versions. Again, the peak and trough effect is apparent from the figure. The most significant changes to Vcscore appear in the first five versions and those of Core appear in the seventh and eighth versions; RQ2 cannot be supported either.

3.1.3. Research Question 3 (RQ3)

For RQ3, the maximum increase in the number of the attributes, and the maximum increase in the number of the methods for each version were used. This data is presented in Table 3 and shows that over the course of the nine versions there are consistent increases in the number of attributes (A) and number of methods (M). However, these increases vary from one version to another. The largest increase in the number of the attributes and methods is at version five. Once again, two packages dominate Table 3 - those being Core and Vcscore (seven of the eighteen entries in columns 4 and 7 relate to these two packages). As per Table 2, the maximum increase in methods occurs at earlier versions for Vcscore, and, for Core, towards later versions.

Table 3. Summary of the increase in the no. of attributes and methods over the nine versions Inc in Max Inc in Package Inc in Max Inc in Version Package name A A Name M M 1st 153 26 Core 228 36 Vcscvs 2nd 262 49 Form 335 84 Vcscore 3rd 25 7 Jndi 46 11 Vcscore 4th 24 7 Diff 22 6 Diff 5th 325 51 Form 489 70 Vcscore 6th 39 10 Debuggercore 73 14 Openide 7th 17 4 I18n 29 6 Core 8th 238 57 Core 371 150 Core 9th 226 34 Java 378 76 Xml

Figure 3. Inc. in attributes and methods Figure 4. Max. inc. in attributes and methods

Figure 3 shows that the number of the attributes and number of methods both increase during the course of the nine versions, but at a fluctuating rate. Version four shows that more attributes were added than methods; the pattern for all other versions is the opposite. In contrast with the previous analysis, Figure 4 shows that version eight appears to be the source

6 / 11 Volume X (2007)

Package Evolvability and Refactoring of the largest increase in methods. In keeping with the results from RQ1 and RQ2, we conclude for RQ3 that the increase in attributes and methods is not constant across the nine versions investigated. While the results so far give a fairly intuitive understanding of how a system might evolve, what is not so clear is the relationship between the ‘regular’ set of changes as we have described them, and the opportunities for undertaking a set of changes such as those associated with refactoring techniques Opdyke (1992), Tourwe and Mens (2003). These are both interesting and potentially fruitful areas of refactoring research as well as challenges facing the refactoring community, Mens and van Deursen (2003).

4. Refactoring Relationships

A current, open research question is whether there is any identifiable relationship between changes as we have described so far and specific refactorings. Beck (2002) suggests that a developer should refactor ‘mercilessly’ and hence consistently. We would therefore expect refactorings for the Velocity System to be consistently applied across all versions.

4.1 Velocity

Table 4 shows the fifteen refactorings collected by a software tool as part of a full study of refactoring in seven Java OSS systems by Advani et al., (2006). The fifteen refactorings were chosen by two developers with industrial experience and reflected, in their opinion, in consultation with Fowler’s text, the common refactorings likely to be made by developers over the course of system’s life.

Table 4. Refactorings for the Velocity system across nine versions No. Refactoring Ver1 Ver2 Ver3 Ver4 Ver5 Ver6 Ver7 Ver8 Ver9 1. AddParameter 0 0 14 0 1 2 0 0 1 2. EncapsulateDowncast 0 0 0 0 0 0 0 0 0 3. HideMethod 0 2 1 0 0 1 0 0 0 4. PullUpField 0 0 4 0 2 4 0 0 0 5. PullUpMethod 0 4 13 0 24 5 0 0 9 6. PushDownField 0 0 0 0 7 0 0 0 0 7. PushDownMethod 0 0 1 0 1 0 0 0 4 8. RemoveParameter 0 0 3 0 1 0 0 0 3 9. RenameField 0 3 14 0 1 2 0 0 3 10. RenameMethod 0 5 11 0 15 14 0 0 10 11. EncapsulateField 0 5 4 0 0 0 0 0 0 12. MoveField 0 0 18 0 1 2 0 0 0 13. MoveMethod 0 3 16 0 3 3 0 0 2 14. ExtractSuperClass 0 1 3 0 8 1 0 0 2 15. ExtractSubClass 0 0 0 0 1 0 0 0 0

Versions 3, 5 and 6 can be seen as the main points when refactoring effort was applied to the Velocity system (these columns are bolded). In versions 1, 4, 7 and 8, zero refactorings were

Proc. Software Evolution 2007 7 / 11

ECEASST applied to this system. Figure 5 shows Table 4 in graphical form (with the ‘per version sum’ of the fifteen refactorings on the y-axis). The figure shows that refactoring effort is applied most significantly at one version (in this case version 3) and thereafter a peak and trough effect can be seen. Comparing the trend in Figure 5 with that in Figures 1-4 suggests that the majority of the refactoring effort occurred between versions where significant changes in classes, LOC, methods and attributes took place; version 3 is a trough in terms of these added features. Conversely, version 5 from Table 4 shows significant refactoring effort to have been applied, coinciding with large changes in the aforementioned features. Version 6 activity (again a trough in terms of Figures 1-4) also shows relatively large amounts of refactoring effort.

A number of conclusions can be drawn from this analysis. Firstly, it is clear that developers do not seem to refactor consistently across the versions of the system studied (Velocity). Secondly, while there is some evidence of peaks in refactoring effort occurring at the same time as large changes in classes, LOC, methods and attributes, refactoring seems to occur largely after a peak of the same type of changes. One of the claims by Fowler as to why developers do not do refactoring is that they simply do not have the time. Finally, in the preceding analysis, and from Figure 5, it is not the initial versions where the majority of regular change activity is applied to a system. We note, as an aside, that a valuable and interesting analysis of specific dates of version release remains a topic of future work. The first question that naturally arises is why refactoring changes tend to follow the regular changes applied to a system? After all, it is quite feasible for refactoring to be carried out at the same time as other changes (there is limited evidence of this occurring from the data). Moreover, the opportunity for refactoring often arises as part of other maintenance activity and we would thus expect developers to spot opportunities for refactoring as they undertake other work on a system. There is one relatively straightforward explanation for this phenomenon. All of the fifteen refactorings in Table 4 are semantics-preserving and do not explicitly add large numbers of classes, LOC, methods or attributes as part of their mechanics. For example, the ‘Move Field’ and ‘Move Method’ refactorings would have no net effect on the number of fields or methods in a system, on a package basis. Simple renaming refactorings such as ‘Rename Field’ and ‘Rename Method’ do not, per se, add any LOC to the system. Equally, none of the inheritance-related refactorings explicitly add LOC to a system. One further suggestion as to why refactoring occurs at different versions is that after a burst of regular maintenance effort and a new version being released, the decay to the system that those changes have caused may need to be remedied. In other words, after a concerted effort to modify the system through regular maintenance, developers may feel that only then is refactoring necessary.

Figure 5. Refactorings in the nine versions of Velocity

8 / 11 Volume X (2007)

Package Evolvability and Refactoring

This does not explain, however, why for the Velocity system there is significant refactoring effort in version 5 coinciding with a large set of changes in terms of added classes, LOC, methods and attributes? One explanation could be that developers refactor during the course of normal maintenance but without explicitly recognizing it as refactoring. In other words, they may ‘tidy up’ in situ. We could hypothesise that while for Velocity (and the refactorings we have extracted) refactoring effort is not applied consistently, there are two key occasions when, consciously or sub-consciously, it is applied.

4.2 PDFBox and Antlr

The question we could then ask is whether refactoring effort is consistent in terms of the versions where it is undertaken and whether a similar trend in refactoring appears in other systems. Figure 6 shows the versions where refactorings were undertaken for the PDFBox system. Versions 3 and 6 appear to be where the majority of the refactoring effort was invested. Although we do not have the dataset of regular maintenance changes applied to the PDFBox system, it is interesting that a peak and trough effect is clearly visible for this system as well as for Velocity.

Figure 6. Refactorings for PDFBox Figure 7. Refactorings for Antlr

Figure 7 shows the refactoring trends for the Antlr system. Version two appears to be the point when most refactoring effort was invested, reinforcing the view that relatively more refactoring seems to be undertaken at early versions of system’s life (but not at its inception). It is interesting that across all three systems, version one seems to have been the subject of virtually no refactoring effort. One explanation might be that version one is simply too early in the life of a system for refactoring effort to be applied. On the other hand, it appears that version two or three is when the bulk of refactoring occurs. The question that then arises is whether the numbers of each type of refactorings in each of the three systems were similar? Inspection of the raw data reveals a common trend for refactoring 1 (Add Parameter) and refactorings 9, 10, 12 and 13 (Rename Field, Rename Method, Move Field and Move Method). We hypothesize that these types of refactoring have been applied relatively more frequently than any of the other fifteen because they ‘tidy up’ a system with relatively little effort being required. After a significant amount of maintenance effort has been applied to a system, minor modifications are bound to be necessary. This may further explain why there is no coincidence between regular maintenance effort and that of refactoring. In the analysis of

Proc. Software Evolution 2007 9 / 11

ECEASST changes made at the package level, a significant number of methods and attributes were added over the versions studied.

Based on the refactoring evidence, we could claim that the five stated refactorings were a direct response to the problems associated with the addition of so many attributes and methods. For example, the motivation for the ‘Move Field’ refactoring is when ‘a field is, or will be, used by another class more than the class on which it is defined’. In such a case, the field needs to be moved to the place ‘where it is being used most’. Equally, the ‘Move Method’ refactoring is applicable when: ‘A method is, or will be, using or used by more features of another class than the class on which it is defined’. For the Velocity system, the large number of these two refactorings at version three suggests that the correspondingly large number of fields and methods added were the cause of required subsequent refactoring. In other words, simple refactorings may have been undertaken to remedy the problems associated with such an intense set of added fields and methods. We also note that these two refactorings were popular across all three systems studied (and at specific points), which adds weight in support of this argument. The same principle applies to simple renaming of fields and methods. It is perfectly reasonable to suggest that when large numbers of attributes and methods have been added to a system, a certain amount of refactoring may be necessary subsequently to disambiguate and clarify the role and meaning of those fields and methods. Fowler (1999) suggests that the ‘Move Method’ refactoring is the ‘bread and butter of refactoring’. Equally, ‘Move Field’ is the ‘very essence of refactoring’. Similarly, Fowler reveals an interesting point about the ‘Rename Method’ refactoring: ‘Life being what it is, you won’t get your names right the first time’. One explanation for the lack of the more ‘structurally-based’ refactorings (i.e., those that manipulate the inheritance hierarchy) in the systems studied might be that the package access provides the necessary inter-class access that inheritance might otherwise provide. The ‘Extract Subclass’ and ‘Extract Superclass’ refactorings would fall into this category. One final point relates to why versions two and three were the source of the most refactoring effort (as opposed to later versions of the system across all three systems). One explanation is that when a system is at early stages of its lifetime, the design documentation is more likely to be up-to-date. Consequently, the system is relatively easy to modify from a refactoring perspective. As the system ages, increasing amounts of effort and time needs to be devoted to changes as the code ‘decays’.

5. Conclusions The goal of this research was to investigate how a system evolved at the package level and this goal was achieved through the use of a case study. A set of three research questions investigated trends in changes of nine versions of an open-source Java system. A bespoke tool was written to extract data relating to changes across those nine versions. An interesting ‘peak and trough’ effect trend was found to exist in the system studied at specific versions of the system, suggesting that developer activity comprises a set of high and low periods. A contrast was found between those regular changes and those associated with refactoring activity. The results address a hitherto unknown area - that of the relationship between regular changes made to a system as part of maintenance and that of refactoring. While the study describes only a limited sample of systems and evidence of the peak and trough effect is similarly restricted (both threats to study validity), we view the research as a starting point for further

10 / 11 Volume X (2007)

Package Evolvability and Refactoring replicated studies and for an in-depth and generalised analysis of coupling/refactoring, both inter- and intra-package.

Bibliography Advani, D., Hassoun, Y. and Counsell S. (2006) Extracting refactoring trends from open- source software and a possible solution to the related refactoring conundrum. Proceedings of the ACM Symposium on Applied Computing, Dijon, France, April 2006. Arisholm, E. and Briand, L.C., Predicting Fault-prone Components in a Java Legacy System, Proceedings of 2006 ACM/IEEE Intl. Symposium on Empirical Software Engineering. Beck, K., (1999) Extreme Programming Explained: Embrace Change, Addison Wesley. Belady, L., Lehman M., (1976) A model of large program development, IBM Sys. Journal, 15(3), pages 225-252. Bieman, J. M., Straw, G., Wang, H., Munger, P. and Alexander, R. (2003) Design patterns and change proneness: an examination of five evolving systems. In Proc of the Ninth Int Software Metrics Symposium, Sydney, Australia, pp.40-49. Bieman, J. M., Jain, D. and Yang, J. Y. (2001) OO design patterns, design structure, and program changes: an industrial case study. In Proceedings of the In.l Conf. on Software Maintenance, Florida, Italy, pp.580-589. Demeyer, S., Ducasse, S., Nierstrasz, O., (2000) Finding Refactorings via Change Metrics. In OOPSLA ’00: Proc of the 15th ACM SIGPLAN OOPSLA, Minneapolis, Minnesota, United States. pp. 166–177. ACM Press, New York, NY, USA. Ducasse, S., Lanza, M. and Ponisio, L. (2005) Butterflies: a visual approach to characterize packages. In Proceedings of the 11th Intl. Software Metrics Symposium, Como, Italy, pp.7-16. Ducasse, S., Lanza, M. and Ponisio, L. (2004) A top-down program comprehension strategy for packages. Technology Report IAM-04-007, University of Berne, Institute of Applied Mathematics and Computer Sciences. Fowler, M., (1999) Refactoring (Improving the Design of Existing Code). Addison Wesley. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design patterns: elements of reusable object-oriented software. Massachusetts, Addison- Wesley. Mens, T. and van Deursen, A. (2003) Refactoring: Emerging Trends and Open Problems. Proceedings First International Workshop on REFactoring: Achievements, Challenges, Effects (REFACE). University of Waterloo. Mens, T. and Tourwe, T. (2004) A Survey of Software Refactoring, IEEE Transactions on Software Engineering 30(2): 126-139. Opdyke, W. (1992) Refactoring object-oriented frameworks, Ph.D. Thesis, Univ. of Illinois. Tourwe, T. and Mens, T., (2003) Identifying Refactoring Opportunities Using Logic Meta Programming, Proc. 7th European Conf. on Software Maintenance and Re-Engineering, Benevento, Italy, 2003, pages 91-100.

Proc. Software Evolution 2007 11 / 11 ECEASST

Supporting Reengineering Scenarios with FETCH: an Experience Report

Bart Du Bois1 and Bart Van Rompaey1, Karel Meijfroidt2 and Eric Suijs3

1 [email protected], [email protected] Lab On Reengineering, University of Antwerp, Belgium

2 [email protected] Alcatel-Lucent, Antwerp, Belgium

3 [email protected] Philips Medical Systems, Best, The Netherlands

Abstract: The exploration and analysis of large software systems is a labor-intensive activity in need of tool support. In recent years, a number of tools have been developed that provide key functionality for standard reverse engineering scenarios, such as (i) metric analysis; (ii) anti-pattern detection; (iii) dependency analysis; and (iv) visualization. However, either these tools support merely a subset of this list of scenarios, they are not made available to the research community for comparison or extension, or they impose strict restrictions on the source code. Accordingly, we observe a need for an extensible and robust open source alternative, which we present in this paper. Our main contributions are (i) a comparison among existing solutions; (ii) a clariﬁcation of useful reverse engineering scenarios; and (iii) an experience report on four recent cases illustrating the usefulness of tool support for these scenarios in an industrial setting. Keywords: Static Analysis, Quality Assurance, Industrial Experience

1 Introduction

To support maintenance scenarios for large software systems, where manual effort is error prone or does not scale, developers are in need of tools. In the past, several engineering techniques have been examined for their contribution to unraveling the evolution knot. In the identiﬁca- tion of maintenance hot spots, metrics provide quantitative indicators. Visualization serves a key role in understanding the system composition, and to facilitate design/architecture communication. Patterns have been successfully introduced as a means to document both best practices (e.g., recurring programmatic needs [GHJV94]) or worst practices (e.g., anti-patterns documenting historical design decisions evaluated as suboptimal [BMMM98]). In assistance to impact and effort analysis, dependency analysis teaches the developer about component interactions. Together, these techniques form the key means to reverse engineer a given system from source. All of these techniques require, at least implicitly, the presence of a model of the software system. Such a model abstracts from programming language and variant speciﬁc properties,

1 / 14 Volume X (2007) enabling the user to reason in terms of higher-level building blocks. In research on such models and the techniques using them, tools have been implemented. In this work, we combined existing components and best practices of earlier tools into FETCH. Implemented as a chain of tools – following a pipes and filters architecture – we support key reverse engineering scenarios in each of the analysis domains (i) metric calculation; (ii) (anti) pattern detection; (iii) impact analysis; and (iv) design/architecture visualization. FETCH aims to be flexible, lightweight, robust as well as open. Firstly, the pipes and filters architecture eases adaptation towards software systems with other characteristics, such as a new implementation environment, as well as new analysis scenarios, e.g., new visualization techniques. Secondly, light weight tools minimize the mental load imposed by the tool usage and employ heuristics to achieve good performance. Thirdly, the tool chain must also be robust, in order to cope with variations and evolutions in the development tools of the target software system. Finally, due to the careful selection of components, we were able to make FETCH open source, encouraging industrial and academic partners to adopt, extend and integrate with FETCH. To illustrate the need for, and usefulness of, a tool chain satisfying the above properties, we report on the application of FETCH on recent industrial collaborations. This paper is structured as follows. The set of existing (C++) fact extractors is discussed in Section 2. As a recent alternative to these existing solutions, FETCH is presented in Section 3. In Section 4, we report on the application of FETCH in recent industrial collaborations. Finally, in Section 5, we conclude and discuss future work.

2 Related Work

Table 1 compares the usage scenarios provided by related C++ fact extractors. This non-exhaustive list has been composed with the information available to us at the time of writing. As C++ fact extractors, these tools invariably process C++ source code and generate an abstract, query-able representation.

Table 1: Comparison of a non-exhaustive list of C++ fact extractors Fact Extractor MC PD DA V Key strengths Open source? √ √ Open Visualization Toolkit √ √ Aggregation No TkSee/SN √ √ Source navigation Yes iPlasma √ √ √ Quality assurance No CPPDM extractor √ √ √ System decomposition No Rigi √ √ √ √ Aggregation Partially Acacia √ √ √ √ Dependency analysis No SPOOL √ √ √ √ Design pattern recovery No CppX/SWAG Kit Architecture evaluation Yes # 8 4 6 6

We use the following abbreviations: (i) MC for Metric Calculation; (ii) PD for Pattern Detec- tion; (iii) DA for Dependency Analysis; and (iv) V for Visualization. As not all fact extractors were built to support these features, we also indicate other key strengths of the tools listed. Ad- ditionally, we indicate whether the tools are open source – i.e., whether they can be freely used and extended. The latter is relevant for readers wishing to use the extractor for their own projects.

Proc. Software Evolution 2007 2 / 14 ECEASST

Open Visualization Toolkit – uses Source Navigator (SN) in combination with Open Inventor C++ toolkit [TMR02]. The usefulness of the toolkit for reverse architecting large systems has been demonstrated on several software systems from Nokia. A key contribution of this toolkit is the ability to aggregate lower level facts on a higher hierarchical level. TkSee/SN – uses SN to generate a GXL representation of the Dagstuhl Middle Model (DMM). This tool mostly supports navigation and querying. While TkSee/SN is indicated in [SHE02] to be open source, we were unable to ﬁnd any reference to the source code nor any binary release. iPlasma – The Integrated Platform for Software Modelling and Analysis particularly targets quality analysis [MMM+05]. Instances of iPlasma’s meta-model (Memoria [Rat04]) can be queried using the Static Analysis Interrogative Language (SAIL) [MMG05]. CPPDM extractor –[MW03] discusses a C++ fact extractor combining Source Navigator1 (SN) with Rigi [MK88]. The output model conforms to a C/C++ domain model (CPPDM), and is presented in Rigi Standard Format (RSF). Since the authors do not provide a name for their tool, we abbreviate it as CPPDM extractor. Rigi – presents a scriptable environment for visualizing the structure of large software systems. Parsers are provided for multiple languages (C, C++ and COBOL) [MK88]. The Rigi C++ parser is based on IBM VisualAge for C++ [Mar99]. Acacia – C++ Information Abstraction System developed by AT&T [CNR90]. A tool named Ccia transforms C++ source code to a relational database, queried using Ciao [CFKW95]. SPOOL – The SPOOL environment transforms source code into the Datrix/TA-XML intermediate format using the Datrix C++ parser [SKL+02]. This XML format is then traversed using an XML parser. SPOOL was set out to support pattern-based reverse engineering for program comprehension, and was applied on industrial C++ systems. CPPX/SWAG Kit – transforms the internal graph structure of gcc to a GXL (Graph eXchange Language) representation of Datrix [DMH01]. The dependency on (an out-dated) gcc (v3.0) en- forces stringent requirements on the source code, which may not be easily satisﬁed in industrial research projects. CPPX is part of the SWAG Kit that furthermore entails the Grok [HWW02] fact manipulation engine as well as a graph visualization environment.

In [SHE02], a C++ fact extractor benchmark (CppETS) is presented. Four extractors (CCia, CppX, Rigi C++ parser and TkSee/SN) were evaluated using so called test buckets, present challenging C++ fragments. This evaluation addressed the accuracy and robustness of the extractors. In contrast, we are speciﬁcally looking for high-level services provided on top of the raw fact extraction. The resulting comparison2 is presented in Table 1.

3 Tool Chain

The C++ fact extractors discussed in the previous section successfully supported reverse engineering activities, as demonstrated by the experience reports and case studies in their respective publications. However, researchers and practitioners wishing to reuse these extractors on their

1 http://sourcenav.sourceforge.net 2 Disclaimer: whether or not an extractor supports a scenario is extracted from publications/documentation.

3 / 14 Volume X (2007) projects typically face at least two problems. First, the these extractors most often support merely a subset of the features mentioned Table 1. Second, these extractors are more than often unavailable: we were only able to ﬁnd the source code for CppX/SWAG Kit and Rigi. The latter is a problem in case one wishes to apply the extractors, as we do. To overcome these problems, we propose FETCH3, a 100% open-source tool chain. FETCH bundles and uniﬁes a set of open source tools supporting key issues in reverse engineering. Figure 1 illustrates how FETCH4 combines these tools to statically analyze source code. Indeed, FETCH currently does not provide a solution for dynamic analysis.

Red Hat GDF Guess Source CDIF Navigator to RSF Crocopat RSF namespace script Snav TXT R conditional to CDIF compilation famix source code script MOOSE CCCC

Figure 1: The chain of tools comprising FETCH

Source Navigator (SN) – A source code analysis tool initiated by Red Hat. [TD01] provides a nice overview of the supported functionality. SN has been used previously to develop metric tools [SE01,SKN05] and even some of the C++ fact extractors presented earlier. One of the main beneﬁts of SN is that it parses the source code for structural programming constructs through robust, lexical analysis, making it tolerant towards variants of C and C++. The results of a parse are stored in database tables together with location and scoping information. Subsequently, relations between such structural constructs such as method invocations and attribute accesses are obtained via a cross-referencing step. CCCC – A metrics tool developed by Littlefair [Lit01]. These metrics concern characteristics not deducible from the structure of the source code, as derived by SN, such as Lines of Code, Cyclomatic Complexity and Comment Lines. Crocopat – A graph query engine written by Beyer and Noack. Crocopat supports the querying of large software models in RSF using Prolog-alike Relation Manipulation Language (RML) scripts. In contrast to typical binary relation query languages as Grok, Crocopat’s support for n-ary relations is particularly expressive for software patterns. Moreover, the highly efﬁcient internal data structure enables superior performance to Prolog for calculating closures (e.g., a call-graph) and patterns with multiple roles (e.g., design patterns) [BNL05]. Guess – A graph exploration system developed by Adar [Ada06]. The input graphs described in ASCII format (GDF) can specify various properties of nodes and edges as required for polymetric views [LD03]. Various layout algorithms are provided. A tree hierarchy is missing, yet can be contributed.

3 We emphasize the names of home-made tools in a different STYLE to distinguish them from existing ones. 4 http://www.lore.ua.ac.be/Research/Artefacts/fetch

Proc. Software Evolution 2007 4 / 14 ECEASST

R – The R project for statistical computing5 initiated by Bell Laboratories. Typical static analyses such as calculating spread, identifying outliers, comparing data sets and evaluating predictive models are supported through the vast library.

The first phase of any usage scenario consists of generating an abstract model Table 2: Abstract model content. corresponding to the Famix (FAMOOS6 Entity Origin Information Exchange Model) specifi- File, Include Source Navigator cation. The contents of this model ConditionalCompilation SCRIPT1 (see Table 2) requires input from (i) Package SCRIPT2 Source Navigator; (ii) CCCC; and (iii) Class, Inheritance, Typedef Source Navigator home-made script to extract namespace Method, Function Source Navigator Attribute, Global Variable Source Navigator scopes and conditional compilation direc- Invocation,Access Source Navigator tives. The facts provided by these three + SNAVTOFAMIX tools are combined and interconnected by Measurement CCCC + Source Navigator SNAVTOFAMIX7, resulting in the generation of a CDIF (Case Data Interchange Format [Che03]) representation of the Famix model. Each of FETCH’s usage scenarios requires to query the abstract model. To facilitate querying, the abstract model is translated to a graph format (RSF, the Rigi Standard Format). Crocopat internalizes this RSF model in an efficient in-memory data structure, and executes given RML scripts (Relation Manipulation Language) as queries. These queries result in ASCII output, which we use to generate either (i) reports; (ii) a filtered/extended/altered RSF model; (iii) a visualization in GDF format (Guess Data Format); or (iii) tab-separated data listings. For visualizations, such as polymetric views [LD03], we employ Guess. Guess provides a flexible means to explore visualizations by zooming and navigating, various layout algorithms, and a query/manipulation mechanism for properties of the visualized information. In case more advanced statistical analysis is required, tab-separated data listings are processed using R scripts.

4 Experience Report

In this section, we present an experience report. This work is carried out in collaboration with two industrial partners in the ITEA SERIOUS8 project. As of March 2007, we used FETCH to support several reengineering projects in multi-million line software systems. These reports present applications of the four usage scenarios presented in Table 1, and indicate the relevance of FETCH in industrial projects in which reverse engineering was called for.

5 http://www.r-project.org 6 http://www.iam.unibe.ch/∼famoos 7 http://sourceforge.net/projects/snavtofamix 8 https://lore.cmi.ua.ac.be/serious

5 / 14 Volume X (2007) 4.1 Case 1: Internal Quality Monitoring

To describe the use case at the heart of this usage of FETCH, we reuse a template provided by [Coc95]. Table 3 presents a characteristic description, and enlists the main success scenario.

Table 3: Basic Use Case Template for Internal Quality Monitoring Item Value Goal in Context User requests comparison of two versions of the same software system with regard to metrics of choice. Preconditions A model (abstract representation) of the software system is available. Success End Condition User receives ﬁle comparing metrics between the two versions. Failed End Condition User receives message explaining failed attempts. Primary Actor Quality Assurance Trigger User launches comparison script Main success scenario 0. User identiﬁes metrics to be used for the comparison and selects associated script to compare metrics 1. User launches comparison script. 2. Comparison script generates plots and report comparing metric values between the two versions.

To support management in monitoring the improvement of quality characteristics during currently running refactoring efforts, the authors were asked to provide objective data. At large, the refactoring scenario can be summarized as a partial transition from an overly complex implementation in C to a more well-balanced design in C++, serving to (i) introduce abstraction; and improve (ii) understandability; and (iii) testability. The module in question concerned a protocol implementation at the data link layer, comprising 8.6 kSLOC Table 4: Structural comparison. of C code, of which the lion’s share (6.9 kSLOC) was contained in a single source file. Key characteristics Entity # before # after ∆ File 9 38 +29 of the structural decomposition before and after refac- Class 24 46 +22 toring are enlisted in Table 4. After refactoring, the Method 0 270 +270 largest implementation file was reduced with 40.1% to Function 255 214 -41 4.1 kSLOC by encapsulating functionality in newly in- Attribute 191 282 +91 Global Variable 66 60 -6 troduced abstractions. This encapsulation is clearly noticeable in Table 4. What is not deducible from Table 4 is the extent to which this encapsulation represents a redistribution of functionality. Accord- ingly, Figure 2 compares the distribution of methods and functions across files before and after refactoring. The before image on the left indicates that all methods and functions were contained in merely two files (a highly centralized implementation). After refactoring, the functionality is decentralized through a distribution across multiple files, each containing less methods and functions. Table 4 indicates that as much as 270 methods were introduced, increasing the total number of invokable entities (methods + functions) from 255 before refactoring, to 484 after refactoring. Accordingly, we ask ourselves whether this refinement improved readability and testability. The average size and complexity of methods and functions was considerably reduced, as can be seen from Figure 3. Size was shortened from an average of 27 LOC (median=17) to 14 LOC

Proc. Software Evolution 2007 6 / 14 ECEASST

Before After 1.0 3.0 2.5 0.8 2.0 0.6 1.5 0.4 Frequency Frequency 1.0 0.2 0.5 0.0 0.0

0 50 100 150 0 50 100 150

Number of methods and functions per file Number of methods and functions per file

Figure 2: Distribution of methods and functions before/after refactoring

(median=8). Complexity (measured using an approximation of McCabe’s cyclomatic complexity) was reduced from an average of 6.3 (median=1) to 3.3 (median=4). Cyclomatic complexity calculates the number of independent paths through a method or function, and is thus directly related to testing effort, since each independent path will need to be covered by a test case to ensure adequate coverage. In the reduction of the spread, we observe that the variation in size and complexity is harmonized as well. before before after after

0 50 100 150 200 250 0 10 20 30 40 50 60 70

LOC MVG (a) Size (b) Complexity Figure 3: Variation of method/function size/complexity before and after refactoring

Summarizing, our observations reveal that the refactoring efforts led to a redistribution of functionality. This distribution was accompanied with a reduction of the size and complexity of methods and functions, resulting in an implementation that is both easier to understand and test. The tools within FETCH providing the required facts for this scenario are Source Navigator (providing information on the structural composition) and CCCC (providing size and complexity measurements). The integration of these two data sources is implemented in SNAVTOFAMIX. This scenario also demonstrates that relatively primitive information can sufﬁce to verify the achievement of quality improvements during software evolution.

7 / 14 Volume X (2007) 4.2 Case 2: Estimating Refactoring and Test Effort

In a second case FETCH was used to estimate the effort involved in a refactoring task inside a 67 kSLOC subsystem, implementing a protocol at the network layer. The associated use case is characterized in Table 5.

Table 5: Basic Use Case Template for Estimating Refactoring and Test Effort Item Value Goal in Context User requests report about impact and effort of a refactoring task, testing inclusive. Preconditions A model (abstract representation) of the software system is available. Success End Condition User receives a report with impacted locations and the corresponding effort in lines of code. Failed End Condition User receives message explaining failed attempts (e.g. a faulty description of the modification, or a refactoring of non-existant entities). Primary Actor Developer Trigger User launches estimation script with a description of the modifications in terms of model entities. Main success scenario 1. User identifies script to perform impact and effort analysis. 2. User translates refactoring task in terms of operations on model entities. 3. User launches script.

Developers noted that the data members of a particular C struct, called T Reference, were directly passed on, accessed and modified throughout the subsystem. One of the features for the next release was translated, at code level, in the introduction of additional data members requiring to change along with the existing members. Developers proposed a proper interface to avoid change ripples in expected future. In a first step, we determined the change impact of the refactoring. Typically, developers used text search tools to obtain an overview of the usage of such a struct via locations where the type is declared (as formal parameter, local variable, etc.), e.g., grep [LH02]. We used FETCH on a model of this subsystem to obtain a list of functions that access data members of T Reference instances. A traditional search does not suffice to identifying these accesses as cross-references between instances of structural entities are required. Part of the (disguised) report is represented in Listing 1. The observation that three of the data members are accessed together in most of the functions confirms the refactoring need. Replacing these direct accesses with an interface invocation is a one line modification. Therefore, we estimated 55 (the number of accesses detected in this case) SLOC of effort.

Listing 1: Change Impact Report for T Reference generated by FETCH Looking up use of T R e f e r e n c e For T Reference in file types i f c . hh Function to data access: stack .c:frameRecv(buffer ∗ , u i n t 3 2 ∗) −> T Reference. line stack .c:frameRecv(buffer ∗ , u i n t 3 2 ∗) −> T Reference. vci stack .c:frameRecv(buffer ∗ , u i n t 3 2 ∗) −> T Reference.vpi ...

Method to data access: configControl .hpp:ConfigControl.changeOperate(T Bool ) −> T Reference. line

Proc. Software Evolution 2007 8 / 14 ECEASST

configControl .hpp:ConfigControl.changeOperate(T Bool ) −> T Reference. vci configControl .hpp:ConfigControl.changeOperate(T Bool ) −> T Reference.vpi ...

Secondly, we used this report to estimate testing effort that had to be started from scratch. The testing approach corresponding to this refactoring task was chosen to be on a per function basis. Within testing, we dinstinguish the efforts of (i) stubbing external subsystems; (ii) setup operations to bring the unit under test in the desired state; and (iii) the actual test code. To estimate the number of lines of test code, we incorporate, per function, the number of input parameters (NOP), McCabe’s cyclomatic complexity (MVG) [McC76] as well as FanOut [CK91]. Table 6 shows the effort estimation for the test code based upon the incorporated metrics. We Table 6: Test Effort Estimation Scheme reason that testing one path through a function Task NOP MVG FanOut requires about 15 SLOC, but as we only want to Stubbing - - 10 test paths (also see [WM96] on testing using cy- Setup 2 - 1 clomatic complexity) affected by the refactoring Testing - 0.5*15 - we roughly estimate that half of the paths require testing, resulting in the 0.5 ∗ 15 ∗ MVG formula for the actual test code. Summed up, our test estimation sums up to 1730 kSLOC of stubbing, 257 kSLOC of setup and 1582.5 kSLOC of testing effort. Using FETCH in an effort estimation context enabled to calculate the expected change impact objectively, in contrast with the typical combination of gut feeling and search tools. The availability of a software model (provided by Source Navigator), enriched with complexity and coupling metrics (provided by CCCC), and a powerful query mechanism (Crocopat) were essential to support this scenario.

4.3 Case 3: Detecting anti-patterns: Dead code A use case description for this case is presented in Table 7.

Table 7: Basic Use Case Template for Detecting Dead Code Item Value Goal in Context User requests a list of design or architecture elements involved in a given (anti-)pattern. Preconditions model (abstract representation) of the software system is available. Success End Condition User receives file listing occurrences for a given (anti-)pattern. Failed End Condition User receives message explaining failed attempts. Primary Actor Q&A Trigger Q&A engineer (or an automated process) launches a set of detection scripts for given (anti-)patterns. Main success scenario 1 User identifies (anti-)pattern to be calculated. 2. User identifies associated script to calculate metrics. 3. User launches detection script. 4. Calculation script generates file reporting on (anti-)pattern occurrences

Dead code has many faces. One may ﬁnd (i) blocks of code that are commented; (ii) functions not called anymore; and thirdly (iii) code that is not compiled due to compiler directives. A particular instance of the latter category uses the #if 0 directive, a condition that never results

9 / 14 Volume X (2007) in an inclusion of the nested code after preprocessing. As one of the developers noted that the latter approach is common behaviour in a 110 kSLOC subsystem (implementing a network protocol) under study, we introduced the concept of a conditional compilation directive to the FAMIX meta-model [RVW07], in order to reason about conditional compilation and to remove dead code by compilation directive in particular. We queried the model for all block conditions that contain condition ”0” at least as subcondi- tion, thereby identifying 911 SLOC out of the total 110 kSLOC that should be removed according to developer’s opinion that such a construct should not be used. Rather, the versioning system should be used to store code that becomes dead or redundant at a certain time. FETCH helped to efﬁciently identify such locations, in what would otherwise have been a cumbersome task of manually identifying blocks that hold this compilation condition. Especially when such blocks are nested, determining the scope of these blocks becomes hard. Note that information on conditional compilations is not provided by Source Navigator (see Table 2).

4.4 Case 4: Detecting key domain abstractions using visualization

Table 8 characterizes the FETCH use case for detecting key domain abstractions. As part of our First Contact to a large C++ software system (a medical image application of around 400 kSLOC), we applied a heuristic for detecting key domain abstractions. This heuristic consists of ﬁnding concepts existing in many variations. Typically, sub-variations of a concept are modeled through inheritance, enabling white-box reuse. Templates, however, enable black-box reuse, thereby introducing another way of modeling conceptual variations. In this particular software system, template instantiations were made explicit using typedef declarations. Accordingly, we proposed to decorate the inheritance hierarchy with typedef relations to represent both types of variation relations.

Table 8: Basic Use Case Template for Detecting key domain abstractions Item Value Goal in Context User requests overview of the genericity of classes in variation graph Preconditions A model (abstract representation) of the software system is available Success End Condition User receives visualization of variation graph. Failed End Condition User receives message explaining failed attempts. Primary Actor (Newly introduced) maintainer or developer Trigger User launches visualization script. Main success scenario 1. User launches visualization script. 2. Visualization script generates GDF ﬁle representing variation graph. 3. User loads GDF ﬁle into Guess.

The resulting variation graph, part of which is represented in Figure 4, contains black circles and edges to represent classes and the inheritance relations between them, and yellow rectangles and edges to represent typedefs and the relation to the base types for which the typedef introduces an alias. Superclasses in the inheritance hierarchy on the left were conﬁrmed by the maintainers to represent high level concepts that encapsulated generic functionality. The two classes in the hierarchy on the right were conﬁrmed as representations of elements in a data model. Both sets of classes thus indeed represent key domain abstractions, and the latter indicated concepts with

Proc. Software Evolution 2007 10 / 14 ECEASST many variations not previously observed in the inheritance hierarchy.

Figure 4: Variation graph decorating a traditional inheritance hierarchy with typedefs

The input required to compose this visualization is fully provided by Source Navigator. The visual recognition of relevant classes is facilitated through Guess’s layout algorithms. For this scenario, FETCH’s contribution lies in the integration of these two tools.

5 Conclusion and Future Work

In this work we present the following contributions. First, we enlist four features highly relevant for reverse engineering tools, namely (i) metric calculation; (ii) (anti-)pattern detection; (iii) impact analysis; and (iv) visualization. Second, we compare current C++ fact extractors with regard to these features, indicating the need for a freely available integrated solution. Thirdly, we introduce FETCH, a tool chain integrating existing open source tools supporting the above listed features. Finally, we report on four cases in which FETCH supported industrial reengineering projects. Since no quantitative data was available to serve as an evaluation, this paper merely suggests the industrial usefulness of an integrated tool chain as FETCH, and by no means attempts to validate its efﬁcacy. The validation of FETCH’s contribution in each of the reverse engineering scenarios mentioned in this paper will be addressed in the next research steps.

Acknowledgements: This work has been sponsored by the Flemish Instituut voor Innovatie door Wetenschap en Technologie under grants of the ITEA project if04032 entitled Software Evolution, Refactoring, Improvement of Operational & usable Systems (SERIOUS) of the Eureka Σ 2023 Programme.

Bibliography

[Ada06] E. Adar. GUESS: a language and interface for graph exploration. In CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems. Pp. 791–800. ACM Press, New York, NY, USA, 2006. [BMMM98] W. Brown, R. Malveau, H. McCormick, T. Mowbray. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998. [BNL05] D. Beyer, A. Noack, C. Lewerentz. Efﬁcient Relational Calculation for Software Analysis. IEEE Trans. Softw. Eng. 31(2):137–149, 2005.

11 / 14 Volume X (2007) [CFKW95] Y.-F. R. Chen, G. S. Fowler, E. Koutsoﬁos, R. S. Wallach. Ciao: a graphical navigator for software and document repositories. In ICSM ’95: Proceedings of the In- ternational Conference on Software Maintenance. P. 66. IEEE Computer Society, Washington, DC, USA, 1995. [CGK98] Y.-F. Chen, E. R. Gansner, E. Koutsoﬁos. A C++ Data Model Supporting Reacha- bility Analysis and Dead Code Detection. IEEE Trans. Softw. Eng. 24(9):682–694, 1998. [Che03] M. Chen. CASE data interchange format (CDIF standards: introduction and evaluation. In HICS’03: Proceedings of the 26th Hawaii International Conference on System Sciences. Pp. 31–40. IEEE Computer Society, Washington, DC, USA, 2003. [CK91] S. R. Chidamber, C. F. Kemerer. Towards a metrics suite for object oriented design. In OOPSLA ’91: Conference proceedings on Object-oriented programming systems, languages, and applications. Pp. 197–211. 1991. [CNR90] Y.-F. Chen, M. Y. Nishimoto, C. V. Ramamoorthy. The C Information Abstraction System. IEEE Trans. Softw. Eng. 16(3):325–334, 1990. [Coc95] A. Cockburn. Basic use case template. Technical report HaT.TR.95.1, Humans and Technology, 84121, Salt Lake City, Utah, 1995. [DDN02] S. Demeyer, S. Ducasse, O. Nierstrasz. Object-Oriented Reengineering Patterns. Morgan Kaufmann, 2002. [DMH01] T. R. Dean, A. J. Malton, R. Holt. Union Schemas as a Basis for a C++ Extractor. In WCRE ’01: Proceedings of the Eighth Working Conference on Reverse Engineering (WCRE’01). P. 59. IEEE Computer Society, Washington, DC, USA, 2001. [GHJV94] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Languages and Systems. Addisson-Wesley, 1994. [HWW02] R. C. Holt, A. Winter, J. Wu. Towards a Common Query Language for Reverse En- gineering. Technical report –, Institute for Computer Science, Universitat¨ Koblenz- Landau, Koblenz, Germany, 2002. [KSRP99] R. K. Keller, R. Schauer, S. Robitaille, P. Page.´ Pattern-based reverse-engineering of design components. In ICSE ’99: Proceedings of the 21st international conference on Software engineering. Pp. 226–235. IEEE Computer Society Press, Los Alamitos, CA, USA, 1999. [LD03] M. Lanza, S. Ducasse. Polymetric Views – A Lightweight Visual Approach to Reverse Engineering. IEEE Transactions on Software Engineering 29(9):782–795, 2003. [LH02] T. T. Lethbridge, F. Herrera. Advances in software engineering: comprehension, evaluation and evolution. Chapter Assessing the usefulness of the TKSee software exploration tool, pp. 73–93. Springer-Verlag New York, Inc., 2002.

Proc. Software Evolution 2007 12 / 14 ECEASST

[Lit01] T. Littlefair. An Investigation into the Use of Software Code Metrics in the Industrial Software Development Environment. PhD thesis, Faculty of communications, Health and Science, Edith Cowan University, June 2001.

[Mar99] J. Martin. Leveraging IBM visual age for C++ for reverse engineering tasks. In CAS- CON ’99: Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research. P. 6. IBM Press, 1999.

[MB89] T. J. McCabe, C. W. Butler. Design complexity measurement and testing. Commun. ACM 32(12):1415–1425, 1989.

[McC76] T. McCabe. A Complexity Measure. IEEE Transactions on Software Engineering 2(4):308–320, December 1976.

[MK88] H. A. Muller,¨ K. Klashinsky. Rigi-A system for programming-in-the-large. In ICSE ’88: Proceedings of the 10th international conference on Software engineering. Pp. 80–86. IEEE Computer Society Press, Los Alamitos, CA, USA, 1988.

[MMG05] C. Marinescu, R. Marinescu, T. Girba. Towards a Simpliﬁed Implementation of Object-Oriented Design Metrics. In METRICS ’05: Proceedings of the 11th IEEE International Software Metrics Symposium (METRICS’05). P. 11. IEEE Computer Society, Washington, DC, USA, 2005.

[MMM+05] C. Marinescu, R. Marinescu, P. F. Mihancea, D. Ratiu, R. Wettel. iPlasma: An In- tegrated Platform for Quality Assessment of Object-Oriented Design. In Proceedings of the 21st International Conference on Software Maintenance (ICSM’05). Pp. 77– 80. IEEE Computer Society, Washington, DC, USA, 2005.

[MW03] D. L. Moise, K. Wong. An Industrial Experience in Reverse Engineering. In WCRE ’03: Proceedings of the 10th Working Conference on Reverse Engineering. P. 275. IEEE Computer Society, Washington, DC, USA, 2003.

[NDG05] O. Nierstrasz, S. Ducasse, T. Gˆırba. The story of moose: an agile reengineering environment. In ESEC/FSE-13: Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foun- dations of software engineering. Pp. 1–10. ACM Press, New York, NY, USA, 2005.

[Rat04] D. Ratiu. Memoria: A Uniﬁed Meta-Model for Java and C++. Master’s thesis, Po- litehnica University of Timisoara, Romenia, 2004.

[Riv02] C. Riva. Architecture Reconstruction in Practice. In WICSA 3: Proceedings of the IFIP 17th World Computer Congress - TC2 Stream / 3rd IEEE/IFIP Conference on Software Architecture. Pp. 159–173. Kluwer, B.V., Deventer, The Netherlands, The Netherlands, 2002.

[RVW07] M. Rieger, B. Van Rompaey, R. Wuyts. Teaching FAMIX about the Preprocessor. In 1st Workshop on FAMIX and Moose in Reengineering (FAMOOSr’07). Pp. 13–16. 2007.

13 / 14 Volume X (2007) [SE01] M. Stojanovic, K. E. Emam. ES2: A Tool for Collecting Object-oriented Design Met- rics for the C++ and Java Source Code NRC/ERB-1088. Technical report, National Research Council Canada, 2001.

[SHE02] S. E. Sim, R. C. Holt, S. Easterbrook. On Using a Benchmark to Evaluate C++ Ex- tractors. In IWPC ’02: Proceedings of the 10th International Workshop on Program Comprehension. P. 114. IEEE Computer Society, Washington, DC, USA, 2002.

[SKL+02] R. Schauer, R. K. Keller, B. Lague,´ G. Robitaille, S. Robitaille, G. Saing-Denis. Advances in software engineering: comprehension, evaluation and evolution. Chap- ter The SPOOL design repository: architecture, schema, and mechanisms, pp. 269– 294. Springer-Verlag New York, Inc., New York, NY, USA, 2002.

[SKN05] S. Sarkar, A. C. Kak, N. S. Nagaraja. Metrics for Analyzing Module Interactions in Large Software Systems. In APSEC ’05: Proceedings of the 12th Asia-Paciﬁc Soft- ware Engineering Conference (APSEC’05). Pp. 264–271. IEEE Computer Society, Washington, DC, USA, 2005.

[TD01] S. Tilley, M. DeSouza. Spreading Knowledge about Gnutella: A Case Study in Un- derstanding Net-Centric Applications. In IWPC ’01: Proceedings of the 9th Interna- tional Workshop on Program Comprehension. Pp. 189–198. IEEE Computer Society, Los Alamitos, CA, USA, 2001.

[TMR02] A. Telea, A. Maccari, C. Riva. An Open Visualization Toolkit for Reverse Archi- tecting. In IWPC ’02: Proceedings of the 10th International Workshop on Program Comprehension. P. 3. IEEE Computer Society, Washington, DC, USA, 2002.

[TTDS07] P. Tonella, M. Torchiano, B. Du Bois, T. Systa.¨ Empirical studies in reverse engineering: state of the art and future trends. To appear in Journal on Empirical Software Engineering, 2007.

[WM96] A. Watson, T. McCabe. Structured Testing: A Testing Methodology Using the Cy- clomatic Complexity Metric. Technical report, National Institute of Standards and Technology, USA, 1996.

Proc. Software Evolution 2007 14 / 14 ECEASST

The Use of Executable FIT Tables to support Maintenance and Evolution Tasks

Filippo Ricca1, Marco Torchiano2, Massimiliano Di Penta3, Mariano Ceccato4 and Paolo Tonella5

1 ﬁ[email protected] Unit CINI at DISI, Genova, Italy

2 [email protected] Politecnico di Torino, Italy

3 [email protected] University of Sannio, Benevento, Italy

4 [email protected] 5 [email protected] Fondazione Bruno Kessler—IRST, Trento, Italy

Abstract: Acceptance testing is a kind of testing performed prior to software delivery. In the agile approach, acceptance test cases can be speciﬁed by analysts and customers during the requirement elicitation phase and used to support the development/maintenance activities. This paper reports a pilot experiment that investigates on the usefulness of executable acceptance test cases, developed by using FIT (Framework for Integrated Test), during software maintenance and evolution activities. The preliminary results indicates that FIT tables help developers to correctly perform the maintenance/evolution tasks without affecting the productivity. Keywords: Empirical studies, acceptance testing, FIT tables.

1 Introduction

FIT (Framework for Integrated Test) is an open source framework used to express executable acceptance test cases in a simple way. FIT lets analysts write acceptance tests (FIT tables) using simple HTML tables. Programmers write code (Fixtures) to link the test cases with the System to verify. Then, in a test-driven development scenario, they perform their development or maintenance task being supported by the execution of these test cases. In this paper we describe a controlled experiment aimed at assessing whether FIT tables are helpful in maintenance tasks. We asked some master students to execute some corrective maintenance and evolution interventions, providing them the Systems to be maintained with and without the FIT Tables. The research questions that we are interested in answering are:

RQ1: Does the presence of FIT tables help programmers to execute maintenance tasks?

1/10 Volume X (2007) The Use of Executable FIT Tables to support Maintenance and Evolution Tasks

RQ2: Does the presence of FIT tables improve the productivity in the execution of maintenance interventions?

The dependent variable “correctness” was measured by exercising an alternative JUnit1 acceptance test suite, the variable “productivity” using time sheets where students annotated start and stop time expressed in minutes. Preliminary results of our experiment shows that FIT tables help developers to correctly perform the four maintenance/evolution tasks given without affecting the productivity (the difference between the two groups considering the time to complete the tasks was not significant). Although there are several papers [Aar06, RMM05] and books [MC05] describing acceptance testing with FIT tables, only a few works report empirical studies about FIT. The most related work is the paper by Melnik et al. [MRM04]. It is a study focused on the use of FIT user acceptance tests for specifying functional requirements. It has been conducted at the University of Calgary and at the Southern Alberta Institute of Technology. In this experiment, the authors showed that the use of FIT tables and the possibility to execute them improve the comprehension of requirements. In another preliminary study [TRP07] some of the authors of the present paper found a statistically significant evidence that the availability of FIT tables allows the programmers to complete more maintenance tasks. However, they did not measure, as we did in the present study, whether completed maintenance tasks were correct. The paper is organized as follows: section 2 briefly presents the Framework for Integrated Test (FIT). Section 3 describes the design of the empirical study that we conducted. Results are presented in Section 4 while conclusions and future works are given in Section 5.

2 FIT tables, Fixtures and Test Runner

The FIT tables serve as the input and expected output for the tests. Figure 1 shows an example of Column FIT tables, a particular kind of table (see [MC05] for the other types such as action, row, etc.) where each row represents a test case. The ﬁrst ﬁve columns are input values (Name, Sur- name, Address, Date of birth and Credit/Debit) and the last column represents the corresponding expected output value (Member number()). Developers write the Fixtures to link the test cases with the System to verify. A component in the framework, the Test Runner, compares FIT table data with actual values obtained from the System. The Test Runner highlights the results with colors (green = correct, red = wrong). See the relationships among FIT tables, Fixtures, Test Runner and System under test in Figure 2.

3 Experiment deﬁnition, design and settings

We conceived and designed the experiment following the guidelines by Wohlin et al. [WRH+00]. The goal of the study is twofold: to analyze the use of FIT tables with the purpose of evaluating their usefulness during maintenance tasks and to measure the effort (if any). The perspective is both of Researchers, evaluating how effective are the FIT tables during the maintenance activities, and of Project managers, evaluating the possibility of adopting the FIT tables in her/his

1 http://www.junit.org/

Proc. Software Evolution 2007 2/10 ECEASST

Figure 1: Example of Column FIT table. FIT table column’s names without parenthesis represent input; parenthesis indicate output. organization. The context of the experiment consists of two objects – two Java systems – and of subjects, 13 students from a master course. All the material of the experiment (sources, documents, questionnaire, etc. ) will be available for replications on a Website soon.

3.1 Hypotheses The null hypotheses for the study are the following:

• H0a The availability of FIT test cases does not signiﬁcantly improve the correctness of the maintained source code.

• H0b The availability of FIT test cases does not signiﬁcantly affect the effort in the maintenance task.

The context in which we investigate the above question has the following characteristics: (1) system requirements have been written in detail, (2) automated acceptance tests have been produced in the form of FIT Tables and (3) some change requirements are expressed only in textual form while other include also an automated FIT test case.

3.2 Treatments The treatments for the main factor (availability of test cases) are: • (+) textual change requirements enhanced with FIT tables and ﬁxtures, thus enabling test case execution;

• (-) only textual change requirements.

3/10 Volume X (2007) The Use of Executable FIT Tables to support Maintenance and Evolution Tasks

Figure 2: The complete picture

Other independent variables (not accounted in this paper) to be considered could be: the objects, the labs and the subjects’ ability, if available.

3.3 Objects

The objects of the study are two simple Java programs realized by students: LaTazza and Ave- Calc. LaTazza is a coffee maker management support application. LaTazza helps a secretary to manage the sale and the supply of small-bags of beverages (Coffee, Tea, Lemon-tea, etc.) for the Coffee-maker. The application supports two kinds of clients: visitors or employees (university employees and professors). Employees can purchase beverage cash or on credit, visitors only cash. The secretary can: sell small-bags to clients, buy boxes of beverages (a box contains 50 beverage of the same kind), manage credit and debt of the employees, check the inventory and check the cash account. The system consists of 18 Java classes for a total of 1121 LOCs. Its requirement document comprises 9 requirements (see table 1 for the ﬁrst four requirements) complemented with a total of 16 FIT tables. AveCalc is a simple “desktop application” that manages an electronic register (record book) for master students. A student can add a new exam to the register, remove an existing exam and remove all exams. An exam has a name, a CFU (a positive number that represent the university credits) and a (optional) vote. An exam without vote is an exam not taken. The vote must be included between 0 and 30 (or equal). If the vote is >= 18 then the vote is positive, otherwise it is negative. It is possible to save the register and to load it (all data or only positive exams). AveCalc computes some statistics: average of the exams passed, total number of CFU, number of exams passed, (hypothetical) degree vote and whether the student has passed a number of exams sufﬁcient to defend his/her thesis. The system consists of 8 Java classes for a total of

Proc. Software Evolution 2007 4/10 ECEASST

Table 1: Some Requirements for LaTazza. R1 The secretary can sell small-bags of Coffee, Arabic Coffee, Tea, Lemon-tea and Camomile-tea. The cost of each small-bag is 0.62 euro. The secretary can select the kind of beverage and the number of small-bags and select the button Sell. If there are enough small-bags then the sale is done, otherwise the sale can not be done. R2 The secretary can register a payment. She/He has to select the employee that perform the payment. This payment can extinguish a debt of the employee or it can used in future as advance fee. The payment must be > 0. R3 The secretary can buy boxes of beverages. A box contain 50 small-bags of beverages all of the same kind (i.e, 50 coffee or 50 Arabic coffee, etc.). Each box cost 31 euro. R4 The secretary can request the list of debtors with their debts.

1827 LOCs. Its requirement document comprises 10 requirements complemented with a total of 19 FIT tables.

3.4 Population The subjects were 13 students from the course of Laboratory of Software Analysis, in their last year of the master degree in computer science at the University of Trento. The students had a good knowledge about programming, in particular Java, and an average knowledge about software engineering topics (e.g. design, testing, software evolution). Subjects have been trained in meaning and usage of FIT tables and Fitnesse2, i.e., the tool that implement the FIT table approach used in the experiment.

3.5 Variables and experiment design The dependent variables to be measured in the experiment are the code correctness and the effort required to perform the maintenance task. The code correctness is assessed by executing a JUnit acceptance test suite — developed by someone different from who developed the FIT tables — and measuring the percentage of test cases passed and failed. The effort was measured by means of time sheets (students marked start and stop time for each change requirements implemented). Time is expressed in minutes. We adopt a balanced experiment design (see [WRH+00]) intended to ﬁt two lab session (2- hours each). Subjects were split into four groups, each one working in Lab 1 on all task of a system with a treatment and working on Lab 2 on the other system with a different treatment (see Table 2).

3.6 Material and Procedure As already mentioned, the test cases are written in the form of FIT tables and the supporting environment is a FitNesse wiki. The development environment is based on the Eclipse IDE with the FitNesse plugin3. For each group we prepared an Eclipse project containing the software

2 http://www.ﬁtnesse.org 3 http://www.bandxi.com/ﬁtnesse/

5/10 Volume X (2007) The Use of Executable FIT Tables to support Maintenance and Evolution Tasks

Table 2: Experimental design (S1 = LaTazza, S2 = AveCalc; + = with FIT tables, - = without FIT tables). Group A Group B Group C Group D Lab 1 S1+ S1- S2- S2+ Lab 2 S2- S2+ S1+ S1-

Table 3: Change requirements for LaTazza. CR1 There is an error in show debtors. Only employees with negative balance must be visualized. Fix the error. CR2 There is an error in update employees. Not all the ﬁelds are updated. Fix the error. CR3 The vendor of boxes of beverages changed his selling policy. Each ﬁve bought boxes one is added as a gift. CR4 Change price of small-bags. Now the total price of the beverages that an employee would like to buy depends on (i) the number of small bugs bought (ii) if the beverage is seasonal or not. If a employee buys a number of small bags minor than 5 no discount is applied. If a employee buys a number of small bags included between 5 and 10 of a seasonal beverage, no discount is applied; but if the beverages are not seasonal a 1 euro discount is applied.

and a FitNesse wiki with both requirements and change requirements. The projects were zipped and made available on a Web server. The experiment was introduced as a lab assignment about FitNesse. Every subject received: • summary description of the application • instructions to set-up the assignment (download the zipped Eclipse project, import it, and start the embedded Fitnesse server)

• A post experiment questionnaire For each Lab the subjects had two hours available to complete the four maintenance tasks: CR1 - CR4 (see table 3) . The first two change requirements (corrective maintenance) are very easy to implement, while the third and fourth require more work to locate the code to be changed and implementing the change (evolution). The maintenance/evolution tasks, for the two different systems, are very similar and of comparable difficulty. The post experiment questionnaire aimed at both gaining insights about the students’ behavior during the experiment and finding justifications for the quantitative results. It included questions about the task and systems complexity, the adequacy of the time allowed to complete the task and the perceived usefulness of the provided FIT tables. Before the experiment, subject were trained by means of introductory lectures (2 lessons 2 hours each) and laboratories (4 hours) on FIT. After subject were randomly assigned to the four groups, the experiment execution followed the steps reported below:

1. We delivered a sheet containing the description of the system.

Proc. Software Evolution 2007 6/10 ECEASST

2. Subjects had 10 minutes to read the description of the system and understand it.

3. Subjects had to write their name and start time on the delivered sheet.

4. Subjects had to download at the given URL the eclipse project and import it.

5. Subjects had to launch the Fitnesse wiki of the application.

6. Subjects had to write the stop time for installing the application.

7. For each change requirement (CR1-CR4):

(a) Subjects had to ﬁx the application code (LaTazza or AveCalc) in order to make the test cases pass (treatment +) or to satisfy the change requirement (treatment -). (b) Subjects had to record the time they use to apply change task (start/stop time).

8. Subjects were asked to compile the Post Experiment Questionnaire.

4 Experimental results

There were 13 subjects divided into three groups of three and one group of four. They took an median of 5 minutes to set up the environment and they worked for a median of 73 minutes on the tasks. The subjects deemed as complete an average of 2.75 tasks over four tasks assigned. The subjects worked on each task for a time ranging from 11 to 39 minutes with an average of 21. The distributions of passed tests and time required to complete tasks are not normal (Shapiro- Wilk test p=0.026 and p=6.9 · 10−6 respectively) therefore we will use the Mann-Whitney test for both hypotheses.

4.1 Data analysis

To test the first hypothesis (H0a) we compared the number of acceptance tests passed by the program whose change requirements included FIT tables or not. The boxplot summarizing the percentage (expressed as fraction) of passed test cases is presented in Figure 3. By applying a one- tailed Mann-Whitney test, we found the difference to be statistically significant (p-value=0.03), therefore we can reject the null hypothesis. The second hypothesis can be tested by looking at the time required to complete the tasks. Since not all students completed all the tasks and since the tasks’s difficulty varied both among tasks and systems, we analyzed the time for each task. Figure 4 shows the boxplot of times used by subjects to complete each task; filled boxes correspond to the presence of FIT tables. To test the second hypothesis we used a Mann-Whitney test. Table 4 reports the p-values of Mann- Whitney tests for each task. Overall in 5 cases out of 8 (see Figure 4) we observe a reduction of time (considering the median) when FIT tables are present but the only significant difference (highlighted in boldface in 4) is found for the first task on system AveCalc. With only this data we cannot reject the null hypothesis H0b. Further experiments are necessary to answer our second research question.

7/10 Volume X (2007) The Use of Executable FIT Tables to support Maintenance and Evolution Tasks Fraction of tests passed 0.0 0.2 0.4 0.6 0.8 1.0

no yes

Fit tables present

Figure 3: Boxplot of fraction of passed tests.

System AveCalc LaTazza Task p-value median yes median no p-value median yes median no 1 0.01 8 18 0.83 12 15.5 2 0.33 6 12 0.57 15 9 3 1.00 40 43 0.53 39 29 4 0.63 28 17 0.45 10 26

Table 4: Analysis results on times to complete tasks.

4.2 Analysis of Survey Questionnaires

The analysis of the survey questionnaires that the subjects ﬁlled-in after each experiment can be useful to better understand the experimental results. In this paper the analyses are supported only by descriptive statistics. Answers are on a Likert scale [Opp92] from 1 (strongly agree) to 5 (strongly disagree). Overall, all subjects agreed they had enough time to perform the tasks (I had enough time to perform the lab tasks, overall mean = 2.35) and the objectives were clear enough (The objectives of the lab were perfectly clear to me, overall mean = 1.73). The description of the systems were clear (overall mean = 2.08) as the change requirements (overall mean = 2.35). Similarly to Melnik et al. [MRM04], we can observe that the students deemed the FIT tables and the capability of running tests automatically useful enough. The possibility of executing FIT tables as tests was perceived useful for performing the change (Running FIT tables are useful in maintenance/evolution tasks, mean = 1.69). Moreover, FIT tables were also considered useful “per-se” to clarify change requirements (FIT tables are useful to clarify change requirements, mean = 1.92). See [RTCT07] for another experiment with students treating the research question: “FIT tables are able to clarify (change) requirements?”.

Proc. Software Evolution 2007 8/10 ECEASST Time to complete task [min] 10 20 30 40 50 60 70

Fit present: no yes no yes no yes no yes| no yes no yes no yes no yes Task: 1 2 3 4| 1 2 3 4 System: AveCalc| LaTazza

Figure 4: Boxplot of time required to complete task.

4.3 Threats to Validity Threats to conclusion validity can be due to the sample size (only 13 subjects) that may limit the capability of statistical tests to reveal any effect. Threats to external validity can be related to (i) the simple Java system chosen and (ii) to the use of students as experimental subjects. Another threat to external validity is that (iii) the results are limited to FIT-based acceptance test suites, which may be rather different from other approaches to acceptance testing. Further studies with larger systems and more experienced developers are needed to conﬁrm or contrast the obtained results.

5 Conclusion and Future Works

This paper reported a controlled experiment aimed at assessing the use of FIT executable acceptance test suites in the context of maintenance and evolution tasks. The obtained results indicates that FIT tables signiﬁcantly help developers to correctly perform the maintenance tasks. Other than looking at requirements, developers continuously execute FIT test cases to (i) ensure that FIT tables related to the change requirements passed and (ii) use application requirements FIT table to regression test the existing pieces of functionality. Regarding productivity, FIT table may or may not help: on the one hand, they provide a guideline to perform the maintenance task; on the other hand, they require time to be understood

9/10 Volume X (2007) The Use of Executable FIT Tables to support Maintenance and Evolution Tasks and executed. Further investigation is anyway necessary to answer our second research question. Future work will aim at replicating this study with a larger population of students, with professionals and by using larger and more realistic experimental objects. Also, other metrics (e.g., number of change requirements completed) and other factors such as subjects’ ability and experience will be taken into account.

Bibliography

[Aar06] J. Aarniala. Acceptance testing. In whitepaper. www.cs.helsinki.ﬁ/u/jaarnial/jaarnial-testing.pdf. October 30 2006.

[MC05] R. Mugridge, W. Cunningham. Fit for Developing Software: Framework for Inte- grated Tests. Prentice Hall, 2005.

[MRM04] G. Melnik, K. Read, F. Maurer. Suitability of FIT user acceptance tests for specifying functional requirements: Developer perspective. In Extreme programming and agile methods - XP/Agile Universe 2004. Pp. 60–72. August 2004.

[Opp92] A. N. Oppenheim. Questionnaire Design, Interviewing and Attitude Measurement. Pinter, London, 1992.

[RMM05] K. Read, G. Melnik, F. Maurer. Examining Usage Patters of the FIT Acceptance Testing Framework. In Proc. 6th International Conference on eXtreme Program- ming and Agile Processes in Software Engineering (XP2005). Pp. Lecture Notes in Computer Science, Vol. 3556, Springer Verlag: 127–136 2005. June 18-23 2005.

[RTCT07] F. Ricca, M. Torchiano, M. Ceccato, P. Tonella. Talking Tests: an Empirical Assess- ment of the Role of Fit Acceptance Tests in Clarifying Requirements. In 9th Inter- national Workshop On Principles of Software Evolution (IWPSE 2007). Pp. 51–58. IEEE, September 2007.

[TRD07] M. Torchiano, F. Ricca, M. Di Penta. ”Talking tests”: a Preliminary Experimental Study on Fit User Acceptance Tests. In IEEE International Symposium on Empirical Software Engineering and Measurement. (to appear) 2007.

[WRH+00] C. Wohlin, P. Runeson, M. Host,¨ M. Ohlsson, B. Regnell, A. Wesslen.´ Experimenta- tion in Software Engineering - An Introduction. Kluwer Academic Publishers, 2000.

Proc. Software Evolution 2007 10 / 10 ECEASST

The evolution of the Linux build system

Bram Adams1, Kris De Schutter3, Herman Tromp2 and Wolfgang De Meuter4

1 [email protected] 2 [email protected] GH-SEL, INTEC, Ghent University Sint-Pietersnieuwstraat 41, 9000 Ghent, Belgium

3 [email protected] 4 [email protected] PROG, Vrije Universiteit Brussel Pleinlaan 2, 1050 Brussels, Belgium

Abstract: Software evolution entails more than just redesigning and reimplement- ing functionality of, ﬁxing bugs in, or adding new features to source code. These evolutionary forces induce similar changes on the software’s build system too, with far-reaching consequences on both overall developer productivity as well as software conﬁgurability. In this paper we take a look at this phenomenon in the Linux kernel from its inception up until present day. We do this by analysing the kernel’s build traces with MAKAO, our re(verse)-engineering framework for build systems, which helps in detecting interesting idioms and patterns in the dynamic build behaviour. Finding a good balance between obtaining a fast, correct build system and migrating in a stepwise fashion turns out to be the general theme throughout the evolution of the Linux build system. Keywords: build system evolution, case study, Linux kernel, MAKAO

1 Introduction

The majority of software evolution research is targeted at direct participants in the evolution process like source code and design artifacts. While these play —of course!— a major role, much can be learnt from indirect evolution partners. The build system is one of them. A build system takes care of two things:

• it decides which components should be built as well as establishes any platform-dependent information needed to do so, and then

• it incrementally builds the system taking dependencies into account.

Before 1977, most people wrote their own ad hoc build and install scripts for this. Then, Feldman introduced a dedicated build tool named “make” [Fel79]. It was based on explicit declarative specifications of the dependencies between targets (executables, object files, etc.) in textual “makefiles”, combined with imperative “recipes” (list of shell commands) for building a target. A time stamp-based updating algorithm considerably improved incremental compilation

1 / 10 Volume X (2007) The evolution of the Linux build system of software projects and enhanced the quality of builds. The underlying philosophy of “make” has inﬂuenced lots of other build tools, but real “make” systems are still in wide use today. One example of such a widely used build system can be found in the Linux kernel. Linux is a —by now famous— operating system, used both by enthusiasts as well as in industrial settings. It started out in 1991, when Linus Torvalds sent an email to the Minix newsgroup, stating that he had developed a free operating system he wanted to share with everyone. It was a monolithic kernel, in which device drivers were hardcoded (e.g. Finnish keyboard), with user space programs ported over from Minix. In a little over ﬁfteen years, Linux has grown from this one-man hobby project into what is probably the largest open-source project on the planet. Linux has been the target of many studies. The one which is of most relevance to this paper was done by Godfrey and Tu in [GT00], where its source code was studied from the perspective of software evolution. Contrary to Lehmans laws [LB85], the kernel exhibited a superlinear growth in size. Source code, however, can not evolve in isolation. We claim that the build system co-evolves with the source code. Every time new source code gets added, or existing modules are moved around, one is forced to deal with the build system in order to get a newly compiled software system. An agile build system gives developers more freedom to restructure and refactor the source code. Hence, traditional evolution steps should have an immediate impact on the build system. Yet, no work to quantify this claim exists yet (the build system was ignored in [GT00]). In this paper, we will therefore examine this peculiar relation by means of the Linux kernel. Considering various major kernel releases from the very beginning to the recent versions, we will investigate the various forces on its build system. In Section 2 we will explain the setup of our case study on the Linux kernel and its build system. Our measurements will enable us to make three important observations. First (Section 3), we will investigate whether and how the build system evolves. Then (Section 4), we will look at the build system’s complexity. Finally (Section 5), we will zoom in on build system maintenance activities. As this is still preliminary work, we will point out future research directions (Section 6) before we summarise this paper’s contributions in Section 7.

2 Setup of the case study

The input for this case study exists of most of the pre-1.0 releases of Linux, as well as the major stable post-1.0 releases (up to the 2.6 series). This spans some 15 years of real-world development time. To each of these versions we applied David A. Wheeler’s SLOCCount tool1 in order to calculate the physical, uncommented SLOC (Source Lines Of Code) of source code (.c, .cpp, etc.), build scripts (Makefile, Kbuild, etc.), configuration data (config.in, Kconfig, etc.) and support build files (.sh, .awk, etc.). Next, we compiled each of the kernels using an initial configuration we reused and enhanced with new kernel features as needed throughout the measurements. The build traces were fed into MAKAO [ADTD07], our re(verse)-engineering framework for build systems, in order to obtain the corresponding dependency graphs, and figures on the number of targets and dependencies. Finally, each dependency graph was loaded into MAKAO to visualise, query and filter them.

1 http://www.dwheeler.com/sloccount/

Proc. Software Evolution 2007 2 / 10 ECEASST

5 ) 10 4

SLOC (log source code 2 build config 1 rest

Date sep-91 sep-92 sep-93 sep-94 sep-95 sep-96 sep-97 sep-98 sep-99 sep-00 sep-01 sep-02 sep-03 sep-04 sep-05 sep-06

Figure 1: Linux kernel complexity (SLOC).

More details on MAKAO can be found in [ADTD07], which explains the rationale behind it as well as its applicability in the realms of build maintenance. Now, we focus on one of the future work topics we mentioned there, i.e. learning things about the source code by looking at the build system. Therefore, it is important to know that MAKAO is built on top of GUESS [Ada06], a graph manipulation tool in which nodes and edges are objects with their own state and behaviour. They can be controlled using the embedded Gython scripting language. We can also reify the graph as Prolog facts and write logic rules to manipulate them. As such, dependency graphs can be inspected and studied in a more controllable way than by merely reading the build scripts.

3 Observation 1: the build system evolves

Figure 1 shows the growth over time of the number of non-comment and non-blank lines which make up both the source code, as well as the build system. The latter is made up of three parts: (1) the actual makefiles (build), (2) the configuration files which drive the selection process of what should get built (config), and (3) other tools and scripts which assist the actual build process (rest). This last category contains build-time scripts to extract symbol tables, install kernel components, etc. The observation to be made from this graph is that the build system evolves over time. Over the course of fifteen years the SLOC of the makefiles has grown by a factor of about 52. What

3 / 10 Volume X (2007) The evolution of the Linux build system Targets

5000 4500 4000 modules 3500 dep all/vmlinux 3000 2500 2000 #targets 1500 1000 500 0

Date sep-91 sep-92 sep-93 sep-94 sep-95 sep-96 sep-97 sep-98 sep-99 sep-00 sep-01 sep-02 sep-03 sep-04 sep-05 sep-06

Figure 2: Linux build system targets. is striking from this figure is the amount of work which has been put into the configuration and support system. These have grown from nothing in the first version to almost 60000 and 10000 lines resp., the former even getting ahead of the core build files. Based on this data a full evaluation of the build system should also include introspection of these assets, but this is not in the scope of this paper. The graph also gives a strong indication of co-evolution between source code and build system, as both more or less follow the same growth pattern. More data, e.g. at the subsystem level [GT00], is needed to identify the exact relationship.

4 Observation 2: complexity increases

In order to assess the evolution of the complexity of the build system we will take a look at some figures relating to the actual makefiles (as noted in the previous section, we will ignore configuration files and other supporting scripts). Figure 2 presents the growth over time of the number of targets which participate in a build. This point needs some elaboration. The Linux build process is divided into a number of phases, of which we will consider the most important ones. The kernel image is either built by a phase named all or vmlinux (starting from version 2.6.0 in 2003), while modules are built within the modules stage. Extraction of dependencies occurs during the dep-phase. As MAKAO works on dynamic traces of the build system [ADTD07], what Figure 2 shows is the number of targets checked by the build process during a concrete run of each of the five phases2.

2 Every kernel was built from scratch, i.e. we did not measure incremental builds.

Proc. Software Evolution 2007 4 / 10 ECEASST Explicit edges

20000 18000 16000 modules 14000 dep all/vmlinux 12000 10000 #deps 8000 6000 4000 2000 0

Date sep-91 sep-92 sep-93 sep-94 sep-95 sep-96 sep-97 sep-98 sep-99 sep-00 sep-01 sep-02 sep-03 sep-04 sep-05 sep-06

Figure 3: Linux build explicit dependencies.

Overall, Figure 2 reflects the point made in the previous section: the build system grows, not only in lines of code, but also in the number of tasks it attempts to complete. Starting from the 2.6 kernel in 2003, the dep-phase disappears as it is subsumed by the other two phases. Figure 3 and Figure 4 relate the growth over time of the number of explicit and implicit3 build dependencies respectively, for each of the five different build runs. Again, what we see here is a huge growth up to September 2000 (version 2.4 of the kernel), followed by a serious dip, the reason for which will become clear in the next section. We also notice that eventually the number of dependencies rises again, albeit at a slower pace. On the other hand, the number of targets does not face a similar crisis, it just keeps increasing. The first point to note here is related to what dependencies stand for. Basically, dependencies capture the relationships between targets. As their number grows, so does the complexity of understanding the relationships between the targets, which in their turn relate back to physical components of the software system and their interconnections. By “physical components”, we mean the decomposition of the source code in a sufficiently succinct way such that the build system is able to create a working application from it. Hence, the growth of the number of dependencies shows at least that understanding the build system becomes harder and harder. More investigation is needed to verify whether this is also a symptom of growing complexity in the source code. This problem becomes compounded when we consider the implications of Figure 4. What this shows is that there is also a steady growth in the number of implicit dependencies. This means that the number of relationships the build system knows nothing about is on the rise. This is

3 Implicit dependencies are relationships which are not explicitly declared as makeﬁle rule dependencies, but rather are buried inside a rule’s command list, e.g. as arguments of shell scripts.

5 / 10 Volume X (2007) The evolution of the Linux build system Implicit dependencies

4000

3500 modules 3000 dep all/vmlinux 2500

2000 #deps 1500

1000

500

Date sep-91 sep-92 sep-93 sep-94 sep-95 sep-96 sep-97 sep-98 sep-99 sep-00 sep-01 sep-02 sep-03 sep-04 sep-05 sep-06

Figure 4: Linux build implicit dependencies. not only problematic when trying to understand the build system, it also constitutes a potential source of build errors, and (at best) may lead to suboptimal builds.

5 Observation 3: maintenance as driver of build evolution

Having observed that the build system evolves and that its complexity increases throughout, we will now examine efforts of the Linux build developers to reduce this growing complexity. From Figure 1, we can deduce that in the pre-1.0 era (1992-1993) and between 2.2.0 and 2.4.0 (1999- 2000) effort has been spent to mitigate build complexity, as both periods show a decrease in SLOC of resp. fourteen and nine percent. In the ﬁrst case, a new recursion scheme had been introduced, while in the second case the majority of the makeﬁles was rewritten in a more concise “list-style” manner [lina]. Figure 3 also points at some reduction attempts like e.g. between 1.2.0 and 2.0.0 (1995- 1996) when common build logic was extracted into a shared build script called “Rules.make”. However, the biggest maintenance step occurred between 2.4.0 and 2.6.0 (2001-2003), because:

• the separate dependency extraction step has vanished and is subsumed in the other phases;

• the number of explicit dependencies has dropped drastically to one third of the 2.4.0 level;

• the number of targets in the vmlinux build has increased with a factor of 2.3.

Proc. Software Evolution 2007 6 / 10 ECEASST

.o } .c }

Figure 5: Linux 2.4.0 build process in phase all (without header ﬁle targets).

.o } .c } .h } dir }

Figure 6: Linux 2.6.0 build process (phase vmlinux).

7 / 10 Volume X (2007) The evolution of the Linux build system

__build

composite

5 4 2

simple1 simple2

dir1 dir2 dir3

Figure 7: Circular dependency chain in the Linux 2.6.0 build system.

.o } .c } .h } dir }

Figure 8: Phase vmlinux of the Linux 2.6.0 build process after ﬁltering of complex idioms.

When looking at the dependency graph of the 2.4.0 kernel image build (all) on Figure 54, we clearly see the various object and source files clustered per directory. Figure 6 shows the corresponding build dependency graph of release 2.6.05. We see a very dense build, almost one huge cluster of nodes. Paradoxically, the dependency graph looks much more complex after the maintenance activities than before. There are various reasons for the graph’s compactness. First, dependency generation now occurs as part of the build instead of as a separate phase. Second, a lot of dependencies are implicit and represent relations between object files and temporary files generated during the build, which were not there yet in the 2.4.0 case. Third, a couple of build idioms are in use, which tie together a lot of build targets. The most obvious one is the “FORCE”-idiom. Target

4 We elided header ﬁle targets for clarity. 5 Header ﬁles belong to two localised clusters, and are not hidden for that reason.

Proc. Software Evolution 2007 8 / 10 ECEASST

FORCE is a so-called “phony” target, i.e. it should always be rebuilt as it is never up-to-date. The majority of build rules depends on FORCE to make sure that all dependencies are checked. To avoid that everything is recompiled, the rules’ recipes always call a custom make function which decides whether the build target is still up-to-date. “Make” is solely used to express build dependencies and not to determine when rebuilding is necessary. Removing FORCE and the associated edges opens up the graph. There are still some other peculiarities. The kernel image consists of a number of modules which are giant object files linked together from various smaller ones. It is easy to detect these “composite objects” [linb], as their only dependencies are object files, while their parent node is always the same target named build. This one is actually the center of the graph. The upper four nodes of Figure 7 illustrate this pattern. In combination with these composites, a phenomenon we named “circular dependency chain” occurs. Figure 7 shows the basic pattern and its control flow. The central (phony) build target depends on all composite objects (arrow 1), which in turn depend on simple objects (arrow 2). Strangely, the latter depend on every possible subdirectory of their enclosing directory (arrow 3), and there is a bidirectional dependency between these and build (arrows 4 and 5). The following note in the main Makefile gives us a hint: “We are using a recursive build, so we need to do a little thinking to get the ordering right.”. The circular dependency chain is actually a clever iteration strategy the Linux developers added to their recursive build in order to get rid of typical side-effects [Mil97]. Indeed, to avoid any influence of the evaluation order of targets, every subdirectory target will recheck build to make sure that earlier targets are rebuilt if some of their dependencies have changed in the meantime. “Make”’s time stamp mechanism makes sure that this recursive algorithm stops. Figure 8 shows the resulting graph after filtering out the above idioms using logic rules. E.g. the circular dependency chain of Figure 7 has been hidden. The result resembles Figure 6’s structure, which is plausible, as the basic directory structure has remained stable between 2.4.0 and 2.6.0, and each directory more or less corresponds to a composite object. Only the recursive process has changed in the meantime to produce a higher-quality build at the expense of extra complexity, both during the build as well as for the developer.

6 Future work

We consider future work of this topic to consist of three major tracks. For one, we should broaden the scope of the study by also looking at other real-world systems, both open- and closed-source. This is needed in order to check whether our observations hold for a larger class of software. Also, it is important to stress that we limited ourselves to one representative kernel configuration. As one of the reviewers noted, performing a configuration-aware study could learn us a lot too. Other potential sources of information are source code repositories, bug databases, etc. The final track is to delve more deeply into this case. There are two main questions which have been left open in this paper, and which we believe need answering: (1) what part do the configuration files and supporting scripts play in the evolution of this build system, and (2) to what degree can we show a causal link between the evolution of the source code and that of the build system? As a corollary: Can one claim that source code re-engineering approaches can

9 / 10 Volume X (2007) The evolution of the Linux build system only be effective if corresponding build system consequences have been taken into account?

7 Conclusion

This paper presented a case-study of the evolution of a real-world build system, namely that of the Linux kernel. We analysed its growth in number of source lines of code (SLOC), as well as the number of targets and dependencies (both explicit and implicit) which are part of the makeﬁles. We also delved into some of the idioms which have shown up in recent kernel versions. From this case study we can make the following observations: (1) the build system evolves, (2) as it evolves it grows in complexity, and (3) it is maintained in order to deal with this growing complexity. These observations are in line with Lehmans’ laws of software evolution. It also strengthens our conviction that in order to modify/re-engineer the source code one will have to modify/re-engineer the build system. That is, a part of the source code evolution bill implicitly is spent on evolving the build system.

Acknowledgements: The authors want to thank the anonymous reviewers for their suggestions. Bram Adams is supported by a BOF grant from Ghent University. Kris De Schutter received support from the Belgian research project AspectLab, sponsored by the IWT, Flanders.

Bibliography

[Ada06] E. Adar. GUESS: a language and interface for graph exploration. In CHI ’06: Pro- ceedings of the 2006 Conference on Human Factors in Computing Systems. Pp. 791– 800. Montreal,´ Quebec,´ Canada, April 2006. [ADTD07] B. Adams, K. De Schutter, H. Tromp, W. De Meuter. Design recovery and maintenance of build systems. In ICSM ’07: Proceedings of the 23rd International Confer- ence on Software Maintenance. Paris, France, October 2007. To appear. [Fel79] S. I. Feldman. Make - A Program for Maintaining Computer Programs. Software - Practice and Experience, 1979. [GT00] M. W. Godfrey, Q. Tu. Evolution in Open Source Software: A Case Study. In ICSM ’00: Proceedings of the International Conference on Software Maintenance. P. 131. IEEE Computer Society, Washington, DC, USA, 2000. [LB85] M. M. Lehman, L. A. Belady (eds.). Program evolution: processes of software change. Academic Press Professional, Inc., San Diego, CA, USA, 1985. [lina] Linux-kbuild mailing list. http://www.torque.net/kbuild/archive/. [linb] Linux kernel build documentation. Linux 2.6.0 edition. [Mil97] P. Miller. Recursive make considered harmful. Australian UNIX and Open Systems User Group Newsletter 19(1):14–25, 1997.

Proc. Software Evolution 2007 10 / 10 ECEASST

Extraction of Component-Based Architecture From Object-Oriented Systems

Sylvain Chardigny1, Abdelhak Seriai1, Mourad Oussalah2, Dalila Tamzalit2

1 Ecole des Mines de Douai 941 rue Charles Bourseul 59508 Douai, France {chardigny,seriai}@ensm-douai.fr

2 LINA, université de Nantes 2 rue de la Houssinière 44322 Nantes, France {mourad.Oussalah,dalila.Tamzalit}@univ-nantes.fr

Abstract: Software architecture modeling and representation are a main phase of the development process of complex systems. In fact, software architecture representation provides many advantages during all phases of software life cycle. Nev- ertheless, for many systems, like legacy or eroded ones, there is no available representation of their architectures. In order to beneﬁt from this representation, we propose, in this paper, an approach called ROMANTIC which focuses on extracting a component-based architecture of an existing object-oriented system. The main idea of this approach is to propose a quasi-automatic process of architecture recovery based on semantic and structural characteristics of software architecture concepts. Keywords: Architecture recovery, software component, object-oriented, metrics, clustering.

Software architecture modeling and representation are a main phase of the development process of complex systems [BBGM05]. Architecture representation is based on components and connectors concepts in order to describe system structures at a high abstraction level. This representation provides many advantages during the software life cycle [SG96]. Indeed having a representation of software architecture makes exchanges between software architects and programmers easier. Then during maintenance and evolution phases, this representation helps to localize software defects and to reduce the risk of misplacing new system functionalities. More- over the distinction which exists, in this representation, between components and connectors makes the separation between functional and communication aspects explicit and consequently makes the system comprehension and evolution easier. Finally, component-based architecture is also useful in order to facilitate the reuse of some system parts represented as components. However most existing systems do not have a reliable architecture representation. Indeed these systems could have been designed without an architecture design phase, as it is the case for most legacy systems. In other systems, the available representation can diverge from the system implementation. This divergence, between the representation and the reality of the system is the result of the erosion phenomenon. This appears, ﬁrst, during the implementation phase due to

1 / 11 Volume X (2007) Extraction of Component-Based Architecture From Object-Oriented Systems gaps between the expected architecture and the implemented one. These gaps become greater because of lack of synchronization between software documentation and implementation. Taking into account the previous considerations, we propose an approach called ROMAN- TIC1. It focuses on extracting a component-based architecture from object-oriented systems. Our extraction approach is different from existing ones by the fact that it uses several guides, like semantic of architecture elements or architectural quality properties, in order to drive the extraction process. The remainder of this paper is structured as follows. Section 1 introduces the principles of our extraction process. In section 2, we present an evaluation of component semantic characteristics. Extraction process and a case study are respectively presented in sections 3 and 4. Section 5 discusses related work. Conclusion and future works are given in section 6.

1 ROMANTIC principles of software architecture extraction

1.1 Principle 1: extraction of software architecture from object-oriented systems During the design process of the architecture, an architect uses requirement specifications and his skill knowledge in order to determine architectural elements : components which describe functional computing, connectors which describe interactions and configuration which represents the topology of connections between components. Architecture extraction is the reverse process of the design one. Indeed the extraction process uses existing implementation code and the architect skills to obtain a system abstraction. Con- sequently, extracting an architecture from an object-oriented system consists of finding a correspondence between object concepts (i.e. classes, interfaces, packages, etc.) and architectural ones (i.e. components, connectors, interfaces, etc.). In ROMANTIC, we define a solution to the architecture extraction problem as a partition of system classes. Consequently, an architecture is defined according to the following correspondences. Firstly, a component to be extracted corresponds to a collection of classes which can belong to different object-oriented packages. Each of these collections is called a “shape”. We call “shape interface”, the classes which have a link with some classes from the outside of the shape, e.g. a method call to the outside (cf. Fig.1 left side). We assimilate component interface set to shape interface (cf. Fig.1 right side). Secondly, we consider that connectors are all the links existing between shapes. Finally, we consider the architecture configuration as a collection of identified shapes. In order to avoid the duplication issue of objects in several components, we impose that each class must belong to only one shape. Consequently the architecture configuration constitutes a partition of the system classes.

1.2 Principle 2: guides of the architecture extraction process The ﬁrst principle allows us to answer how to extract architectural elements from object-oriented ones. However, the issue how to extract a relevant architecture remains. The second principle gives an answer to that issue. Indeed, we consider that an architecture is relevant if it respects

1 ROMANTIC: Re-engineering of Object-oriented systeMs by Architecture extractioN and migraTIon to Compo- nent based ones.

Proc. Software Evolution 2007 2 / 11 ECEASST

Figure 1: Object/component correspondences

four guides (cf. Fig.2). Firstly, it must be semantically correct. Secondly, it must have good quality properties. Thirdly, it must respect precisely the recommendation of the architect and, as far as possible, speciﬁcations and constraints deﬁned in documentations. Finally, it must be adapted to the properties of the hardware architecture.

Figure 2: Extraction guides

We think that, using all these guides, our process provides a relevant component-based architecture representation. However, among all these guides, the one which uses the architectural element semantic is preponderant. That is why in this work we start with focusing on deﬁning an evaluation function of software architecture semantic according to the measurable properties of these characteristics.

3 / 11 Volume X (2007) Extraction of Component-Based Architecture From Object-Oriented Systems

2 Evaluation of software component semantic: a proposition

In order to define our evaluation function, we measure what a semantically correct architecture is. An architecture is semantically correct if its elements (components, connectors and configuration) are semantically correct. Nevertheless, the study of the connector and configuration semantic constitute a future work. For these reasons, we study, in the following, component semantic characteristics and define functions in order to measure them. This study is based on the most commonly accepted definitions of software components which include those associated to architectural ones. Indeed, this choice will make the extracted architecture easier to reify which can be helpful in order to achieve a migration from an object-oriented system to a component- based one for example. Finally, we use the evaluation functions of semantic characteristics of components in order to define our evaluation function of software architecture semantic.

2.1 Semantic of a software component

Many definitions exist where each one characterizes a component somewhat differently. Nonethe- less, some important commonalities exist among the most prevalent definitions. Szyperski defines, in [Szy98], a component as a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. In [HC01], Heinemann and Councill define a component as a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard. In combining and refining the common elements of these definitions and others commonly accepted [LH02], we obtain the following definition of a component:

A component is a software element that (a) can be composed without modiﬁcation, (b) can be distributed in an autonomous way, (c) encapsulates an implementation of functionality, and (d) adheres to a component model.

In our approach, the definition of a component model is the Luer one [LH02]: a model component is the combination of (a) a component standard that governs how to construct individual components and (b) a composition standard that governs how to organize a set of components into an application and how those components globally communicate and interact with each other. As compared to the definitions of Luer and Heineman and Councill, we intentionally do not include the criterion that a component must adhere on a composition theory and the properties of component self-descriptive, pre-packaged and easy to install and uninstall. These are covered through the criterion that a component must adhere to a component model and does not need to be repeated. In conclusion, according to our software component definition, we identify three semantic characteristics of software components: composability, autonomy and specificity which means that it must contain a limited number of functionalities.

Proc. Software Evolution 2007 4 / 11 ECEASST

2.2 Evaluation of the software component semantic correctness In the previous section, we have identified three semantic characteristics, that we propose to evaluate. To do so, we use the characteristic measurement model given by the norm ISO-9126 [ISO01](cf. Fig.3.A). According to this model, we can measure the characteristic semantic correctness which is refined in the previous three semantic characteristics which are consequently considered as sub-characteristics. We define a set of component measurable properties (e.g. number of provided/required interfaces) for each sub-characteristic. Nevertheless, we cannot define the metrics which measure these properties on shapes. Consequently, we use our correspondence model (cf. Fig.3.B) and match these component properties with the shape ones. Finally we propose metrics in order to measure these shape properties.

Figure 3: Characteristic measurement model in norm ISO-9126 and our approach

2.2.1 Component semantic sub-characteristics vs. component properties Based on the study of the semantic sub-characteristics, we reﬁne them to a set of component measurable properties. Thus, a component is autonomous if it has no required interface. Con- sequently, the property number of required interfaces should give us a good measure of the component autonomy. Then, a component can be composed by means of its provided and required interfaces. However, a component will be more easily composed with another if services, in each interface, are cohesive. Thus, the property average of service cohesion by component interface should be a correct measure of the component composability. Finally, the evaluation of the number of functionalities is based on the following statements. Firstly a component which provides many interfaces, may provide various functionalities. Indeed each interface can offer different services. Thus the higher the number of interfaces is, the higher the number of functionalities can be. Secondly if interfaces (resp. services in each interface) are cohesive (i.e. share resources), they probably offer closely related functionalities. Thirdly if the code of the component is closely coupled (resp. cohesive), the different parts of the component code use each other (resp. common resources). Consequently, they probably work together in order to offer a small

5 / 11 Volume X (2007) Extraction of Component-Based Architecture From Object-Oriented Systems number of functionalities. From these statements, we reﬁne the speciﬁcity sub-characteristic to the following properties: number of provided interfaces, average of service cohesion by component interface, component interface cohesion and component cohesion and coupling.

2.2.2 Component properties vs. shape properties Measuring component properties on shape is impossible. Consequently, according to our evaluation model (cf. Fig.3.B), we link the component properties to shape measurable properties. Firstly, according to our correspondence model (cf. Fig.1), component interface set is linked to the shape interface. Consequently the average of the interface-class cohesion gives a correct measure of the average of service cohesion by component interface. Secondly the component interface cohesion, the internal component cohesion and the internal component coupling can respectively be measured by the properties interface class cohesion, shape class cohesion and shape class coupling. Thirdly in order to link the number of provided interfaces property to a shape property, we associate a component provided interface to each shape-interface class having public methods. Thanks to this hypothesis, we can measure the number of provided interfaces using the number of shape interface classes having public methods. Finally, the number of required interfaces can be evaluated by using coupling between the component and the outside. This coupling is linked to shape external coupling. Consequently, we can measure this property using the property shape external coupling.

2.3 Definition of metrics used to the component semantic evaluation In the previous sections, we have established links between component sub-characteristics and shape properties. In order to measure these properties, we need to define metrics according to the particularities of our approach. The properties shape class coupling and shape external coupling require a coupling measurement. We define the metric “Coupling(E)” which measures the coupling of a shape E and “CouplingExt(E)” which measures the coupling of E with the rest of classes. They measure three types of dependencies between objects: method calls, use of attributes and parameters of another class. In addition, they are percentages and are related through the equation:couplingExt(E) = 100 − coupling(E). Due to the lack of space, we cannot detail these metrics. Shape properties average of interface-class cohesion, interface-class cohesion, and shape- class cohesion require a cohesion measurement. The first one requires a class cohesion measurement whereas the last ones require a class set cohesion measurement. For all, cohesion measurement can be obtained by computing the cohesion of a method and attribute set, respectively of the class or of the class set. The metric “Loose Class Cohesion” (LCC), proposed by Bieman and Kang [BK95], measures the percentage of pairs of methods which are directly or indirectly connected. Two methods are connected if they use directly or indirectly a common attribute. Two methods are indirectly connected if a connected method chain connects them. This metric satisfies all our needs for the cohesion measurement: it reflects all sharing relations, i.e sharing attributes in object-oriented system, and it is a percentage. Consequently, we use this metric to compute the cohesion in our process.

Proc. Software Evolution 2007 6 / 11 ECEASST

2.4 Evaluation of component semantic correctness In the previous section, we have linked each sub-characteristic to a shape metric set. We exploit these links in order to define an evaluation function for each sub-characteristic. Then, we use these functions to define an evaluation function of the semantic correctness characteristic. According to the links previously established between the sub-characteristics and the shape properties, we define the evaluation functions Spe,A,C respectively of specificity, autonomy and composability, where nbPub(I) is the number of interface classes having a public method and |i| is the shape interface cardinality:

1 1 Spe(E) = · ( · ∑LCC(i) + LCC(I) + LCC(E) 5 |I| i∈I +Coupling(E) − nbPub(I))

A(E) = couplingExt(E) = 100 −Coupling(E) 1 C(E) = · ∑LCC(i) |I| i∈I

The evaluation of the semantic correctness characteristic is based on the evaluation of each sub-characteristic. That is why we deﬁne this function as a linear combination of each sub- characteristic evaluation function (Spe, A, and C):

1 S(E) = (λ1 ·C(E) + λ2 · A(E) + λ3 · Spe(E)) (1) ∑i λi This linear form allows us to consider uniformly the sub-characteristics. The weight associated with each function allows the software architect to modify, as needed, the importance of each sub-characteristic.

3 Component identiﬁcation process

We use, in order to identify components, a two step process based on a clustering technique which aims at organizing objects into groups whose members are similar in some ways. The first step of our process is a hierarchical clustering whose result is a binary tree where each node represents a cluster, a leaf an initial element, and the root the final cluster. In a second step, we exploit this tree in order to obtain a class partition. The principle of the hierarchical clustering algorithm, defined by S.C.Johnson [Joh67], is shown in Fig.4.A. At the beginning, this algorithm assigns each initial element to a cluster (line 4). Then, in each step, the two more similar clusters (function nearestCluster) are merged into a single cluster (lines 5 to 10). The process stops when all items are merged into a single cluster. We obtain from this single cluster a dendrogram which represents the shape hierarchy. Figure 4.B presents a dendrogram. In this example, process steps are (a,c), (a,c,e), then (b,d) and finally (a,b,c,d,e).

7 / 11 Volume X (2007) Extraction of Component-Based Architecture From Object-Oriented Systems

Figure 4: Hierarchical clustering algorithm

We use this algorithm to merge system object classes. The evaluation of the cluster similarity consists of the application of our evaluation function S(E) on the shape composed of the classes belonging to the union of the two clusters. In order to obtain a partition of classes, we have to select nodes among the hierarchy resulting from the previous step. This selection is done by an algorithm based on a depth-ﬁrst search which selects nodes representing shapes which will be the best components. For each node, we compare the result of the evaluation function S for the node shape and for its sons. If the node result is inferior to the average of the result of its two sons, then the algorithm continues on the next node or else the node is identiﬁed to a shape, added to the partition and the algorithm computes the next node.

4 Case study: Jigsaw

We have experimented our extraction process on the Jigsaw software. Jigsaw is a Java based web server. This software has been used to present the architecture extraction process in previous works [MJ06]. Consequently the architecture of Jigsaw is well-known and presented in Figure 5. Jigsaw contains around 300 classes. The result of the ﬁrst step of the ROMANTIC tool is a dendrogram whose leaves are jigsaw classes. The second step of our process extracts 12 components from this dendrogram. The study of this result showed that it can be improved by applying two simple rules: if the graph of the component’s classes is disconnected, each connected part can create a new component; if one components is connected to only one component, the two components are merge together. After the application of these rules on the previous result, we obtain an architecture whose result for our evaluation function is 80% . Fig.5 presents Jigsaw architecture as thought, whereas Fig.5 presents the architecture extracted by ROMANTIC. Our architecture has extracted 16 more components than expected on. However the comparison of these architectures shows that most of our components are sub-components of

Proc. Software Evolution 2007 8 / 11 ECEASST

Figure 5: Focus result Figure 5: ROMANTIC result envisaged ones. Few of them are included, at the same time, in several envisaged components. The superposition of architecture extracted by ROMANTIC and that thought is shown in Fig.6. The study of these results shows that the ROMANTIC components included in expected ones deﬁne a functionality which is a sub-functionality of expected components. For example, envisaged component protocolFrame includes ROMANTIC component which manages frames on the web page.

5 Related work

Various works are proposed in literature in order to extract architecture from an object-oriented system [PDP+07]. We distinguish these works according to two criteria: the process input and technique used to extract architecture. The inputs of the extraction approaches are various. Most often it works from source code representations, but it also considers other kinds of information. Most of them are non-architectural. We can cite, for example, human expertise, which is used in an interactive way in order to guide the process [MJ06, KOV01], and physical organization, e.g. ﬁles, folders and packages [HRY95]. Some works use architectural input like styles for example. Medvidovic [MJ06] uses styles in Focus in order to infer a conceptual architecture that will be mapped to a concrete architecture extracted from source code. Finally most works are based on the human expertise: some use the expertise of the architect which uses the tools as an input whereas others use the expertise of the one which proposed this approach. In our approach we use architectural semantic in order to avoid this need of human expertise. This input will be completed by using the other guides and in particular the documentation which is used, in existing works, through the human expertise. Moreover ROMANTIC will use several inputs, using several guides whereas most works use only one or two inputs. The techniques used to extract architecture are various and can be classiﬁed according to

9 / 11 Volume X (2007) Extraction of Component-Based Architecture From Object-Oriented Systems

Figure 6: Superposition of extracted architectures their automation level. Most of approaches are quasi-manuals or semi-automatics. For example, Focus [MJ06] proposes a guideline to an hybrid process which regroup classes and maps the extracted entities to an idealized architecture obtained from an architectural style according to the human expertise. Semi-automatic techniques automate repetitive aspects of the extraction process but the reverse engineer steers the iterative refinement or abstraction, leading to the identification of architectural elements. This automation can be used in a bottom-up way, like in Dali [KOV01] or in top-down way, like ManSART [HRY95]. Finally, few techniques are quasi-automatic. Most of these techniques use clustering algorithms like in our approach. The main difference of these approaches with ours is the definition of the similarity function. For example, in [AFL99], the similarity is defined in order to product cohesive clusters that are loosely interconnected. In ROMANTIC we refine the commonly used definitions of components into semantic characteristics, measurement models and finally similarity function.

6 Conclusion

We propose, in this paper, an approach for the extraction of a component-based architecture from an object-oriented system. This approach is based on the use of the component semantic characteristics. These characteristics guide the partitioning of the system classes and the abstraction of each shape in a component. The main difference with existing works on architecture extraction is that we refine the commonly used definitions of components into semantic characteristics and measurement models whereas others works use the expertise of the authors in order to define rules driving the process. The extraction of connectors is a first future work. We need to study their semantic and decide when we will extract them: before, after or during the component extraction process. Finally as we mentioned it previously, the semantic characteristics that we use is not the only

Proc. Software Evolution 2007 10 / 11 ECEASST guide envisaged. The use of other guides will be considered in our future work. We have started the study of the architecture quality properties and deﬁnition of an evaluation function considering these properties. We will also consider the use of the design documents and all additional information provided by the architect.

Bibliography

[AFL99] N. Anquetil, C. Fourrier, T. C. Lethbridge. Experiments with Clustering as a Soft- ware Remodularization Method. In Proc. of the Sixth Working Conf. on Reverse Engineering. P. 235. IEEE Computer Society, 1999.

[BBGM05] A. Bertolino, A. Bucchiarone, S. Gnesi, H. Muccini. An Architecture-Centric Ap- proach for Producing Quality Systems. In QoSA/SOQUA. Pp. 21–37. 2005.

[BK95] J. M. Bieman, B.-K. Kang. Cohesion and reuse in an object-oriented system. In Proc. of the Symp. on Software reusability,SSR ’95. Pp. 259–262. 1995.

[HC01] G. Heinemann, W. Councill. Component-based software engineering. Addison- Wesley, 2001.

[HRY95] D. R. Harris, H. B. Reubenstein, A. S. Yeh. Reverse Engineering to the Architectural Level. In Proc. of the Int. Conf. on Software Engineering, ICSE-17. Pp. 186–195. ACM, Inc., 1995.

[ISO01] ISO/IEC-9126-1. In Software engineering - Product quality - Part 1: Quality Model. ISO-IEC, 2001.

[Joh67] S. Johnson. Hierarchical clustering schemes. Psychometrika 32:241–245, 1967.

[KOV01] R. Kazman, L. O’Brien, C. Verhoef. Architecture Reconstruction Guidelines. Tech- nical report, 2001.

[LH02] C. Luer, A. van der Hoek. Composition Environments for Deployable Software Components. Technical report, 2002.

[MJ06] N. Medvidovic, V. Jakobac. Using software evolution to focus architectural recovery. Automated Software Engineering 13:225–256(32), April 2006.

[PDP+07] D. Pollet, S. Ducasse, L. Poyet, I. Alloui, S. Cimpan, H. Verjus. Towards A Process- Oriented Software Architecture Reconstruction Taxonomy. In Proc. of the 11th Eu- ropean Conf. on Software Maintenance and Reengineering. Pp. 137–148. 2007.

[SG96] M. Shaw, D. Garlan. Software architecture: perspectives on an emerging discipline. Prentice-Hall, USA, 1996.

[Szy98] C. Szyperski. Component Software. ISBN: 0-201-17888-5. Addison-Wesley, 1998.

11 / 11 Volume X (2007) ECEASST

Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

Javier Perez´ 1, Yania Crespo2

1 [email protected], www.infor.uva.es/∼jperez 2 [email protected], www.infor.uva.es/∼yania 1,2 Departamento de Informatica,´ ETSI Informatica´ Universidad de Valladolid, Valladolid, Spain

Abstract: One of the problems of documenting software evolution appears with the extensive use of refactorings. This paper explores a method, based on graph transformation, to detect wether the evolution between two versions of a software system can be expressed by means of a sequence of refactoring operations. For this purpose we extend a graph representation format to use it for simple Java programs, and we show a sample implementation of the method using the AGG graph transformation tool. In case a refactoring sequence exists, our technique can help reveal the functional equivalence between the two versions of the system, at least, as far as refactorings can assure behaviour preservation. Keywords: ﬁnding refactoring sequences, documenting software evolution, behaviour preservation, functional equivalence, graph transformation

1 Introduction

Refactorings [FBB+99, Opd92] are structural transformations that can be applied to a software system to perform design changes without modifying its behaviour. Efforts to include refactorings as a regular technique in software development have led refactoring support to be commonly integrated into development environments (e.g. Eclipse Development Platform, IntelliJ R Idea, NetBeans, etc.). Finding refactorings, now that they are extensively used, is one of the problems of documenting and understanding software evolution [DDN00]. We explore a method, based on graph transformation [EEKR99, Roz97], to search for a refactoring sequence which can describe the evolution of a software system. A toy Java system will be used, as an example, to explain our approach. The AGG graph transformation tool [ERT99] is used for a sample implementation of the method. The paper is organised as follows. Firstly, in Section 2 we show the example used to illustrate our proposed method. Section 3 introduces an extension of a graph format to allow representing simple Java programs as graphs, and Java refactorings as graph transformation rules. In Section 4 we describe our method to ﬁnd refactorings using graph parsing. Section 5 describes a sample implementation using the AGG graph transformation tool and, in Section 6 we show the test-run of this implemention with the previously formulated example. The analysis and comparison to related work of our approach is performed in Section 7. Finally, in Section 8 we present our future work and conclude. inheritance

1 / 10 Volume X (2007) Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

2 A short example

We will use a toy Java system, slightly inspired in the LAN simulation example [JDM03, MT04], as a running example to illustrate our approach. Our original system (see Figure 1(a)) was designed to model printers for different document types and a hub to connect them, providing a single access point. A hierarchy of default and specific printers allows to add more printers when needed. When the administrator notices that no other type than pdf documents are sent, the original system is rashly modified to simplify the printer hierarchy (see Figure 1(b)). When a new system administrator arrives, he finds the two versions of the system, and no documentation about the changes performed between them. The problem here is not only about documenting the changes performed, but mainly to test whether the new system is functionally equivalent to the old one. For space reasons we have simplified the example removing some method’s bodies.

//------PrinterHub.java //------PrinterHub.java public class PrinterHub { public class printerHub { public void printWithPDF(PDFPrinter p){ public void print(Printer p){ p.printPDF(); p.print(); } } } } //------PDFPrinter.java public class PDFPrinter extends Printer{ public void printPDF(){ // body of printPDF method } } //------Printer.java //------Printer.java public class Printer { public class Printer { public String content; public String content; public void setContent(String c){ public void setContent(String c){ this.content = c; this.content = c; } } public void printDefault(){ public void print(){ // body of printDefault method // body of print method } } } } (a) The original printing system (b) The modiﬁed printing system Figure 1: The printing system example

We know that the new system was obtained after applying the following sequence of refactorings over the old one: 1) removeMethod applied to Printer.printDefault(); 2) pullUpMethod applied to PDFPrinter.printPDF(), placing it at Printer.printPDF(); 3) renameMethod executed over Printer.printPDF(), which is renamed as Printer.print; 4) renameMethod executed over PrinterHub.printWithPDF(), which gets renamed as PrinterHub.print; 5) useSuperType applied over Printer.print(PDFPrinter p), resulting the new method signature Printer.print(Printer p); 6) removeClass performed over the class PDFPrinter. This sequence uses only refactorings supported by a refactoring tool. This restriction implies that it is composed by widely tested refactorings, being also widely recognised that they are behaviour-preserving. This guarantees that the sequence is behaviour-preserving and both versions of the system are functionally equivalent. These transformations belong to the set supported by the Eclipse Development Platform 1. The removeMethod and removeClass, whose deﬁnitions can be found, for example, in [Opd92], are not provided by Eclipse. These refactorings can be performed manually, checking the preconditions and deleting the desired source code.

1 Eclipse Development Platform homepage: http://www.eclipse.org

Proc. Software Evolution 2007 2 / 10 ECEASST

3 Representing refactorings with graph transformation

To tackle the problem we use a formal representation for refactorings and Object-Oriented software. Refactorings involve modiﬁcation of the system structure, and refactoring deﬁnitions must include preconditions and postconditions in order to guarantee that these changes are behaviour- preserving. Therefore, we have selected graph transformation [EEKR99, Roz97] as the underlying formalism because its naturally focused on description and manipulation of structural information and allows to model refactoring conditions too. Formalisation of refactorings with graph transformation is described and validated in [EJ05, MVDJ05]. In that work, programs and refactorings are represented with graphs, in a language-independent way, using a kind of abstract syntax trees with an expressiveness level which is adequate for the problem.

3.1 Java programs as graphs We use the part of the formalism from [MVDJ05] referenced as “program graphs” and related to software representation to represent Java programs. As it is suggested in that work, it is necessary to extend the graph format when representing programs containing specific elements and constructions of a particular language. Bearing this fact in mind, we have developed an extension to represent simple Java programs which we have named “Java program graphs”. We describe the edges and nodes which build up this representation format within Tables 2(a) and 2(b), including the elements of the original format and our modifications. Observing the contribution of our extension, it can be noticed, for example, that some new node types have been added to represent packages, interfaces, literals and operators, altogether with their relationships edges. We also included a type attribute to E nodes, in order to represent control structures and language constructions like a return or an instantiation (new) expression. Added seq attributes to E and P nodes allow to represent the order of the sentences within a method body and the order of the parameters within the signature of a method. Using our extension, we can represent the old version of the printing system (see Figure 1(a)) as displayed in Figure 3. The graph shows that a prefix s: has been added to each node and edge type label. This prefix is needed by the implementation that will be described later.

3.2 Refactorings as graph transformation rules Graph transformation rules are similar to the derivation rules of string grammars. To apply a rule, a graph transformation system looks for a subgraph, within the graph currently being transformed, which matches the left-hand side of the rule. Then, the left-hand side matched subgraph is transformed into the subgraph of the right-hand side. Rule constraints, such as negative application conditions, can be added. Negative application conditions (NAC) describe subgraphs which forbid the application of a rule if a match for the NAC exists. The basis of formalising refactorings as graph transformation rules is presented in [EJ05, MVDJ05]. Figure 4(c) shows how we specify a simpliﬁed version of the removeMethod refactoring with the AGG graph transformation tool. The leftmost part of Figure 4(c) is the left-hand side of the rule. It represents a method signature (node type M) dynamically linked (edge type l) to a method deﬁnition (node type MD) which is a member (edge type m) of a class (node type C). The

3 / 10 Volume X (2007) Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

Label Edge Description i: C −→ C inheritance relationship between classes (reference on an “extends” Concept Node Attributes Description subexpression) package PKG Java package I −→ I inheritance relationship between interfaces (reference on an “extends” name: string name subexpression) interface I (same as package) Java interface C −→ I class which implements an interface (reference on an “implements” class C Java class subexpression) name: string name o: C −→ I an interface is observable from a class (“import” subexpression) visibility: enum visibility: [non-public, public, C −→ C a class is observable from a class (“import” subexpression) protected, private] I −→ I an interface is observable from an interface (“import” subexpression) hierarchy: enum order within a inheritance hierar- I −→ C a class is observable from an interface (“import” subexpression) chy: [abstract, middle, ﬁnal] t: M −→ C type of a method static: boolean is static?: [true, false] V −→ C type of a variable or attribute method M (same as class) signature of a method P −→ C type of a formal parameter MD implementation of a method L −→ C type of a literal/constant variable V (same as class) atttribute or local variable m: MD −→ C body of method MD appears in class C VD attribute or local variable decla- VD −→ C declaration of an attribute within a class ration VD −→ MD declaration of a local variable within a method’s body parameter P formal parameter PKG −→ PKG a package belongs to another package seq: integer position of the parameter within C −→ PKG a class belongs to a package the parameter list I −→ PKG an interface belongs to a package expression E expression, subexpression or M −→ I method’s signature belongs to an interface sentence VD −→ I attribute declaration belongs to an interface type: enum type of expression: [new, return, l: M −→ MD binding of method’s signature to a method’s body if, else, for, loop, ... ] V −→ VD binding of an attribute or a local variable to its declaration seq: integer order within a sequence of p: M −→ P formal parameter declaration within a method’s signature subexpressions sharing the root e: MD −→ E expression within a method’s body node, i.e. sentence order E −→ E subexpression or hierarchical relationship between expressions operator O operator d: E −→ VD local variable declaration in subexpression type: string string that represents the opera- c: E −→ M method call in subexpression tor E −→ O operator used in subexpression literal L literal or constant a: E −→ V access to a local variable or attribute value: string string representation of the lit- E −→ P access to a parameter eral value E −→ L access to a literal (a) nodes and attributes u: E −→ V variable update expression E −→ P parameter update expression (b) edges Figure 2: Description of nodes and edges of Java program graphs right-hand side describes the result of the rule application. All the elements that represent the method found by the left-hand side matching subgraph, have been removed from that subgraph. Figure 4(b) describes a NAC: if any expression (node type E) exists, which represent a call (edge type c) to the method in the left-hand side, the rule can not be applied. The numbers appearing in the graph elements stand for identity mappings between elements from the different parts of the rule (left-hand side, right-hand side and NAC). Attribute values, like name=mName, specify variables, parameters of the rule, which are substituted with values from the graph to ﬁnd a match. When the left-hand side of the rule is matched to a subgraph and a match for the NAC can not be found, the subgraph is transformed into the right-hand side of the rule. Application of the rule of Figure 4(c) removes a method from the class where it is declared.

4 A method to detect refactoring sequences

Using the representation format described in the previous Section, we can apply graph parsing algorithms to search for a refactoring sequence between two different versions of a software system. We address the problem of ﬁnding this transformation sequence as a state space search problem. With this approach we identify: the original/old system as a start state, refactoring operations as state changing operations (edges), the refactored/new system as the goal state, the problem of whether a refactoring sequence exists as a reachability problem, and a refac-

Proc. Software Evolution 2007 4 / 10 ECEASST

Figure 3: The original system of the example

(a) NAC: method does not (b) NAC: method call does (c) Rule: removeMethod exist in target not exist in source Figure 4: Rule to search removeMethod toring sequence as the path from the start state to the goal state. We will refer to the old version of the system as “source”, to the new version of the system as “target” and we will use “current” to refer to the state being explored at a certain point. The “current” state will represent a system that is being transformed into the new version during the searching process. We propose a basic search algorithm to search for refactoring sequences (see Figure 5). In order to allow some kind of guided search and the future addition of heuristics, we use preconditions and postconditions of refactorings. So our approach needs refactoring deﬁnitions which include preconditions and postconditions, as they are used in [KK04].

5 Implementation in the AGG graph transformation tool

We have prepared a prototype with version 1.6.0 of AGG [ERT99]. AGG is a rule based visual language, and tool, supporting an algebraic approach to graph transformation 2. We have chosen AGG mainly because it allows rapid prototyping of graph transformation systems. Additionally, it supports graph parsing, what can be used to perform depth ﬁrst search with backtracking, allowing us to explore our algorithm straightly, with little implementation effort.

2 AGG home page, graph grammar group, Technische Universitat¨ Berlin: http://tfs.cs.tu-berlin.de/agg

5 / 10 Volume X (2007) Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

Graph source, current, target end //if List rules_to_apply, ruleset, sequence end //if Rule rule; Pair(Graph, List) node; Stack stack end //while if current is isomorphic to target then initialise source, target, ruleset return sequence //success else copy source to current return empty //fail rules_to_apply = find_rules(current,target,ruleset) end //if rule = rules_to_apply.remove_first sequence = empty List find_rules(Graph source, Grah target, List ruleset) while current is not isomorphic to target and do rules_to_apply is not empty List rules_to_apply = empty; do Rule rule; if rule is not empty then // candidate rule sequence.add_last(rule) foreach rule in ruleset do current = apply_rule(current,rule) if rule.precondition holds in source and rules_to_apply = find_rules(current,target,ruleset) rule.postcondition holds in target rule = rules_to_apply.remove_first then stack.push(node(current,rules_to_apply)) // state rules_to_apply.add_last(rule) else end //if sequence.remove_last end //foreach node = stack.pop // recover a previous state sort(rules_to_apply,random) if node is not empty then return rules_to_apply current = node.graph; rules_to_apply = node.rules rule = rules_to_apply.remove_last end //find_rules

Figure 5: Basic refactoring searching algorithm

AGG graph parsing, which is mainly oriented to visual languages parsing [RS97], allows checking whether a particular graph belongs to the graph language generated by a graph grammar or not. A graph grammar includes an initial graph and a set of graph transformation rules. The set of graphs generated by a graph grammar defines a graph language. To perform graph parsing, AGG needs a “parsing grammar”, a grammar whose transformation rules are reversed so they can transform a given graph to reduce it to the initial graph of the grammar. The tool needs at least: a set of graph transformation rules, the graph to be transformed, called “host graph” and the initial graph, called a “stop graph”. The parsing process is based on a simple backtracking algorithm. The tool randomly chooses graph transformation rules from the parsing grammar and iteratively applies them to the host graph. The process stops when there are no more applicable rules or when the host and stop graphs become isomorphic. To implement our method we use the source system representation as the host graph, and the target system representation as the stop graph. The host graph also acts as the “current” graph, the graph being transformed during the searching process. To guide the search, we have added another subgraph to the host and to the stop graph: a guidance graph which is another copy of the target system graph. This graph allows to prioritise the selection of refactorings whose “effects” or postconditions can be found within the target system. Each iteration, to select a refactoring for the sequence, its preconditions are searched within the “current” graph and its postconditions within the guidance graph, which does not change during the parsing process. To distinguish both subgraphs, we have added the prefix s: to labels in the source and target system graph, and t: to labels in the guidance graph. This can be seen in the rule of Figure 4. First, we implement a refactoring operation by specifying the transformation source and context in the left-hand side of the rule and the result on the right-hand side. These elements have their type labels prefixed with s: (see Figure 4(c). Additional refactoring preconditions, which do not form part of the refactoring context, must be expressed as NACs formulated over the current graph (see Figure 4(b)). Refactoring postcondi-

Proc. Software Evolution 2007 6 / 10 ECEASST tions are speciﬁed as conditions over the guidance graph. Positive postconditions are included within the left-hand side of the rule, while negative postconditions must be expressed as NACs. Figure 4(a) express that the removed method does not exist in the target system graph.

6 Parsing the example

We launch the parser using the graph representation of the old system (see Figure Figure 3) as the host graph, the graph representation of the modified system as the stop graph, and the search rules for the refactorings mentioned in Section 2 as parsing rules. In order to explore our approach, we have only implemented the rules needed by the example. Given the small complexity of experiment, the state space resulted is finite and thus the parser does not have problems finding a valid sequence. Termination of the algorithm depends on the size of the state space, which we believe can be restricted with the use of refactoring postconditions in the searching process. To test our approach we just needed a raw output from the parser. We obtained the parser’s debugging information to know which rules have been applied, when backtracking occurs, the intermediate graphs, etc. From that debugging information, we have extracted that the parser has found the refactoring sequence: 1 → 4 → 3 → 2 → 5 → 6. This sequence differs from the one we proposed in Section 2 but it is an equivalent one for our purposes, and thus is a valid result. The main goal of our approach was not to find the exact refactoring sequence which was originally applied. Our goal is to find wether the system evolution was behaviour-preserving and to try to formulate this evolution in terms of a suitable refactoring sequence. This result is enough to detect the functional equivalence and to document the general intention of the changes applied. Even if the developer does not know to have applied a behaviour- preserving sequence of changes, if this has been the case, it can be revealed. More experiments, with more refactoring rules, bigger systems, and different graph transformation tools are planned, to test the scalability and obtain the performance details of the approach.

7 Discussion

7.1 Related work As far as we know, there are not many works dealing with ﬁnding refactorings, and the efforts have been mainly addressed to mining refactorings that occur mixed with other changes which are not behaviour-preserving. Our approach focuses on computing if a refactoring sequence exists between two versions of a software systems or not. What we offer, through this refactoring sequence calculation, is a kind of test for functional equivalence between systems as long as the refactorings we support assure behaviour preservation. Demeyer et al. [DDN00] use metrics to reveal refactorings with the purpose of helping a programmer to understand the evolution of a system. Their technique applies to a scenario where human examination of the source code is performed after the automatic analysis. The main problems of the approach are that it does not behave well with renamings and that it looses effectiveness when many changes have been applied to the same piece of code. With our approach, multiple refactorings executed over the same element can be found easily.

7 / 10 Volume X (2007) Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

To apply a refactoring searching rule we initially impose the condition of finding the refactoring postcondition in the refactored system graph. Refactoring postconditions included in the rule definition can be more or less restrictive. Less restrictive postconditions allow the rule to be applied whether the refactoring immediate result can be observed on the refactored system graph or not. The more restrictive postconditions we include in the refactoring searching rules definitions, the smaller the state space to search is. We can fine-tune the refactoring searching rules to balance state space size against searching capability. Handling renamings is not a problem either in our approach. The previous argumentation applies in this case too. Renamings are expressed in the same way as any other refactoring, and we can increase the capability of finding renamings making their postconditions less restrictive. Gorg¨ and Weißgerber [GW05] present an approach to find refactorings from consecutive transactions in CVS repositories. A transaction, in this context, is each new version of a system submitted to the repository. This work is based in pairing and comparing elements (classes and methods) between consecutive transactions, using element attributes such as name, parameters, return type, visibility, etc. The method presents good empirical results, but can not detect refactorings when more than one change has been applied to a program element. This work also shows an interesting technique of change visualisation that helps in software comprehension. As already said, our approach allows to fine-tune the searching rules to maximise the searching capability. We can adjust a rule so it can be selected even if the effects of a refactoring are overridden by another one making the first disappear from the refactored system graph. Dig et al. [DCMJ06] have developed an effective approach which has been proved to offer good empirical results. Their technique of shingles computing is oriented to find refactorings that affect software APIs and behaves well at that level of detail. The limitation suffered by this method is that it can not deal with changes performed within method bodies. The advantage of our approach relies on its graph transformation basis. Our graph transformation approach is based on a structural representation of the source code which can be as detailed as needed in order to support refactorings at any detail level.

7.2 Known problems and limitations Our approach presents a technique that aids to check the functional equivalence between two versions of a software system. A parsing analysis having an affirmative result will reveal behaviour preservation between two versions of a system and will generate a refactoring sequence. The main limitation of our approach arrives when analysing two versions which are not functionally equivalent, because the state space we search is probably not finite. Our searching algorithm is only partially correct. An affirmative result will undoubtedly generate a valid refactoring sequence, but it is not complete because termination can not be guaranteed. Our parsing grammar does not belong to a graph grammar category with termination condition, such as layered graph grammars [EEL+05]. So, it is not guaranteed that our searching method terminates. We believe that this can be overcome if we formulate the refactoring searching rules in a way they could restrict the search space to a finite state space. In spite of the parsing support provided by AGG, this tool lacks some key features in order to be able to fully specify any refactoring searching rule. The rules that we have presented are sufficient to show the validity of our method, but it is quite obvious that they did not fully conform

Proc. Software Evolution 2007 8 / 10 ECEASST to “real” refactoring operations implemented in a development tool. In rule removeMethod (see Figure 4), e.g. a method is specified just by its name, and its context is defined just by its container class (which is also identified just by its name). This problem appears because the AGG graph language allows to specify only one context per rule. We need to be able to specify a set of contexts within a single rule, and more expressiveness is needed for that. This can be achieved using, for example, path expressions as they are supported on the PROGRES graph transformation tool [Mun99¨ ]. It has also been difficult to represent some kind of rules in AGG, those with an iterative nature, which take an undetermined number of steps to be executed. The transformation control that AGG has been supporting was based in rule layering and this is not sufficient to formulate that kind of rules. More complex execution control has been recently implemented in the last versions of AGG, that allows to gather a set of rules and to designate a main rule to fire them.

8 Results and future work

We have presented a technique based on graph transformation to find whether a refactoring sequence exists between two versions of a software system or not. Despite of showing some limitations, the sample implementation that has been reviewed can be seen as a proof of concept, and it offers very promising results. The main limitation of our approach is that our searching method is only partially correct, and it could not terminate in certain cases. In order to solve this problem an exhaustive analysis of the state space must be done. We must determine if we can formulate the refactoring searching rules to restrict the search space to a finite state space. Once we have proved the validity of our approach, our immediate objective is to implement refactoring searching rules to support more refactoring operations and to measure the scalability of our technique over industrial-size systems. This will include improving rule descriptions to take benefit of features in the newest versions of the AGG tool. From the raw information the parser outputs we are able to identify the refactoring sequence it finds, but this is only valid for the purpose of testing our approach. There is a clear need to develop a front-end tool to show up the refactoring sequence in a more convenient way. We also believe that building tool is a fundamental step to demonstrate an approach. Thus this is planned to be provided as a plugin for the Eclipse Development Platform, which has a strong refactoring support. Up to date, we have already developed an initial Eclipse plugin [MA06] to automatically obtain a Java program graph representation and to show the parser results.

Bibliography

[DCMJ06] D. Dig, C. Comertoglu, D. Marinov, R. Johnson. Automatic Detection of Refactor- ings in Evolving Components. In ECOOP 2006 - Object-Oriented Programming; 20th European Conference, Nantes, France, July 2006, Proceedings. 2006.

[DDN00] S. Demeyer, S. Ducasse, O. Nierstrasz. Finding refactorings via change metrics. In OOPSLA. Pp. 166–177. 2000.

9 / 10 Volume X (2007) Exploring a Method to Detect Behaviour-Preserving Evolution Using Graph Transformation

[EEKR99] H. Ehrig, G. Engels, H.-J. Kreowski, G. Rozenberg (eds.). Handbook of Graph Grammars and Computing by Graph Transformations, Volume II: Applications, Languages and Tools. Volume 2. World Scientific, 1999. [EEL+05] H. Ehrig, K. Ehrig, J. de Lara, G. Taentzer, D. Varro,´ S. Varro-Gyapay.´ Termination Criteria for Model Transformation. In Cerioli (ed.), FASE. Lecture Notes in Com- puter Science 3442, pp. 49–63. Springer, 2005. [EJ05] N. V. Eetvelde, D. Janssens. Refactorings as Graph Transformations. Technical report, Universiteit Antwerpen, 2005. [ERT99] C. Ermel, M. Rudolf, G. Taentzer. The AGG approach: language and environment. Volume 2 in [EEKR99], chapter 14, pp. 551–603, 1999. [FBB+99] M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts. Refactoring: Improving the Design of Existing Code. Object Technology Series. Addison-Wesley, 1999. [GW05] C. Gorg,¨ P. Weißgerber. Detecting and Visualizing Refactorings from Software Archives. In IWPC. Pp. 205–214. 2005. [JDM03] D. Janssens, S. Demeyer, T. Mens. Case Study: Simulation of a LAN. Electr. Notes Theor. Comput. Sci. 72(4), 2003. [KK04] G. Kniesel, H. Koch. Static Composition of Refactorings. Science of Computer Pro- gramming 52(1-3):9–51, 2004. Special issue on Program Transformation, edited by Ralf Lammel,¨ ISSN: 0167-6423, http://dx.doi.org/10.1016/j.scico.2004.03.002. [MA06] B. Mart´ın Arranz. Conversor de Java a grafos AGG para Eclipse. Master’s thesis, Es- cuela Tenica´ Superior de Ingenier´ıa Informatica,´ Universidad de Valladolid, Septem- ber 2006. [MT04] T. Mens, T. Tourwe.´ A Survey of Software Refactoring. IEEE Transactions on Soft- ware Engineering 30(2):126–139, 2004. [Mun99]¨ M. Munch.¨ PROgrammed Graph REwriting System PROGRES. In Nagl et al. (eds.), AGTIVE. Lecture Notes in Computer Science 1779, pp. 441–448. Springer, 1999. [MVDJ05] T. Mens, N. Van Eetvelde, S. Demeyer, D. Janssens. Formalizing refactorings with graph transformations. Journal on Software Maintenance and Evolution: Research and Practice 17(4):247–276, July/August 2005. [Opd92] W. Opdyke. Refactoring Object-Oriented Frameworks. PhD thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, 1992. also Techni- cal Report UIUCDCS-R-92-1759. [Roz97] G. Rozenberg (ed.). Handbook of Graph Grammars and Computing by Graph Trans- formations, Volume I: Foundations. Volume 1. World Scientific, 1997. [RS97] J. Rekers, A. Schurr.¨ Defining and Parsing Visual Languages with Layered Graph Grammars. J. Vis. Lang. Comput. 8(1):27–55, 1997.

Proc. Software Evolution 2007 10 / 10 ECEASST

Evolutionary success of Open Source software: an investigation into exogenous drivers

Karl Beecher, Cornelia Boldyreff, Andrea Capiluppi and Stephen Rank1

1 (kbeecher,cboldyreff,acapiluppi,srank)@lincoln.ac.uk Centre of Research on Open Source Software – CROSS Department of Computing and Informatics University of Lincoln, UK

Abstract: The “success” of a Free/Libre/Open Source Software (FLOSS) project has often been evaluated through the number of commits made to its configuration management system, number of developers and number of users. Based on Source- Forge, most studies have concluded that the vast majority of projects are failures. This paper argues that the relative success of a FLOSS project depends also on the chosen forge and distribution: given a random sample of 50 projects contained within a popular FLOSS forge (Debian, which is the basis of the successful Debian distribution), we compared these with a similar sample from SourceForge, using product and process metrics, like size achieved and developers involved. The results show at first that, depending on the forge of FLOSS projects, researchers can draw different conclusions on the overall concept of success of FLOSS software. Secondly, the projects included in the Debian distribution benefit, on average, from a larger evolutionary activity and a larger number of developers than the comparable projects on SourceForge. Finally, the Debian projects benefit from more activity and more developers from the point at which they joined this distribution. Keywords: FLOSS, repositories, metrics, success, evolvability

1 Introduction

In terms of Lehman’s ﬁrst law of software evolution, it can be anticipated that a useful and widely used real-world software system, known as an evolutionary (or E-type) software system, must undergo continuing change, i.e. that it must evolve [LRW+97]. Some well-known Open Source projects, such as the so-called LAMP (Linux, Apache, MySQL, Perl), the Debian family, and *BSDs, have achieved higher evolvability than others [MFH02]; these systems are categorised as E-type. Their evolvability is made possible through these projects attracting a large community of users as well as a strong base of developers. The user community initiates the need for change while the developers make it happen; both are key factors in the evolution process. The term “success” of FLOSS projects has been often empirically evaluated via endogenous characteristics, such as the amount of development activity, the number of developers, or by using proxies of their pool of users. Moreover, FLOSS literature has traditionally tackled this research topic by sampling well-known FLOSS forges (mostly SourceForge), and concluding that the vast majority are “unsuccessful”, or “dead” projects [ES07]. Perhaps because they are

1/13 Volume X (2007) Evolutionary success of Open Source software too specialised in their functionality, but also it could be that through lack of publicity, they have never achieved the wide spread usage, nor attracted the developers that would drive their evolution. Using the literature terms, those projects never gained a ‘bazaar’ state, where users join in a self-sustaining cycle and become developers on the project [SM04, RG06, CM07]. Unless an open source evolutionary software project has enough developers to satisfy its users’ needs for change, it is likely to fail. An interesting case arises when one open source project becomes incorporated into another, larger one; this is often found in the Open Source operating system projects, such as Debian, e.g. in the case of new packages. In such a case, the incorporated package project becomes as widely-distributed as the incorporating project and potentially is able to reach the same user base and benefit from the developer base of the incorporating project. This paper investigates the exogenous drivers of FLOSS evolvability, and studies whether the inclusion of a specific project in the same forge and distribution of a successful FLOSS project (Debian) has an influence on its evolutionary characteristics. In order to understand the influence of these drivers, we randomly sampled 50 projects from both forges: Debian and SourceForge, and studied their evolution. Our goal is to determine whether the visibility given by the inclusion into Debian increases the number of developers and their activity, compared to the SourceForge sample. Also, we studied the “entry point” of each project into the Debian forge and distribution, and evaluated its activity both prior to and after this event. This paper is structured as follows: Section 2 reviews related work in the area of FLOSS char- acterisation and section 3 introduces the traditional Goal-Question-Metric approach [BCR94], as applied to the research topic of this paper. Two major questions will be introduced and later instantiated in several hypotheses in section 4. Section 4.1 empirically evaluates and tests the hypotheses derived from the first question, while section 4.2 presents the results for the second question. Section 6 presents our conclusions.

2 Related work

There are two main types of FLOSS literature, tentatively termed external and internal to the FLOSS phenomenon: based on the availability of FLOSS data, the former has traditionally used FLOSS artefacts in order to propose models [HG05], test existing or new frameworks [CCP07, LHMI07], or build theories [ACPM01] to provide advances in software engineering. The latter includes several other studies that have analysed the FLOSS phenomenon per se ([SAOB02, Cap03, Ger04] with their results aimed at both building a theory of FLOSS, and characterising the results and their validity specifically as inherent to this type of software and style of development. In this section we review some of the works of the latter category. The success and failure of FLOSS projects has been extensively studied in the past: some specific forges were analysed, and metrics were computed of extracted from the forges themselves. Examples include the use of the vitality and popularity indexes, computed by the SourceForge maintainers, which were used to predict other factors on the same forges [SA02], or the comparison of the status of the projects between two different observations [FFH+02]. Also data was collected from SourceForge about community size, bug-fixing time and the popularity of projects, and it was used to review some popular measures for success in information systems to the FLOSS case [CAH03a]. Popularity of FLOSS projects was also assessed using web-

Proc. Software Evolution 2007 2/13 ECEASST search engines [Wei05]. Other studies observed projects from SourceForge, and from their release numbers they inferred their activity or success within a sample [CAH03b], while other researchers sampled the whole SourceForge data space, and concluded that the vast majority of FLOSS projects should be considered as failures [RG05]. Finally, other researchers have created 5 categories for the overall SourceForge site, based on dynamic growth attributes, and using the terms “success” and “tragedy” within the FLOSS development. Again, it was shown that some 50% of the FLOSS projects should be considered as tragedies [ES07]. Tthere are several tools and data sources which are used to analyse FLOSS projects. FLOSS- mole1 is a single point of access to data gathered from a number of FLOSS forges(e.g., Source- Forge, Freshmeat, Rubyforge). While FLOSSmole provides a simple querying tool, its main function is to act as a source of data for others to analyse. CVSAnaly2 is a tool which is used to measure any analyse large FLOSS projects [RKG04]. It is used in this paper to determine such information as the number of commits and developers associated with a particular project.

3 Goal, Question, Metrics – GQM

The Goal-Question-Metric (GQM) method evaluates whether a goal has been reached by associ- ating that goal with questions that explain it from an operational point of view and providing the basis for applying metrics to answer these questions. The aim of the method is to determine the information and metrics needed to be able to draw conclusions on the achievment of the goal. In the following, we applied the GQM method to first identify the overall goal of this research; we then formulate a number of questions related to the FLOSS projects and their success relative to their host forge and distribution to which they belong; and finally we collect adequate product and process metrics to determine whether the goal has been achieved. Goal: The long-term objective of this paper is to evaluate metrics to identify successful FLOSS projects, and to provide guidelines to FLOSS developers about practical actions to foster the successful evolution of their applications. Based on two samples from Debian and SourceForge, a comparison of their product and process characteristics will be evaluated to determine which sample should be considered more successful in terms of their evolution. This will also give an indication of the forges and distributions in which developers should include their projects so that they may achieve the best outcomes for their project’s future development. Question: The purpose of this study is to establish differences between samples of FLOSS projects extracted from Debian and SourceForge. Two sets of questions will be evaluated, one comparative and one internal to Debian: the first will deal with a direct comparison of the evolutionary characteristics achieved by the projects in the two samples, and the latter will study the projects in the Debian sample, and evaluate whether their evolution after being included in the distribution is different from that before this date. The date when a FLOSS project was inserted into the Debian distribution will be termed “entry point”. The difference before and after the entry point will be evaluated by comparing the activity and number of developers in each phase. As a summary the two main questions underlying this study can be formulated as follows: 1. Are projects in Debian statistically different from projects in SourceForge?

1 http://ossmole.sourceforge.net/ 2 http://cvsanaly.tigris.org/

3/13 Volume X (2007) Evolutionary success of Open Source software

2. After being inserted into the Debian forge and distribution, do FLOSS projects leverage more activity and developers than before? In section 4, the ﬁrst question will be articulated in four research hypotheses, while the second question will lead to two further hypotheses. Metrics: This study uses three sources of information to assess the above questions: the SourceForge and the Debian forges to select two random samples of projects; each project’s own repository (either their CVS or SVN); and, among the projects within the Debian sample, their entry into Debian. Each of these sources has been analysed to obtain the metrics needed to perform the investigation: the metrics for the study will be introduced in each section below.

3.1 Debian and SourceForge samples

The Debian forge (http://www.debian.org/) hosts a large number of FLOSS projects under a common name. At the time of writing, more than 20,000 projects are listed under the “stable” label of the latest version. Using a randomiser, we selected 50 of these stable projects. A summary of the projects retrieved from Debian can be found in the ﬁrst column of table 1. The SourceForge site (http://sourceforge.net/) hosts more than 150,000 projects. In order to draw an accurate comparison, the sample from SourceForge was extracted only from the pool of the “stable” projects, i.e. those projects whose core developers labelled the status of the project with the tag “Production/Stable”. The number of projects from Debian and SourceForge in this category is comparable (around 22,000). A summary of the projects that have been chosen from the SourceForge site can be found in the ﬁrst column of table 2.

3.2 Code repositories

The CVS/SVN repository of each project from the Debian or the SourceForge sample was searched: in the sample of 50 Debian projects, 42 existing repositories were found. In order to provide a similar sample, 42 repositories were also selected from the SourceForge sample. The following concept and attributes were used to build a table of results for each project: Commit: the atomic action of a developer checking in one or more files (being source code or other) into a central repository. Modules and subsystems: at a fine granular level, both CVS and SVN repositories record activity on files (here termed as “modules”) and their containing folder (termed “subsystem”). Date: CVS/SVN repositories record the time when the module and its subsystem was modified or created from scratch. A date with ISO formatting “YYYY-MM-DD” was recorded. Developers: we recorded this information in two ways: firstly by assigning the activity to the actual committer who placed the file into the repository; secondly by using any further developers who were mentioned in the commit, by means of mentioning his/her involvement in the coding or patching. This information was used to characterise the input provided to each project. Touch: Since many modules and subsystems can be committed in the repository within the same commit, and the same module could have been modified by more than one developer in the same commit, the term “touch” was used to isolate the atomic information of a unique date, unique union on module and subsystem, and unique developer.

Proc. Software Evolution 2007 4/13 ECEASST

project oldest date entry date newest date days touches Dev. SLOC acpidump 2003-05-01 2005-09-26 2003-05-01 1 34 1 2349 apmud 2001-12-07 2000-05-23 2001-12-24 18 95 1 2502 clamav 2003-07-29 2002-05-09 2007-06-02 1405 5382 9 116731 dia 1998-10-01 1998-09-02 2007-06-07 3172 12828 126 146550 EtoileWildMenus 2006-03-04 2006-10-03 2007-04-16 409 46 3 1711 fte 2000-01-30 1996-12-25 2007-03-15 2602 1937 16 51498 geomview 2000-08-15 1998-08-02 2007-05-21 2471 7777 6 101844 grass6 1999-12-29 2003-11-10 2007-06-02 2713 42135 77 107648 gwenview 2006-06-20 2001-09-16 2007-06-06 352 449 5 4580 kdegames 1997-09-11 1997-09-20 2007-06-07 3557 19659 243 118479 kdenetwork 1997-11-26 1997-10-19 2007-06-06 3480 43130 818 272576 kmouth 2003-01-17 2004-01-30 2007-06-05 1601 647 31 5240 liboil 2004-01-07 2004-11-04 2007-05-29 1239 3106 4 52996 mimedecode 2006-06-19 1996-11-29 2006-06-19 1 16 1 631 mod auth kerb 2002-05-01 2004-02-21 2006-11-22 1667 349 2 119 myphpmoney 2002-11-20 2003-01-15 2007-05-27 1650 741 5 19434 octaveforge 2001-10-10 2001-02-25 2007-06-02 2062 16044 48 78150 Pike 1996-09-22 2002-05-05 2007-05-30 3903 21449 69 173196 prelude-manager 2001-08-23 2002-04-11 2007-05-02 2079 1557 44 10854 ProofGeneral 1996-03-15 2002-09-03 2007-05-25 4089 10425 20 48692 ruby 1998-01-16 2003-08-23 2007-06-05 3428 23968 143 419942 scid 2002-04-04 2001-02-13 2003-12-12 618 633 2 89402 shorewall 2002-05-01 2001-12-30 2007-06-06 1863 79498 4 25159 skel 2001-05-20 2003-07-13 2007-01-24 2076 219 13 120 sylpheed 2005-01-12 2000-09-30 2007-06-04 874 2719 2 106087 tcl 1998-03-26 1997-08-19 2007-05-30 3353 39124 109 165306 tdb 2000-08-14 2001-05-07 2005-08-02 1815 295 9 3261 tiobench 2000-03-23 2000-11-08 2003-12-22 1370 110 3 1689 txt2html 2007-01-15 2001-03-30 2007-05-10 116 4 1 3623 vlc 1999-08-08 2000-03-13 2007-06-06 2860 34736 113 401256 wxWidgets 1998-05-20 2000-02-13 2007-06-01 3300 246022 104 2142713 xmakemol 1998-04-03 2001-10-31 2006-09-23 3096 1386 4 18724 yaml4r 2002-06-22 2003-08-23 2003-04-24 307 498 1 10728 ﬁg2ps 2005-11-16 2003-10-28 2007-02-19 461 105 1 397 syncekde 2003-02-11 2003-08-15 2006-11-26 1385 622 5 21684 noteedit 2004-09-15 2001-07-01 2005-07-30 319 590 4 63456 grub 1999-02-28 1997-11-19 2007-02-22 2917 5101 76 3536 libsoup 2000-12-06 2003-03-19 2007-06-01 2369 1548 42 15012 prcs1 2001-06-25 1997-03-28 2005-02-07 1324 858 5 37360 kphoneSI 2005-10-12 2002-12-20 2007-05-23 589 1630 1 41829 cdparanoia 1999-08-15 1998-05-16 2006-11-15 2650 297 6 9182 rlplot 2002-06-06 2004-04-16 2007-05-28 1818 1405 1 69493 Table 1: Summary of attributes of the Debian projects: in bold, the projects where there is a recorded evolution before and after the entry-point

5/13 Volume X (2007) Evolutionary success of Open Source software

project oldest date newest date days touches developers SLOC audiobookcutter 2006-05-06 2007-05-22 381 958 2 4229 pf 2005-10-03 2006-08-29 330 3207 2 84489 seagull 2006-06-06 2007-05-31 359 707 5 62875 csUnit 2002-12-16 2006-08-14 1337 2147 1 16241 ﬁtnesse 2005-03-26 2007-06-04 800 5172 12 39503 galeon 2000-07-06 2007-04-20 2479 10839 82 93374 expreval 2006-08-29 2007-04-11 225 282 1 3588 cdlite 2005-12-06 2007-04-12 492 46 1 1116 txt2xml 2002-04-27 2006-07-26 1551 155 3 1345 wxactivex 2005-01-26 2005-01-27 1 59 1 3264 ustl 2003-03-21 2007-03-31 1471 11470 1 11416 neocrypt 2003-05-23 2005-06-25 764 108 2 2135 cpia 2000-03-02 2004-10-17 1690 429 15 22954 moses 2002-05-07 2007-02-20 1750 5170 8 105955 critical care 2002-01-18 2002-09-22 247 1708 5 38994 xmlnuke 2006-03-27 2007-03-07 345 888 2 57944 jtrac 2006-03-18 2007-06-06 445 1577 1 12771 QPolymer 2006-01-10 2007-05-24 499 459 1 86971 kasai 2004-08-31 2007-05-30 1002 673 3 8786 fourever 2005-02-23 2007-05-28 824 1795 2 15163 xqilla 2005-11-01 2007-05-28 573 8867 3 107320 uniportio 2006-05-29 2007-02-03 250 32 1 1096 genromfs 2002-01-18 2005-08-18 1308 94 3 654 Beobachter 2006-08-31 2006-12-10 101 376 1 2715 perpojo 2003-06-10 2003-07-31 51 70 1 1677 oliver 2004-07-22 2006-01-14 541 187 3 1429 hge 2005-11-18 2007-03-18 485 1183 3 45654 fnjavabot 2004-06-18 2007-06-05 1082 660 8 10142 ozone 2001-12-17 2005-12-12 1456 6108 7 63790 juel 2006-05-13 2007-04-25 347 990 1 7284 edict 2002-12-06 2006-12-28 1483 82 1 2556 Aquila 2004-05-04 2004-05-28 24 78 1 893 swtjasperviewer 2004-11-21 2007-05-21 911 188 1 3214 eas3pkg 2006-10-26 2007-05-22 208 274 2 43724 formproc 2001-05-10 2004-12-22 1322 1338 1 3514 toolchest 2002-01-03 2005-07-16 1290 15 1 494 ogce 2006-11-27 2007-06-03 188 26596 3 350997 simplexml 2002-08-23 2002-08-23 0 64 1 1691 intermezzo 2000-11-12 2003-09-30 1052 2276 15 34792 whiteboard 2003-06-15 2003-06-27 12 49 1 4910 modaspdotnet 2004-07-16 2007-03-02 959 688 1 2445 kpictorial 2002-05-09 2002-06-04 26 339 1 18214 Table 2: Summary of attributes of the SourceForge projects

Proc. Software Evolution 2007 6/13 ECEASST

3.3 Entry date Every project within the Debian distribution has its own page under the Debian website, where the ChangeLog (typically an unstructured list of amendments to the project) shows the ﬁrst entry in terms of changes made since the introduction into Debian. By manually investigating and recording this date, we collected the information of the lifecycle of each project “before” and “after” its inclusion into Debian. For instance, the Debian Changelog for “clamav” is shown at http://tinyurl.com/2njfon. At the bottom of the page, the ﬁrst date indicates that this project entered Debian on May 9th, 2002, in its 0.11-1 release. All history before that date will be treated as pre-Debian, after that date it will be treated as the post-Debian lifecycle.

4 Hypotheses and Results

Hypotheses have been formed concerning the two questions derived from the GQM approach. Here they are grouped by the question to which they belong along with their results.

4.1 Empirical evaluation of question 1 The ﬁrst research question was designed as a direct comparison between the Debian and Source- Forge samples, and its objective was to highlight any signiﬁcant difference on the selected characteristics. Each of these hypotheses is evaluated empirically: given the null hypothesis in the second column of table 3, a statistical test will either reject it or not. A summary of the tests and their results will be provided at the end of this section to wrap up the relevant conclusions.

4.1.1 Hypothesis 1.1 – Period of Activity This hypothesis posits that the duration of time that projects from each forge have been evolved over differs significantly, measured by the number of days for which activity could be observed on a project’s repository. The null hypothesis states that Debian and Sourceforge projects have a similar time-span, which should be rejected if the sample projects display significant difference. Table 3 show that, apart from the minimum values (just 1 day of activity recorded in the repository), the two samples have different medians, different quartiles Q1 and Q3, and different maximum values. Applying both the t-test and the Wilcoxon test for two independent samples, we can reject the null hypothesis with 99.99% confidence for each tests.

4.1.2 Hypothesis 1.2 – Size Achieved The second hypothesis postulates that the typical size of a project differs signiﬁcantly for each forge, in terms of SLOC (sources lines of code), with the null hypothesis stating that both forges have similar sizes, to be rejected if project sizes are shown to be signiﬁcantly different. The results were evaluated on the extracted repositories using the R programming language. They show that projects from Debian are larger than those in SourceForge (although we found several outliers in the Debian distribution of sizes). The size of Debian packages also has a greater range, with a greater number of outliers of larger magnitude found in the Debian distribution, implying the presence of larger communities.

7/13 Volume X (2007) Evolutionary success of Open Source software

Hypothesis: Days of evolution H0: Debian and sf.net projects have a similar time H1: Debian projects have a longer time span span min Q1 median Q3 max debian 1 588 1740 2916 4088 sf.net 1 247 495.5 1290 2479 t-test t = -5.279 D.F. = 82 p ≤ 1.142 × 10−6 Wilcoxon W = 1320 p ≤ 3.248 × 10−5 Hypothesis: distribution of size H0: Debian and sf.net projects have a similar size H1: Debian projects are larger than sf.net min Q1 median Q3 max debian 119 3,782 48,686 110,945 2,142,554 sf.net 654 2,346 11,416 49,854 106,478 t-test t = -1.627 D.F. = 82 p ≤ 0.11 Wilcoxon W = 1550 p ≤ 0.036 Hypothesis: distinct developers H0: Debian and sf.net projects have a similar amount H1: Debian projects have more developers than sf.net of developers min Q1 median Q3 max debian 1 2 5,5 48 818 sf.net 1 1 2 3 82 t-test t = -2.294 D.F. = 82 p ≤ 0.02436 Wilcoxon W = 1343 p ≤ 7.829 × 10−5 Hypothesis: overall touches H0: Debian and sf.net projects have a similar amount H1: Debian projects have more touches than sf.net of touches min Q1 median Q3 max debian 1 2 5,5 48 818 sf.net 1 1 2 3 82 t-test t = -2.029 D.F. = 82 p ≤ 0.04577 Wilcoxon W = 1548.5 p ≤ 0.03475 Table 3: Summary of the hypotheses, tests and results of the tests

Proc. Software Evolution 2007 8/13 ECEASST

From Table 3 we see that the two samples show different distributions in terms of size achieved. The null hypothesis was based on the assumption that the two sample come from the same population, and therefore have the same average: based on the tests, we can reject the null hypothesis with 89% and 96% of conﬁdence (for the t-test and the Wilcoxon test, respectively).

4.1.3 Hypothesis 1.3 – Developers This hypothesis posits that the number of developers that a project attracts is, on average, significantly different for each forge, measured according to the number of unique developers who have contributed source code. The null hypothesis states that Debian and SourceForge projects have approximately equal number of contributing developers, to be rejected if this is not the case. The final column of tables 1 and 2 shows the number of distinct developers (CVS or SVN committers or external developers acknowledged during a specific commit). We found several outliers in the Debian sample which rendered the average of the population sample to 51 developers, while the SourceForge sample has an average of some 5 developers only. In table 3 the summaries for the boxplot evaluation are visualised, as well as the results of the t-test (with 82 degrees of freedom) and the Wilcoxon test. Since the null hypothesis is that the two sample have the same median, the two tests show that, for a confidence of 97.5% and 99.99% (for the t-test and the Wilcoxon test, respectively), we can reject the null hypothesis. That means that there is a statistically significant difference in the distribution of the evolution days in the two samples.

4.1.4 Hypothesis 1.4 – Activity (Touches) The final hypothesis for question 1 postulates that the amount of activity (or output) observed differs between each forge. Specifically, the null hypothesis states that, on average, individual Debian projects and individual SourceForge projects will have a total number of file touches that does not differ significantly. We may reject this if it is shown that either forge tends to harbour significantly more active projects than the other. The results are summarised in tables 1 and 2 . As seen in the previous test, some projects (notably wxWidgets and shorewall) clearly skew the distribution of the Debian sample. The two tests show that, for a confidence of 0.04 and 0.03 (for the t-test and the Wilcoxon test, respectively), there is a statistically significant difference in the distribution of the activity (in terms of the amount of overall touches) of the two samples.

4.2 Empirical Evaluation of Question 2 This section examines Debian only, and investigates whether it can be considered an external driver for achieving a better software evolvability. Each project in this sample was analysed with regards to the two phases of its lifecycle, i.e. before and after the date when it was ﬁrst included into Debian. If the projects experienced two statistically different behaviours before and after the entry date, we could conclude that the “Debian treatment” is responsible for this difference. As shown in table 1, the bold entries in the entry date column represent the date of each project’s ﬁrst appearance in Debian. This entry point, e, has been used to separate each project

9/13 Volume X (2007) Evolutionary success of Open Source software into two phases, so the dependent variable in each hypothesis can be measured between both the earliest available date and e, and between e and the latest available date. For some projects the entry date appears before any data was collected in their repository, hence there is no data to draw a comparison of activities and developers before and after the entry date. For hypotheses 2.1 and 2.2 only projects with data available both before and after the entry point will be considered.

4.2.1 Hypothesis 2.1 – Developers

The first hypothesis for this question postulates that the number of contributing developers a project has before insertion into Debian is significantly different to that figure after insertion. The null hypothesis assumes that no significant difference will be observed between the two durations. The metric used is the number of distinct developers. The results are shown in the first two columns of Table 4. As can be observed the number of distinct developers in the second part of the lifecycle are always more than or equal to that of the first part. In 18 projects out of 22, the number of distinct developers after the introduction into Debian is strictly larger than before, while 4 projects out of 22 have the same amount of developers both before and after the inclusion. These latter 4 are relatively smaller projects, where at most 1 or 2 developers are currently responsible for the overall development. Since the majority of the observed projects showed a larger number of developers in the second part of the lifecycle, we rejected the null hypothesis.

4.3 Hypothesis 2.2 – Activity (Touches)

The second hypothesis posits that the amount of activity a project displays before appearing in Debian is significantly different to that after the event. The null hypothesis states that no significant difference in activity is apparent in the two durations. As in hypothesis 1.4, activity is measured in number of file touches. The results are summarised in table 4: each project was given an ID, while the overall number of touches before, T (pre), and after, T (post) is shown in the second and third columns. Con- sidering these unadjusted values, all considered projects show a larger number of touches after joining Debian: these results lead us to reject the null hypothesis. Considering the dates shown in table 1, some projects had a longer time span within the Debian distribution than outside. To consider this point, columns 5 and 6 of table 4 report an adjusted value, given by the touches divided by the relative interval of time spent either outside or inside Debian (T/D (pre) and T/D (post) respectively). As shown by the ticks in the final column, 12 projects out of 22 experienced an adjusted number of touches which was larger before joining Debian than afterwards. This did not allow us to reject the null hypothesis, and hence to consider the observed differences in the two phases as related to the applied treatment. As reported, the only case where the null hypothesis had to be rejected regards the amount of touches done in projects within the Debian forge. In general, projects achieved a larger amount of activity after the insertion into Debian, but this was not accomplished with the same amount of touches per day (i.e., productivity) than before the entry point.

Proc. Software Evolution 2007 10 / 13 ECEASST

ID D (pre) D (post) T (pre) T (post) T/D (pre) T/D (post) √ √ √ 1 9 10 10 1417 1.11 12.88 √ √ √ 2 17 41 10 88 0.59 2.15 √ √ 3 1 2 14 18 14 6 X √ √ 4 5 44 15 117 3 2.66 X √ √ √ 5 1 1 18 18 18 18 √ √ 6 2 2 22 22 11 7.33 X √ √ √ 7 22 42 25 86 1.14 2.05 √ √ √ 8 1 1 31 37 31 37 √ √ 9 2 243 32 954 16 3.93 X √ √ 10 9 31 40 41 4.44 1.32 X √ √ 11 10 13 43 50 4.3 3.85 X √ √ 12 7 9 44 55 6.29 6.11 X √ √ √ 13 2 2 46 49 23 24.5 √ √ 14 2 5 49 63 24.5 12.6 X √ √ 15 2 4 53 74 26.5 18.5 X √ √ 16 1 5 60 82 60 16.4 X √ √ √ 17 1 1 67 67 67 67 √ √ 18 1 4 160 576 160 144 X √ √ √ 19 14 20 436 779 31.14 38.95 √ √ 20 61 69 1666 1673 27.31 24.25 X √ √ √ 21 50 76 3972 6429 79.44 84.59 √ √ √ 22 41 104 6923 18595 168.85 178.8 Table 4: Summary of the number of distinct developers and overall touches in the two samples

5 Threats to Validity

The limited information (from hypothesis 2) affects the ability to demonstrate a temporal relationship; what exists does not consistently conﬁrm that cause precedes effect. However sugges- tive the data is of such a relation, more measures applied to these and other forges of similar prestige would help form a stronger opinion of temporal precedence. The ability to generalize from this study may be threatened by the Debian forge (and others of similar prestige) possessing attributes unique to them that may adversely effect their ability to, for example, attract new developers. To provide more conﬁdence of generalizability it would need to be established that other forges acting as repositories – yet providing different services, such as Mozilla or KDE – exhibit the same characteristics measured here.

6 Conclusions

This paper has investigated the presence of exogenous drivers to software evolvability, and proposed that the inclusion in a successful FLOSS forge (Debian) has an inﬂuence on the evolutionary characteristics of FLOSS projects. The recipients of this paper were both researchers and practicioners: on the researcher side, it aimed to show that by investigating and comparing different FLOSS forges it is likely to draw different results, and to characterise differently the FLOSS phenomenon. On the practicioners

11 / 13 Volume X (2007) Evolutionary success of Open Source software side, the paper shows that FLOSS developers, if interested in further fostering the development of their project, should consider the inclusion in one large distribution or forge like Debian. The paper leveraged the well-known GQM method: two research questions were then formulated, the first based on a direct comparison between the two samples, the second regarding the Debian sample only. The first question postulated that the Debian forge would have significantly different attributes to Sourceforge. Debian projects were shown to have a longer period of evolution, were larger in size, attracted more developers and experienced greater activity than SourceForge. All of the designed hypotheses showed a difference in the two random samples, and this positively assessed the first overall research question: Debian projects indeed show different characteristics than projects from SourceForge. The second research question was based on the Debian sample only and assessed the presence of two phases of evolution, i.e. before and after the inclusion into the Debian forge. In statistical terms, we studied whether there existed differences before and after applying a treatment to the sample. The first hypothesis proposed that there are more developers after being inserted into Debian, and the majority of projects showed this to be the case. The second hypothesis concerned the activity before and after the entry point: from the results we gathered, we could not conclude that there was a statistically significant difference before and after the treatment. This could be the result of measuring activity in terms of touches. Further research is required to substantiate the more general proposition that widespread distribution builds the user base of a FLOSS project thus driving its evolution, while incorporation into a distribution with an existing developer base provides the basis for sustainable evolution.

Bibliography

[ACPM01] G. Antoniol, G. Casazza, M. D. Penta, E. Merlo. Modeling Clones Evolution Through Time Series. In Proc. IEEE Intl. Conf. on Software Maintenance 2001(ICSM 2001). Pp. 273–280. Fiorence, Italy, Nov 2001. [BCR94] V. R. Basili, G. Caldiera, D. H. Rombach. The Goal Question Metric Approach. In En- cyclopedia of Software Engineering. Pp. 528–532. John Wiley & Sons, 1994. See also http://sdqweb.ipd.uka.de/wiki/GQM. [CAH03a] K. Crowston, H. Annabi, J. Howison. Defining Open Source Software Project Success. In Proceedings of ICIS 2003. Seattle, Washington, USA, Dec. 2003. [CAH03b] K. Crowston, H. Annabi, J. Howison. Defining open source software project success. In ICIS 2003. Proceedings of International Conference on Information Systems. 2003. [Cap03] A. Capiluppi. Models for the Evolution of OS Projects. In Proceedings of ICSM 2003. Pp. 65– 74. Amsterdam, Netherlands, 2003. [CCP07] G. Canfora, L. Cerulo, M. D. Penta. Identifying Changed Source Code Lines from Version Repositories. Mining Software Repositories 0:14, 2007. [CM07] A. Capiluppi, M. Michlmayr. From the Cathedral to the Bazaar: An Empirical Study of the Lifecycle of Volunteer Community Projects. In Feller et al. (eds.), Open Source Development, Adoption and Innovation. Pp. 31–44. Springer, 2007. [ES07] R. English, C. Schweik. Identifying Success and Tragedy of FLOSS Commons: A Prelimi- nary Classification of Sourceforge.net Projects. In Proceedings of the 1st International Work- shop on Emerging Trends in FLOSS Research and Development. Minneapolis, MN, 2007.

Proc. Software Evolution 2007 12 / 13 ECEASST

[FFH+02] J. Feller, B. Fitzgerald, F. Hecker, S. Hissam, K. Lakhani, A. van der Hoek (eds.). Character- izing the OSS process. ACM, 2002. [Ger04] D. M. German. Using software trails to reconstruct the evolution of software. Journal of Software Maintenance and Evolution: Research and Practice 16(6):367–384, 2004. [HG05] A. Hindle, D. M. German. SCQL: a formal model and a query language for source control repositories. SIGSOFT Softw. Eng. Notes 30(4):1–5, 2005. [LHMI07] S. Livieri, Y. Higo, M. Matushita, K. Inoue. Very-Large Scale Code Clone Analysis and Visualization of Open Source Programs Using Distributed CCFinder: D-CCFinder. In ICSE ’07: Proceedings of the 29th International Conference on Software Engineering. Pp. 106– 115. IEEE Computer Society, Washington, DC, USA, 2007. [LRW+97] M. M. Lehman, J. F. Ramil, P. D. Wernick, D. E. Perry, W. M. Turski. Metrics and Laws of Software Evolution—The Nineties View. In El Eman and Madhavji (eds.), Elements of Software Process Assessment and Improvement. Pp. 20–32. IEEE CS Press, Albuquerque, New Mexico, 5–7 Nov. 1997. [MFH02] A. Mockus, R. T. Fielding, J. Herbsleb. Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology 11(3):309–346, 2002. [RG05] A. Rainer, S. Gale. Evaluating the Quality and Quantity of Data on Open Source Software Projects. In Feller et al. (eds.), First International Conference on Open Source Systems. 2005. [RG06] G. Robles, J. M. Gonzlez-Barahona. Contributor Turnover in Libre Software Projects. In Damiani et al. (eds.), OSS. IFIP 203, pp. 273–286. Springer, 2006. [RKG04] G. Robles, S. Koch, J. M. Gonzalez-Barahona.´ Remote analysis and measurement of libre software systems by means of the CVSAnalY tool. In Proceedings of the 2nd ICSE Workshop on Remote Analysis and Measurement of Software Systems (RAMSS ’04). 26th International Conference on Software Engineering. Edinburgh, UK, May 2004. [SA02] K. J. Stewart, T. Ammeter. An Exploratory Study of Factors Inﬂuencing the Level of Vi- tality and Popularity of Open Source Projects. In ICIS 2002. Proceedings of International Conference on Information Systems 2002. 2002. [SAOB02] I. Stamelos, L. Angelis, A. Oikonomou, G. L. Bleris. Code Quality Analysis in Open-Source Software Development. Information Systems Journal 12(1):43–60, 2002. [SM04] A. Senyard, M. Michlmayr. How to Have a Successful Free Software Project. In Proceedings of the 11th Asia-Paciﬁc Software Engineering Conference. Pp. 84–91. Busan, Korea, 2004. [Wei05] D. Weiss. Measuring Success of Open Source Projects Using Web Search Engines. In Scotto and Succi (eds.), Proceedings of The First International Conference on Open Source Systems (OSS 2005), Genova, Italy. Pp. 93–99. 2005.

13 / 13 Volume X (2007)

ECEASST

A Requirements-Based Taxonomy of Software Product Line Evolution

Klaus Schmid, Holger Eichelberger

Software Systems Engineering. Universität Hildesheim Marienburger Platz 22, D-31141 Hildesheim {schmid, eichelberger}@sse.uni-hildesheim.de

Abstract: Software product lines are, by their very nature, complex software systems. Due to the interconnectedness of the various products in the product line any form of evolution becomes significantly more complex than in a single system situation. So far most work on product line evolution focused on specific approaches to supporting special cases of the evolution problem. In this paper, we take a different approach and provide a broad taxonomy of requirements-driven evolution in software product lines. This serves as a basis for the identification of requirements on evolution support.

Keywords: Software Product Lines, Evolution, Traceability, Requirements

1 Introduction Software product line (SPL) engineering [CN02, LSR07] is an important approach to the efficient development of large numbers of software systems that promises major improvements in terms of time, costs, and quality based on large-scale reuse. Experience shows that product development costs can be reduced by 80% and that cost of quality can be improved by 50% [LSR07]. However, as a result, the various products in a SPL become interconnected: they share various assets and any change that is relevant to one product may actually have ramifications for several other products due to the product interdependencies. This range of shared assets is also called the product line infrastructure and covers the whole range of product development starting from requirements through implementation and up to test assets. As a consequence of the interconnection of the various product developments by the product line infrastructure, adequate support for SPL evolution is very important. The evolution problem is further magnified as a SPL needs to integrate all the changes relevant to any product it supports and that the SPL as a whole is usually much longer lived than an individual product [SV02]. The combination of these issues leads to a situation where the evolution problem is much more severe than in single system development. While classical treatment of software evolution prefers the categorization of perfective, corrective, and adaptive maintenance [Hat07] (sometimes also preventive), we will focus here on requirements-driven evolution, i.e., those SPL evolution tasks, that can arise in a SPL context based on new or changed requirements, e.g., driven by new products that need to be supported. Usually, these belong to the categories of perfective or adaptive maintenance. In this paper, we will focus on a requirements perspective of evolution. Thus, we will in particular refrain from addressing issues of refactoring the product line infrastructure.

2 / 10 Volume X (2007)

Software Product Line Evolution

The background for our approach is our interest in identifying key requirements that future product line engineering tools, especially requirements engineering tools, will need to support in order to give adequate support for product line evolution.

In the next section, we will discuss related work from the area of evolution in general and from the area of SPL evolution in particular. In section 3, we will introduce a basic terminology for SPL and provide a high level discussion of different possible situations for product line evolution. This will be the basis for our refined discussion in section 4, where we will summarize our requirements for evolution support for SPL. Finally, in section 5 we will conclude.

2 Related Work In single system development evolution scenarios are typically categorized as perfective, corrective, and adaptive maintenance [Hat07]. There is a considerable amount of work on the classification of evolution of individual artifacts, e.g. for • requirements (clarification, retraction, splitting and merging) [PT93]. • scenarios in the sense of use cases [BSB05]. Several static relationships like contained in, or precondition of between scenarios as well as dynamic operations on scenarios were identified. Some inter-scenario operations are split into others, specialization, extension, consolidation and some intra-scenario operations are inclusion, modification and deletion. • goals in requirements engineering [RSE04] • design diagrams like the taxonomy of changes for UML diagrams in [BLO03]. • source code, like [Gus03] or [MCS05] from the viewpoint of traceability links. An approach to the evolution of architectures, which relies on various types of traceability links, was given in [MRP06]. Existing work on evolution of SPL can be structured into domain, artifact / feature and architecture evolution and combinations of these categories. On domain level, the domain evolution problem [DLS05, MSG96] arises, i.e. when existing PLAs are extended and/or refactored, unanticipated requirements may occur or changes of the architecture to improve the current customer satisfaction must be considered. In [MGN05], the general evolution of domain concepts was classified as vertical, domain-specific evolution (i.e. extension by new features) and horizontal evolution of the domain assets (e.g. for improving application functionality). Also a case for collaborative evolution of domains was introduced, i.e. when federated development of partner domains is done. On artifact level, migration of artifacts between the core asset base and concrete products in a SPL can be described using the evolution tree model known from single system development [ST00]. The evolution of features, variation points and dependent artifacts in terms of basic change operations (addition, deletion and modification) was described in [Myl01]. The evolution of product feature maps was discussed in [HHS05]. Feature models can also be used as a basis for describing evolution in requirements, design and implementation [Rie04]. For the SPL architecture level, in [SB99] a taxonomy for evolution was given as follows: requirements changes (like decision for a new SPL, improvement of functionality or quality attributes), architectural evolution (e.g. split of a SPL) and component evolution.

Proc. Software Evolution 2007 3 / 10

ECEASST

Probably the approach which is closest to ours was presented in the context of the ConIPF methodology [HWK+06]. There, addition, deletion, and modification of artifacts are explicitly used as a basic categorization. Each category was then further separated according to individual artifacts. While the various descriptions of product line evolution provided significant contributions, none so far provided a consistent categorization of product line change on all three levels: ranging from individual requirements over products to product lines. In the next three sections we will discuss each of these levels in detail.

3 Evolution Categories In this section, we introduce the basic categories of our taxonomy. Roughly, requirements- driven evolution can result in changes on three levels: • Requirements level change – change to an individual requirement (or small group of requirements). • Product level change – change in terms of products that must be supported. • Product line level change – change to whole groups of products that must be supported. As a basis for our discussion we will categorize requirements of a product in a SPL in three categories: • Commonalities – requirements that are common to all products in the SPL. • Variabilities –requirements that are not common for all products, but there are systematic variations among the products, i.e., a variability is usually relevant to multiple products. • Product-Specific – these are requirements that are relevant only to an individual product. In general, the various products will include requirements from all three categories, i.e., the resulting set of requirements will usually be composed of commonalities + selected variabilities + product-specific requirements. The product line infrastructure (i.e., the reusable artifacts) will contain only commonalities (including the implementation) and any variabilities. The product-specific parts (requirements and implementation) are only regarded as part of the products. As the basis for our analysis, we also need to make certain assumptions, regarding the way variability in software product lines is modeled. Here, we base our terminology on a decision- based framework similar to the one described in [SJ04], however, our results can be easily transferred to feature tree based modeling approaches like [CCKK06]. In particular, we will distinguish between a variability (e.g., an alternative) and a variability resolution (e.g., a specific case in an alternative). Further, we will denote the usage of a specific alternative in a context as a variability usage. Individual variabilities may be related by means of constraints. As described above, we should differentiate changes on the levels of individual requirements, changes on the level of products and on the level of product lines as a whole. Roughly, the different changes can be subdivided into addition, modification, and deletion. In the remainder of this section, we will structure our discussion according to these categories.

4 / 10 Volume X (2007)

Software Product Line Evolution

3.1 Requirements Level Changes These changes can be categorized as adding, deleting or modifying individual requirements (or groups of requirements). Below, we further discuss their implications • Adding requirements – adding requirements can happen any of the levels: product- specific, variability addition, or commonality. While the product specific addition has no ramifications on other products or the product line infrastructure (except for the fact that the addition must be conformant to restrictions of the product line infrastructure), the addition of a variability commonality will impact the product line infrastructure and thus have ramifications on other products as well. • Deleting requirements – again this can happen on any of the levels: product-specific, variability, or commonality. For product-specific requirements there are no ramifications for further products. Variability and commonality deletions have effects on the product line infrastructure. Commonalities and variabilities that are relevant to other products also have an impact on these other products. • Modifying requirements – modifying requirements can happen on any of the levels: product-specific, variability, or commonality. In particular, a modification may change the category of the requirement as shown in [BCM+03]. o Product-specific modifications can lead to a mere modification of content or can also change a requirement into a variability. o Variability modifications can change a variability into a commonality or a product-specific requirement. In particular, it needs to be determined what happens to other products that share the variability: the change may affect either all products in the same manner or it may affect only some products, for example, leading to the introduction of an additional variability resolution. Particular forms of variability modifications are that the relevant constraints are modified or that attributes of the variability like its binding time are modified. o Commonality modifications. Again this may either impact the commonality per se, changing it for all products. Or it may affect only some, and thus may turn the commonality into a variability.

An overview of these types of changes is given in Figure 2. Some changes may also modify the type of requirement in terms of commonality, variability, and product-specific. In Figure 2 the boxes represent the SPL requirement categories as introduced in section 3. The arrows visualize the intent of the change to a requirement, e.g. to make a product-specific requirement more generic and thereby to turn it into a variability. Furthermore, the arrows denote the impact in terms of the number of products affected by changing a requirement

3.2 Product-Level Change Product-level changes describe additions and deletions of whole products. Modifications of individual products can be described as requirements-level change. As defined in [HSH06], there is a need to distinguish between the marketed and the engineered product line in product line engineering. A marketed product line denotes a set of products that are marketed together as sharing a common set of features, whereby different products often substitute each other (e.g. different versions of the Windows operating system). An engineered product line is

Proc. Software Evolution 2007 5 / 10

ECEASST

product-local change

Product-specific specific generic make make t impact on individual products n y e it il m b impact on multiple products g a u ri a a v Variability e impact on all products e g im common variable n t make make a g m h n od c i co ify d nstr in aints b

Commonality

modify commonality Figure 2: Summary of Requirements-Level Changes.. designed and developed for and with reuse in order to share major parts of the implementation. Conversely, different products in an engineered product line may belong to different marketed product lines (e.g. navigation systems of one producer may be sold under different brands). Here, we focus on the engineered product line only. • Adding a product – this will require the definition of the selected variabilities and of product-specific concerns. Thus, this only establishes uses relations for the various variabilities (and commonalities). • Deleting a product – this will lead to the deletion of the corresponding product- specific requirements. Usually the variabilities remain in existence in the product line infrastructure, even if they are no longer used. Modifying a product directly maps to modifying requirements as discussed above.

3.3 Product-Line-Level Change A complex product portfolio is sometimes represented in terms of a number of product lines. These product lines can be either independent in the sense that they do not explicitly share any product line level assets or they can be structured in the sense that they share some assets. The later is sometimes also called a product population [vO05]. As a consequence, we can distinguish the following cases as a refinement of the product / product line operations that were defined in the context of [BCM+03]: • Adding a product line – a new product is established. This may either be a completely new and independent product line or it is a sub product line in the sense of a product population as defined above. In the later case, there is a relation between the sub product line and the upper level product line, which is similar to the relation between an individual product and its product line.

6 / 10 Volume X (2007)

Software Product Line Evolution

• Removing a product line – the product line is removed. Again this can be subdivided into the cases that either an independent product line or a product line as a sub product line of a product population is removed. • Merging two product lines – sometimes it is relevant to merge different product lines (e.g., in the case of an acquisition, or if they become increasingly similar over time). • Splitting a product line – the opposite operation is the split of a product line. This may either lead to two independent product lines or it leads to two product lines, which are part of a product population. In fact, this case can be handled by moving the appropriate product-specific elements into the target SPL while variabilities and commonalities are simply duplicated.

4 Requirements for Evolution Support of Software Product Lines In the preceding sections we discussed thoroughly the different possible situations that may occur in product line evolution. Now, we will turn to the core of our paper and will build on this taxonomy and derive certain requirements on evolution support. The underlying assumption is that using a systematic characterization of changes provides a higher potential of achieving a complete and consistent set of evolution support requirements than an ad-hoc approach does. In the following table, we will summarize major operators that must be supported for product line evolution. In addition, the table describes traceability relations that are relevant to supporting the described operations and go beyond the usual relationships in single system development.

Situation Evolution Operator Traceability Information Requirements Level Add Add product-specific requirement --- Requirement Add new variability relation between product and infrastructure Add new resolution in existing relation to other variability resolutions; variability relation between product and infrastructure Add new commonality relation between product and infrastructure Modify Modify content of product- --- Requirement specific requirement Modify content of variability for relation to other variability resolutions; some products (either introduces relation between product and infrastructure additional resolutions or introduces product-specifics) Modify content of variability for relation between product and infrastructure; all products relation to usage of this variability resolution Modify variability constraints relation to usage of variability

Proc. Software Evolution 2007 7 / 10

ECEASST

Modify variability properties relation to usage of variability (e.g., binding time) Delete Delete product-specific --- Requirement requirement Delete variability relation to usage of variability Delete variability resolution relation to usage of variability resolution Product Level Add Product Add a product relation to commonalities and selected variability resolutions relation between product and product- specific requirements Delete Delete a product relation to commonalities and selected Product variability resolutions relation between product and product- specific requirements Product line Level Adding a Add an independent product line --- product line Add a sub product line relation to commonalities and selected variability resolutions (of higher level SPL) relation of product line to specific commonalities and variabilities Removing a Remove a product line --- product line Remove a sub product line relation to commonalities and selected variability resolutions (of higher level SPL) relation of product line to specific commonalities and variabilities Merging two Merge two independent product ---1 product lines lines Merging two sub product lines relation to commonalities and selected variability resolutions (of higher level SPL) Splitting a Split product line relation to commonalities and selected product line variability resolutions (of higher level SPL)

1 While traceability information among the different product lines would be very useful for merging, we cannot assume that it exists, as by definition these are independent product lines.

8 / 10 Volume X (2007)

Software Product Line Evolution

As a result of the above discussion, we believe, we can provide a theoretically more sound analysis of the required operations and traceability relations that a requirements-based product line environment shall support. • The various change operators identified above shall be supported. In particular, the nesting of these operators shall be respected and correspondingly supported. • In particular, traceability among the usages in different products and between products and infrastructure should be supported. • In addition it would be useful to be able to work with multiple versions of a variability model in order to enable products to rely on different versions and defer update of products till an appropriate time. • Changes in variability constraints should be identifiable with respect to their impacts. • Changes in terms of additional attributes shall be supported (e.g., binding time). • The difference between requirement and realization (e.g., required binding time vs. established binding time) shall be represented.

5 Discussion We provided a systematic discussion of different product line evolution operations from the viewpoint of requirements engineering. A taxonomy of evolution operations was given, which was structured into requirements-level, product-level and product-line level changes. Based on the discussion in this paper, we outlined the traceability information influenced by the individual evolution operations and derived a set of requirements to be fulfilled by a product line environment in order to support the systematic evolution of SPL. To our knowledge, so far no support has been provided which is in accordance with all these requirements. We thus stipulate that the presented taxonomy can be used as a reference for product line evolution support. Some interesting issues for further research are: to realize a prototypical product line environment for the systematic support of evolution that supports the operations and requirements outlined above, to validate the taxonomy and its completeness by applying the environment and the proposed evaluation operations and to evaluate SPL case studies e.g. to derive the frequency of occurrence of the individual evolution operations of our taxonomy. References [BCM+03] G. Böckle, P. Clements, J. McGregor, D. Muthig, and K. Schmid. A Cost Model for Software Product Lines. In Proceedings of the 5th International Workshop on Product Family Engineering (PFE’5), number 3014 in LNCS, pages 310–316. Springer, 2003. [BLO03] L. C. Briand, Y. Labiche, and L. O'Sullivan. Impact Analysis and Change Management of UML Models. In Proceedings of Software Maintenance 2003, IEEE Conference on Software Maintenance, pages 256– 265. IEEE, IEEE Computer Society, September 2003. [BSB05] K. K. Breitman, J. Cesar Sampaio do Prado Leite, and D. M. Berry. Supporting scenario evolution. Requirements Engineering, 10(2):112–131, 2005. [CCKK06] K. Czarnecki, H. Chang, P. Kim, and K. Kalleberg. Feature models are views on ontologies. In Software Product Line Conference, 2006 10th International, pages 41–51, 21-24 Aug. 2006. [CN02] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley, Boston, MA, 2002.

Proc. Software Evolution 2007 9 / 10

ECEASST

[DLS05] G. Deng, G. Lenz, and D. C. Schmidt. Addressing Domain Evolution Challenges in Model-Driven Software Product-line Architectures. In Proceedings of the ACE/IEEE MoDELS 2005 Workshop on MDD for Software Product-lines: Fact or Fiction?, October 2, 2005, Jamaica, pages 247–261, October 2005. [Gus03] J. Gustavsson. A Classification of Unanticipated Runtime Software Changes in Java. In Proceedings of Software Maintenance 2003, IEEE Conference on Software Maintenance, pages 4–12. IEEE, IEEE Computer Society, 2003. [Hat07] L. Hatton. How Accurately Do Engineers Predict Software Maintenance Tasks? IEEE Computer, 40(2):64–69, February 2007. [HHS05] A. Helferich, G. Herzwurm, and S. Schockert. Developing Portfolios of Enterprise Applications using Software Product Lines. In Turowski and Zaha [TZ05], pages 71–85. [HSH06] A. Helferich, K. Schmid, and G. Herzwurm. Reconciling Marketed and Engineered Software Product Lines. In Proceedings of the 10th International Software Product Line Conference, pages 23–27, 2006. [HWK+06] L. Hotz, K. Wolter, T. Krebs, S. Deelstra, M. Sinnema, J. Nijhuis, and J. MacGregor. Configuration in Industrial Product Families - The ConIPF Methodology. Akademische Verlagsgesellschaft Aka, Berlin, 2006. [LSR07] F. van der Linden, K. Schmid, and E. Rommes. Software Product Lines in Action - The Best Industrial Practice in Product Line Engineering. Springer, 2007. http://www.spl-book.net/. [MCS05] J. I. Maletic, M. L. Collard, and B. Simoes. An XML Based Approach to Support the Evolution of Model- to-Model Traceability Links. In Proceedings of TEFSE 2005, November 8, 2005, Long Beach, California, USA, 2005. [MGN05]J. Meinecke, M. Gaedke, and M. Nussbaumer. A Web Engineering Approach to Model the Architecture of Inter-Organizational Applications. In Turowski and Zaha [TZ05], pages 125–137. [MRP06] P. Mäder, M. Riebisch, and I. Philippow. Aufrechterhaltung von Traceability Links während evolutionärer Softwareentwicklung. Softwaretechnik-Trends, 26(3):89–90, May 2006. Proceedings 8. Workshop Software-Reengineering, Bad-Honnef May 3-5, 2006. [MSG96] R. R. Macala, L. D. Stuckey Jr., and D. C. Gross. Managing Domain-Specific, Product-Line Development. IEEE Software, 14(13):57–67, May 1996. [Myl01] T. Myllymäki. Variability Management in Software Product Lines. Technical report, Tampere University of Technology, Software Systems Laboratory, 2001. [PT93] C. Potts and K. Takahashi. An active hypertext model for system requirements. In J. C. Wileden, editor, Proceedings of the 7th International Workshop on Software Specification and Design, pages 62––68. IEEE Computer Society, December 1993. [Rie04] M. Riebisch. Supporting Evolutionary Development by Feature Models and Traceability Links. In Proceedings 11th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS2004), Brno, Czech Republic, May 24-26, 2004, pages 370–377, 2004. [RSE04] C. Rolland, C. Salinesi, and A. Etien. Eliciting Gaps in Requirements Change. Requirements Engineering Journal, 9:1–15, 2004. [SB99] M. Svahnberg and J. Bosch. Evolution in Software Product Lines. Journal of Software Maintenance, 11(6):391–422, 1999. [SJ04] K. Schmid and I. John. A Customizable Approach to Full Lifecycle Variability Management. Science of Computer Programming, 53(3):259–284, 2004. [ST00] S. Schach and A. Tomer. Development/Maintenance/Reuse: Software Evolution in Product Lines. In P. Donohoe, editor, The Israeli Workshop on Programming Languages & Development Environments Organized by IBM Haifa Research Lab, Haifa University, Israel, July 1, pages 437–450. Kluwer, 2000. [SV02] K. Schmid and M. Verlage. The Economic Impact of Product Line Adoption and Evolution. IEEE Software, 19(6):50–57, 2002. [TZ05] K. Turowski and J. M. Zaha, editors. Component-Oriented Enterprise Applications, Lecture Notes in Informatics, 2005. [vO05] R. van Ommering. Software reuse in product populations. Software Engineering, IEEE Transactions on, 31(7):537–550, July 2005.

10 / 10 Volume X (2007)

Supporting Model-Based Iterative Software Development

László Angyal, László Lengyel and Hassan Charaf

Budapest University of Technology and Economics {angyal, lengyel, hassan}@aut.bme.hu

Abstract: The orientation of the current software development practice requires efficient model-based iterative solutions. The high costs of maintenance and evolution during the life cycle of the software can be reduced by using tool-aided iterative development. This paper presents how model-based iterative software development can be supported through efficient model-code change propagation. The presented approach facilitates bi-directional synchronization between the modified source code and the refined initial models. The backgrounds of the synchronization technique are three-way abstract syntax tree (AST) differencing and merging. The AST-based solution enables syntactically correct merge operations. OMG's Model-Driven Architecture describes a proposal for platform-specific model creation and source code generation. We extend this vision with the synchronization feature to assist the iterative development. Furthermore, a case study is also provided.

Keywords: MDA, MIC, Model-Based Iterative Development, Three-Way AST Differencing, AST Merging. 1 Introduction The current model-based development approaches emphasize the use of models at all stages of software development. Models are used to describe all artifacts of the system, i.e., user interfaces, interactions, and properties of all the components that comprise the system. The MDA [1] approach separates the platform-independent application specification from the platform-dependent constructs and assumptions. A complete MDA application consists of a definitive platform-independent model (PIM) and one or more platform-specific models (PSM) on those platforms that the application developer decides to support. The platform- independent artifacts are mainly Unified Modeling Language (UML) [2] and other software models containing enough specification to generate the platform-dependent artifacts automatically by model compilers. UML is a widespread general purpose modeling language that is too general to support efficient source code generation. Closely focusing on a specific problem domain, domain-specific languages (DSL) cover a narrow domain-specific area in a high abstraction level. Therefore, greater part of the source code generation can be covered by domain-specific model processors. Model-Integrated Computing (MIC) [3] provides a framework for software production using both metamodeling environments and model interpreters. The domain-specific concepts of MIC are similar to MDA. MIC supports the flexible creation of modeling environments by metamodeling basics, and helps tracking the changes of the models. Using MIC technique the domain-specific models can be converted into another format such as executable code. One of the most important challenges of model-based development is round-trip engineering [4]. Almost every existing modeling tool supports generating the code skeletons,

Proc. Software Evolution 2007 1 / 10

ECEASST and synchronizing of the skeleton with the models. However, it is insufficient in most cases. Usually, the generated source code does not contain enough logic to be used effectively without further manual programming. The current reverse engineering tools mostly focus on the inter-procedural calls or pattern recognition, and there is lack of tool support for the statement-level handling of method bodies, but it is also important. The method bodies cannot be supported without the comprehension of their logic. Textual-based solutions are unable to extract enough information, therefore an AST-based approach is required. In order to support model-driven iterative development, software models and the source code should be kept synchronized. This work provides a three-way AST difference analysis and merge-based software model-code synchronization solution. The remainder of the paper is organized as follows. The next section discusses the motivation. Section 3 provides background information and related work, Section 4 describes our model-code synchronization approach and a concrete platform-specific solution with a case study. Finally, conclusions and future work are elaborated. 2 Motivation Our motivation is to support automatic, iterative application generation and synchronization with the same platform-independent model set for different platforms, e.g. for different mobile phone platforms (Fig. 1). The model space consists Model space Code space of the platform-independent class mobile { public int i; public void e{ models (PIMs) and the Model System.out... Java Sync 1 } platform-specific models transformation 1 } (PSMs). The PIMs are Java composed of static resource class mobile { public: void e{ and other dynamic models Resource diagram Model c out<<“ax” Symbian Sync 2 } transformation 2 } (Fig. 1), which describe the State 2 State 1 State 4 C++ user interface and the State 3 Dynamic diagrams behaviour of the application. class mobile { public int i; public void e{ Windows A PSM represents a concrete Model Console.Wr... Sync 3 } Mobile implementation of the PIMs transformation 3 } in a selected platform. C# Several development PIMs PSMs Source code platforms are available for mobile phones e.g. Symbian Abstraction level [5], Java [6], Windows Fig. 1. Motivation principles Mobile [7]. Generally, any PSMs can be produced from the PIM using graph rewriting-based [8] model transformations. PSMs are constructed to facilitate source code generation. Visual Modeling and Transformation System (VMTS) [9] is an n-layer metamodeling environment which supports visual editing of models according to their metamodels, and allows specifying Object Constraint Language (OCL) constraints in model transformation rules. Both the models and the transformation rules are represented internally as directed, labeled graphs. Also, VMTS is a model transformation system, which transforms models using graph rewriting techniques and supports code generation from models.

2 / 10 Volume X (2007)

Supporting Model-Based Iterative Software Development

The relations between the AST elements can be considered the metamodel of the language and its instance model as a concrete AST of a source code that is written in that language. According to [10], an AST metamodel is powerful, because the manipulation of programs became universal. The regeneration of the code from an AST model is possible via model traversal and parsed source code can be stored in that model. Thus, choosing an AST model as PSM can be advantageous. Both PIMs and the source files generated from the PSMs can be modified by the developers. The model and the source code are modified independently of each other over the time. To solve the synchronization problem, this paper introduces how VMTS supports model- based iterative software development. In order to avoid the error-prone manual change propagation, the synchronization feature between these states is essential. The bi-directional non-destructive model-code change propagation enables iterative and incremental software development (IISD). The non- destructive way means that the previously committed changes in both sides will be saved. The whole development process can be split into iterations instead of sequential phases. After each iteration, developers have executable software to use and to draw conclusions from it, and to incorporate the observations into the next iteration of the project. Fig. 2 depicts a typical scenario of IISD. In the beginning of the first iteration, we generate code from a model. The development Original source affects both the model and the code. code Initial generation At the end of each iteration, before the manual Model modification start of the next one, we should bring Initial state the model and the code into a First iteration manual User updated consistent state. modification source code In model-driven iterative development the synchronization Updated bi-directional non-destructive Model synchronization between PSMs and source code should be supported. Due to the incremental Model and code are consistent synchronization, the model is always Second iteration up to date, developers can choose Updated bi-directional non-destructive between further source code synchronization Model modifications and additional model User updated refinements. This paper describes a source code possible solution to model-based IISD. Fig. 2. Iterative model-based development 3 Backgrounds and Related Work Considerable research was conducted in the subject of source code differencing and merging in the past 30 years. Software development projects are typically based on teamwork, where the team mates work on many kinds of common files. The methods of the source code comparing and merging were and will always be an actual problem. The comparison of two files as sequences is originated in string operations, like finding the longest common subsequence (LCS) [11] or the longest common substring [12]. The two algorithms cover different matching approaches. The traditional file comparing tools usually use modified versions of the longest common subsequence searching algorithms. The difference analysis of two strings ( S1, S2) or trees ( T1, T2) produces an edit script [11]. An edit script contains the operations needed to transform S1 into S2 or T1 into T2. The analysis

Proc. Software Evolution 2007 3 / 10

ECEASST first matches the common parts then generates the script that contains as few operations as possible. For example, the popular UNIX diff utility [13] finds the longest common subsequence of the lines of the two files, then creates a sequence of insert and delete operations. Diff works well on general text files, but in several cases when differencing source code files, diff can produce useless edit scripts, because diff does not know the speciality of the programming languages. To compare two pieces of source code correctly, the algorithm must take the grammar of the language into consideration. These algorithms work on the parse trees of the files and use different approaches. Hierarchical structures such as trees cannot be handled as such simple sequences. [14] provides an algorithm for change detection in hierarchically structured information that has linear time complexity. This approach is supposed to be used on ordered trees with large amount of data. FastMatch and EditScript algorithms are provided for the two sub- problems of the change detection problem. The FastMatch uses some heuristic solutions e.g. equality comparison of two labeled nodes containing a value for computing the unique maximal matching. The algorithm EditScript supports the insert/delete/update and the complementary move operations. The improved versions [15] of these algorithms work on unordered trees and allow copy/glue operations, as well. Merge performs reconcile of changes in some revisions of a software artifact. Distinction can be made between the numbers of artifacts e.g. files processed by the merge. Two-way merge works on two revisions ( A1 and A2) of the same software artifact. Typically this is error- prone and requires human intervention and verification, therefore, this technique is rarely used in practice. According to the three-way merge approach, the common ancestor ( A0) of two modified artifacts ( A1 and A2) is used, to detect and resolve more conflicts, e.g. two-way merge is unable to distinguish insert and delete. A three-way merge is performed after difference analysis between A1 and A2, which takes account of A0. This approach is the most reliable in practice. The three-way comparison with automatic conflict resolution allows automated merge. The most known tool that uses three-way merge approach is diff3 [16]. Further information can be found about other software merging techniques in [17]. Merge tools that work on parse trees have to output the reconciled source code from the tree. Pretty-printing [18] is a technique that makes an internal structure human readable. It traverses the parse tree and visits every node while printing the output. It facilitates the source code generation from an AST. The tokens belonging to the nodes are printed in order. The inserted white spaces and blank lines make the output pretty. It is also known as code beautifier, which makes a code well-indented. Many papers have been written in the issue of three-way merging of trees. We summarize some of the closely related results. There are several model related general merge approaches that significantly differs from ours, therefore these are not listed bellow. [19] addresses the conflicts during three-way merge of hierarchically structured documents. The possible eleven combinations of operations on the pairs of child nodes during merge are enumerated. 3DM [20] and DeltaXML [21] are tools for performing differencing and three- way merging of XML files. 3DM applies heuristic tree matching between trees. This performs node similarity measurements i.e. content similarity and child list similarity when no exact matches exist. The tree matching of DeltaXML uses an optimized longest common subsequence (LCS) algorithm, which matches the nodes at each level on the trees, and then the differences are reconciled.

4 / 10 Volume X (2007)

Supporting Model-Based Iterative Software Development

Syntactic merge techniques using trees or graphs as underlying data structure. [22] proposes a program merging system that consist of a syntax-based comparator, a synchronous pretty-printer, and a merging editor. The synchronous print traverses the trees that is previously matched by the comparator, and produces an intermediate merged file that can be edited further with the merging editor, the differences are coloured in the editor to the user can verify the merge. There is an other interesting approach in [23], where a graph-based software merging using a category theory approach is presented. The proposed approach does not depend on any specific programming language. The programs are represented as graphs and the approach uses categorical formalisms. The novelty of this work is the combination of three-way tree differencing, edit script controlled tree patching (merge) and model-driven development approach to achieve the synchronization of the model and code spaces. Most of the tools and cutting edge researches in the field of synchronization focus on differencing and merging between the same kinds of artifacts (mostly source code). 4 Contributions First of all, in this section, a novel PSM-code synchronization approach is elaborated, that can perform an automated syntactically correct three-way merge. That is followed by a concrete platform-dependent solution of VMTS with a case study.

4.1 The General Synchronization Method The synchronization method depicted in Fig. 3 is based on AST differencing. The files containing the source code ( S0, S 1) are parsed into ASTs. In the model space the PSM ( M1) describes the implementation in a concrete platform. The PIMs and PSMs are stored in the model database, but Fig. 3 represents only the PSMs. In our case the PSM is an AST model that can contain directly the AST representation of the platform-specific code. This makes easier to match and then merge the two different representations.

In-memory AST node AST of the last A Last synchronized common ancestor 0 AST model class mobile { M0 AST node in model public int i; p0 public void e{ Console.Wr... Parser } } S0

m0 y Last Common f d d1 odi ancestor 0 Diff M Diff m Modify 1

class mobile { public int i; A public void e{ 1 Console.Wr... Parser } M } p 1 S1 1 Modified AST Refined AST model Modified code rge m Me

class mobile { public int i; p2 public void e{ Console.Wr... Pretty } Printer A2 M2 } S2 Next synchronized AST model Synchronized code Next synchronized AST

Code space Model space (database) Fig. 3. Block diagram of the model-code synchronization

Proc. Software Evolution 2007 5 / 10

ECEASST

The following method is based upon the assumption that the structure of the PSM and the AST built by the parser are conformable or at least very similar. Obviously, the complex AST model (PSM), which is based on model containment hierarchy, is not editable directly by the developer. Due to the large number of nodes and the absence of the layout it is nearly impossible to visualize it. PSMs that contain AST representation are modified indirectly via model transformations or model-code synchronization. Our solution uses three-way approach starting from the persistently stored artifacts ( S0, S 1, M 1). The four phases of our synchronization method are (i) the auxiliary tree building phase, (ii) the edit script generation phase applying tree differencing, (iii) edit script transformation phase, and finally (iv) the three-way tree merge phase. The last synchronized AST model ( M0) is logically equal to the common ancestor ( S0) that reflects the last synchronization state. It is important that both of them contain the same implementation state, but in different representations. Both the model and the code can be edited independently and the synchronization means change propagation between them. The resulting artifacts of the merge are S2, and M 2. The modified code ( S1) and the refined model ( M1) will be overwritten by the synchronized ones (S2 and M2). The others are temporary memory objects ( A0, A 1, A 2). AST of the last T A common ancestor 0 0 T ree d iff T d0 1 D d1 ng if In-memory ci fe en re auxiliary trees er nc iff in D ε ε g 1 2 INS DEL M1 A1 Modified AST Edit scripts Refined AST model Transform scripts a0 ε ' ε ' 2 1 Apply edit scripts a1 A M2 2 Syntactically equals Next Synchronized AST Next Synchronized AST model Fig. 4. The details of synchronization

The difference analysis ( d0, d 1) between the two modified software artifacts ( S1 and M 1) and the common ancestor ( S0) finds and identifies the applied edit operations. The source files (S0, S1) are parsed ( p0, p 1) into abstract syntax trees ( A0, A 1), and the PSM ( M1) is already an AST structure. The differencing ( d0, d 1) produces the merge instructions, which are used during the merge phase ( m). Then using the pretty-printing technique ( p2) source code ( S2) can be generated i.e. the in-memory AST is serialized. The model ( M2) is updated directly, no other operations are needed. In order to provide further details related to the presented method, Fig. 4 illustrates a detailed version of the synchronization process depicted in Fig. 3. Trees denoted by A0, A 1, A 2 are in the code space, while M1, M 2 are in the model space according to Fig 2, but T0, T 1 are temporary trees for helping the difference analysis.

6 / 10 Volume X (2007)

Supporting Model-Based Iterative Software Development

The first phase of the synchronization builds two auxiliary trees ( T0, T 1) from the two different representations of the implementation using the visitor pattern [24] and model traversal. In the second phase, the modifications made on the source code and the model refinements are identified, and edit scripts ( ε1 and ε2) are produced. The differencing algorithm (d0, d 1) works on the auxiliary trees, instead of comparing directly the AST in the memory and the PSM in the database. The homogeneous auxiliary tree representation is designed to fit the tree matching algorithm. The heterogeneous structure of an AST is difficult to traverse using a general algorithm, because the different types of nodes are not comparable. The advantage of this method is that it hides the concrete way of storage of the AST and model traversals: the differencing ( d0, d 1) and the edit script processing algorithms ( a0, a 1) are the same for arbitrary programming languages. Supported edit operations in our method are the following: (i) moving a subtree, (ii) insert, (iii) delete, and (iv) update a node, because they are the typical AST modification operations. Since the model representation is in a database, therefore, recognizing subtree movements can keep the number of executed row inserts/deletes low during the synchronization. A node update occurs e.g. when the name of a method or the return type is changed. Reordering two statements in a method body causes a subtree move operation. Each operation refers to exactly one tree node that is affected by the operation, which can be a root of a subtree, its parent node and its index, as well.

A merged edit script should be created from the two already existing scripts ( εm=ε1+ε2). This script could be executed later on the common ancestor ( A0) and the result is a synchronized AST that contains all modifications. In our case there is no representation of A0 in each space, since it is stored only as a file ( S0). Therefore, instead of using εm, we produce ′ ′ two transformed edit scripts ( ε1 and ε2 ) in order to execute them on the opposite side ( A1 or M1) to create the synchronized artifacts denoted by A2 and M2. This does not require storing the ancestors in both spaces, only a file in the code space. While transforming the edit scripts, it is important that the operations from different edit scripts can affect on each other. Since operations store positions, and inserting/deleting a node shifts the indices of the children of a parent node, positions should be maintained to be suitable for the application on the opposite AST. The conversion of the edit scripts (i) updates the positions of the contained operations if necessary, (ii) removes the overlapping delete operations and (iii) resolves the conflict between two edit operations. The conflict resolution needs labeling one side as master side. Since from the model-based development point of view the model representation is the more relevant, by default, models are the primary artifacts. After the script conversion, in the merge phase the updated edit scripts are applied to both sides, which performs the change propagations. In this approach the edit scripts are used as inputs by the merging algorithms to control the merge. The merge can be considered as tree ′ patching, it executes the modifications described by the edit operations. Formally, S2=S1+ε2 ′ and M2=M1+ε1 . The model in the database ( M2) and the AST in the memory ( A2) have to contain the same elements both syntactically and semantically. This synchronized state ( S2) is stored as a common ancestor for the next iteration. It is also important to remark that the synchronization should work with empty models or empty source files. For instance, if the model ( M2) is empty, the content can be built from scratch during the synchronization.

Proc. Software Evolution 2007 7 / 10

ECEASST

4.2 A Platform-Specific Solution One of the platforms supported by VMTS is Windows Mobile that solution is presented in Fig. 5. VMTS uses the CodeDOM technology [25] as a language independent model representation of the source code, and this means that the code generation is just a syntax tree composition. [26] introduces how VMTS generates source code using model transformation methods and CodeDOM metamodel. PIMs are transformed by model processors into CodeDOM instance models. The code generation technology of CodeDOM has several internal pretty-printers i.e. for C#, VB.NET, and C++ languages, but it can be extended to support other languages. We have created a demonstrative

class mobile { CodeDOM tree of implementation of the proposed public int i; public void e{ the common ancestor Console.Wr... C# Parser } approach. An open source C# parser } [27] is used, that is capable of building Common ancestor D iff C# file Diff CodeDOM object tree in memory from

class mobile { parsed code. The CodeDOM tree and public int i; Modified public void e{ Console.Wr... C# Parser CodeDOM tree the CodeDOM model (PSM) in the } } database are traversed and ordered, Refined CodeDOM Modified C# file model labeled trees are built from them, Synchronized Synchronized CodeDOM tree Merge CodeDOM model which are easy to process due to their class mobile { CodeDOM public int i; homogeneous structure. The labels of public void e{ Console.Wr... code generator } the nodes are the types of the AST } elements to help the matching. Synchronized C# source file The tree differencing and edit script Code space Model space computing are performed by the [14] Fig. 5. Synchronization in the Windows Mobile algorithm, because it was easy to platform implement and allows using heuristics (node similarity) during the matching. The edit scripts are transformed by our algorithm that works as mentioned previously. There are two different edit script execution units in the merger: one patches the CodeDOM object tree and the other handles the CodeDOM model in the database. These execution units are explicitly controlled by edit scripts. Reliability criterias of the merging approach are the followings: (i) all changes must be detected, (ii) all must be propagated to the other side, (iii) syntactical correctness is ensured, (iv) there are no compile errors after the merge i.e. semantical correctness, (v) model consistency remains (vi) program (business) logic is unharmed, (vii) proper conflict handling e.g. automatic decision making, overlapping changes, identical changes (duplication) detection and solution, reorder the newly inserted nodes. Criteria iv, vi and some of vii have not been addressed yet. General limitations of syntactical-based techniques are that they are unable to detect undeclared variables, since the code is still syntactically correct. Some object-oriented behaviour i.e. the dynamic binding cannot be resolved by only syntactical approaches [17]. We tried the synchronization on a source code, which was auto-generated by VMTS plugin [28] generator. The source file contained 2100 lines of code, 55 classes, its size was 104 kb, and the number of the tree elements affected by the differencing was above 7000. We made two copies of that file to create the common ancestor and the two revisions. Some changes were made to the revisions without making a conflict: a method body was removed and an extra class was added. The files and the edit scripts are available on VMTS web site [9]. Currently one file is generated directly from a PSM. All criteria have been satisfied.

8 / 10 Volume X (2007)

Supporting Model-Based Iterative Software Development

The drawback of reading source code into AST to manipulate is that the subsequent serializing looses the formatting and comments unless the parser, the pretty-printer and the AST take care of formatting information and comments. Although CodeDOM contains comment node, only namespace, class and class members nodes handles the comments. Fortunately the chosen parser reads the comments but stores them separately from the AST nodes. However, a complete synchronization approach should deal with the changes in the comments as well. This depends on the parsing technology and the design of the AST. CodeDOM has some other limitations; it does not support all of the language elements introduced by C#. Using code snippet nodes the need of the unsupported elements can be bypassed. It works well on files, which are generated from domain-specific models by VMTS. These limitations hardly reduce the applicability of our solution, because the model-driven development is mainly relies on the models and not on the generated code. The changes are typically performed in the model, but the developer has the opportunity to carefully modify the code, as well. 5 Conclusions and Future Work The presented synchronization involves structural model-code differencing and three-way tree merging. The main advantage is that in contrast to typical code generation approaches, it permits modifying the generated code and instead of losing the changes, they will be synchronized back to the models. The incremental approach is more effective and keeps the previous modifications within both sides. The modular design allows the model-model and in addition the code-code synchronization. CodeDOM models are applied as PSMs, which enables easy code generation. The illustrated method with some minor changes can be a solution to the synchronization challenge of other platforms as well. We separated the specific algorithms from the general ones, the differencing and the edit script transformation algorithms that contain the core logic of the synchronization are reusable. For instance, to support Java platform, a parser to Java language has to be written, which is capable of building CodeDOM tree in memory or a converter is required that creates CodeDOM tree from the AST of a Java source. Code generation for Java can be performed by the J# code provider [29] of CodeDOM. Obviously any other language dependent or independent code syntax scheme can be used as PSM instead of CodeDOM. VMTS facilitates effective modeling with easy domain-specific modeling language definition and the dependent customizable domain-specific visualization. The introduced model-code synchronization method affects not only the higher level parts of the classes i.e. methods and attributes, but also the whole source code space including statements. In the code- to-model direction, this approach is useless without model transformations, because the complex CodeDOM model has to be transformed into domain-specific models in order to make the approach useable in the practice. One drawback is that if the granularity of the transformation rules is not fine enough, some small changes in the code will not affect the PIMs directly. Syntactical correctness is ensured, since the change propagation works on the ASTs of the selected language and the elements of an AST are based on the grammar of the language. Semantically correct synchronization and supporting more software platforms are the subject of our future work.

Proc. Software Evolution 2007 9 / 10

ECEASST

Acknowledgements The fund of “Mobile Innovation Centre” has supported in part, the activities described in this paper. The C# source code parsing into CodeDOM is performed by the free open source NRefactory parser [27]. References [1] OMG, MDA Guide Version 1.0.1, document number: omg/2003-06-01, www.omg.org/docs/omg/03-06-01.pdf [2] OMG UML 2.0 Spec., http://www.omg.org/uml/ [3] J. Sprinkle, “Model-Integrated Computing”, IEEE Potentials , 23(1), 2004, pp. 28-30. [4] R. Kollman, P. Selonen, E. Stroulia, T. Systä, and A. Zundorf, “A Study on the Current State of the Art in Tool-Supported UML-Based Static Reverse Engineering”, Ninth Working Conference on Reverse Engineering , Washington, 2002, pp. 22-34. [5] C. Enrique Ortiz, “Introduction to Symbian OS for Palm OS developers”, http://www.metrowerks.com/pdf/ IntroSymbianOSforPalmDevelopers.pdf [6] Sun, Java 2 Platform, Micro Edition (J2ME), http://java.sun.com/j2me/index.jsp [7] Microsoft Windows Mobile, http://www.microsoft.com/ windowsmobile [8] G. Rozenberg (ed.), Handbook on Graph Grammars and Computing by Graph Transformation: Foundations , Vol.1 World Scientific, Singapore, 1997. [9] VMTS web site, http://vmts.aut.bme.hu [10] Philip Newcomb, “Abstract Syntax Tree Metamodel Standard ASTM Tutorial”, OMG’s Second Annual Architecture-Driven Modernization Workshop, Alexandria, USA, 2005. [11] Eugene W. Myers, “An O(ND) difference algorithm and its variations”, Algorithmica , 1(2), 1986 pp. 251-266. [12] W. F. Tichy, “The string-to-string correction problem with block moves”. ACM Transactions on Computer Systems , 2(4), November 1984, pp. 309-321. [13] UNIX diff manual, web site: http://unixhelp.ed.ac.uk/CGI/man-cgi?diff [14] S. Chawathe, A. Rajaraman, H. Garcia-Molina, and J. Widom, “Change detection in hierarchically structured information”, In Proceedings of the ACM SIGMOD International Conference on Management of Data , 25(2), Montreal, Quebec, June 1996, pp. 493-504. [15] S. Chawathe and H. Garcia-Molina, “Meaningful change detection in structured data”, Proceedings of the 1997 ACM SIGMOD international conference on Management of data , 26(2), May 1997, pp. 26-37. [16] S. Khanna, K. Kunal, and B. C. Pierce.” A Formal Investigation of Diff3”, Manuscript , University of Pennsylvania, 2006. [17] T. Mens, “A State-of-the-Art Survey on Software Merging”, IEEE Transactions on Software Engineering, 28(5), May 2002, pp. 449-462. [18] D.C. Oppen, “Prettyprinting” ACM Transactions on Programming Languages and Systems , 2(4), 1980, pp. 465-483. [19] U. Asklund, “Identifying Conflicts During Structural Merge”, Proceeding of the Nordic Workshop on Programming Environment Research '94 , Lund University, 1994, pp. 231-242. [20] Tancred Lindholm, “A three-way merge for XML documents”, Proceedings of the 2004 ACM symposium on Document engineering , October 28-30, 2004, Milwaukee, Wisconsin, USA, pp. 1-10 [21] R. la Fontaine, “Merging XML files: a new approach providing intelligent merge of XML data sets”, In Proceedings of XML Europe 2002 , Barcelona, Spain, 2002. [22] W. Yang, “How to merge program texts”, Journal of Systems and Software , Vol. 27, No. 2, 1994, pp. 129-135. [23] N. Niu, S. Easterbrook, and M. Sabetzadeh “A Category-Theoretic Approach to Syntactic Software Merging”. 21st International Conference on Software Maintenance (ICSM'05), Budapest, Hungary, Sept. 2005. pp 197-206. [24] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, “Design Patterns”, Addison-Wesley, Massachusetts, 1994. [25] Microsoft’s CodeDOM Web Site, http:// msdn2.microsoft.com/en-us/library/system.codedom.aspx [26] L. Lengyel, T. Levendovszky, G. Mezei, B. Forstner, H. Charaf, “Metamodel-Based Model Transformation with Aspect- Oriented Constraints”, Electronic Notes in Theoretical Computer Science , Volume 152, pp. 111-123. [27] #develop web site: http://sharpdevelop.net/ [28] G. Mezei, T. Levendovszky, H. Charaf, “A Presentation Framework for Metamodeling Environments”, Workshop in Software Model Engineering, Montego Bay, Jamaica, 2005. [29] Visual J# code provider web site: http://msdn2.microsoft.com/en-us/library/w5e3ax1a(VS.80).aspx

10 / 10 Volume X (2007) ECEASST

An Active Domain Meta Layer for Documented Software Malleability

Dirk Deridder1, Soﬁe Goderis2, Isabel Michiels2 and Viviane Jonckers1

1 [email protected], http://ssel.vub.ac.be/ System and Software Engineering Lab Vrije Universiteit Brussel, Belgium

2 http://prog.vub.ac.be/ Programming Technology Lab Vrije Universiteit Brussel, Belgium

Abstract: In order to cope with the ever-increasing adaptability and ﬂexibility requirements for software we introduce the notion of a Concept-Centric Coding (C3) environment. The aim is to provide an active domain meta layer that can be used as a basic infrastructure to set up a documented malleable implementation. We illustrate this by means of COBRO, a proof-of-concept C3 environment developed in Smalltalk.

Keywords: Run-time Adaptation, Documentation, Agile Development, Co-Evolution

1 Introduction

In order to survive in today’s highly dynamic marketplace, companies must show a continuous and ever-increasing ability to adapt. This level of agility, necessary to keep up with the business side of the adaptability challenge, consequently imposes itself on the software side. As a result the current generation of software developers needs to service extreme adaptability and ﬂexibility requirements in an environment of extremely strict deadlines, short time-to-market expectations, and limited availability of project resources [CDBD04]. The kind of systems targeted by this research are E-type object-oriented applications written in a class-based programming language. Such E-type applications are known to be in a constant state of change [Leh96] and typically call for a malleable implementation to facilitate adaptations as swiftly as possible. Additionally such systems are closely connected to a real world domain, which means that there exists a tight two-way interaction between changes in the real world and changes to the application [Pﬂ98]. As a result of this close connection to the real world, a lot of domain expertise is involved in the development of E-type systems. Since a lot of this domain expertise is lost over time or remains implicit in a software implementation, we present an approach that provides support to make it explicit in connection to the code. Moreover, to support a programmer in developing a malleable implementation, we incorporate a mechanism that renders the active use of this knowledge transparent to the programmer. Both elements will enable developers to cope with the adaptability challenge referred to above.

1 / 10 Volume X (2007) An Active Domain Meta Layer for Documented Software Malleability

The approach is labelled Concept-Centric Coding (C3)1 and is supported by a tool suite named the Concept to Code Browser (COBRO) [Der06]. In Section 2 we identify three main sources of problems that form a bottleneck for evolving object-oriented E-type applications. These are described from a worst case perspective and result in a considerable overhead for the developers. In Section 3 we introduce the C3 environment to counter the problems identiﬁed. In essence we propose an environment that provides support to make domain knowledge explicit, to couple it to the code, and to use it in an active fashion. The domain knowledge thus forms an integral and essential part of the implementation and can be used as a basic building block for creating a malleable implementation. This results in an active domain meta layer where special care is taken to reduce the overhead perceived by developers to an absolute minimum. This is based upon a symbiotic integration2 of the domain meta layer with the underlying programming language which lets programmers handle domain concepts and implementation objects transparently.

2 The Need for a Concept-Centric Coding Environment

2.1 Implicit Domain Knowledge Up to 60 percent of the time spent in software evolution is dedicated to program comprehension [ABDT04]. Canfora et al. even mention estimates as high as 90 percent [CC05]. So before any adaptation actually takes place, a lot of effort is put in trying to understand the software. Therefore in program comprehension a major amount of time is dedicated to rediscovering and reconstructing the domain knowledge3 that was available to the original developer. The fact that a lot of it remains implicit is clearly problematic for evolution. Even though this is a rather plain observation, there is also empirical evidence that domain concept descriptions are amongst the most essential information needed by software maintainers [KSP04]. Koskinen et al. for example observed that domain concept descriptions and connected domain-program-situation knowledge are among the top three most frequent information types needed by software maintainers. Broadly speaking, the main factors why knowledge about a software system becomes implicit can be summarised as follows [Der06]:

• High personnel turnover Software developers and domain experts are a volatile asset. They switch companies or project teams frequently. Moreover depending on the stage the software is in, it will become less likely to ﬁnd people that are well-acquainted with the system.

• Complexity of software systems As a result of the complexity and the size of contemporary software systems, the peculiar-

1 http://ssel.vub.ac.be/c3/ 2 With symbiotic we refer to a mutually beneﬁcial relationship between the domain meta layer and the code layer. With integration we refer to the fact that both are closely combined so they form a whole 3 The set of knowledge that captures the concepts and rules that govern a particular domain. This includes business domain knowledge which is rooted in the business (e.g., insurance, banking) and application domain knowledge which is rooted in the software used in a particular business.

Proc. Software Evolution 2007 2 / 10 ECEASST

ities of a particular component or implementation are often lost over time. This is not only a result of the difﬁculty people have to grasp the entire system. It is also a consequence of the large number of dependencies between the different elements.

• Short-term software development economics Spending time on documenting a system is time that cannot be spent on development. As a consequence code documentation is often neglected by developers in favor of producing code that contributes to the next release of the system.

• Kind of knowledge Even in a model-centric approach to software development not all knowledge is made explicit. For instance the motivation for a particular design choice is often left undocu- mented. Also common sense knowledge about the business domain in which the system operates is often unavailable in the code and the models. This is especially true in the case of a malleable generic implementation.

• Genericity of the implementation Continued development is also about refactoring the software to make it more susceptible to future changes. A basis for enhancing the ﬂexibility of an implementation lies in writing generic code. Unfortunately generic code results in less explicit code since a lot of details become hidden in the data that is loaded at runtime. Moreover less explicit code is not helpful for code comprehension since it has a negative impact on readability [Fow01].

• Reduced information quality Each time information is passed on in a communication chain, there is a deterioration of the quality. Such a deterioration also occurs when an evolution request is passed on from a domain expert to a developer since the developer will have to map the business need onto the implementation. Moreover each evolution step results in certain parts of the implementation to be rewritten which also causes a recurrent loss of information.

We have brieﬂy illustrated that domain knowledge becomes implicit for different reasons. This is problematic in the context of software evolution, since it is one of the main assets for program comprehension. Given this observation we conclude that there is a clear need for an explicit medium to capture the relevant domain knowledge. Next we discuss the importance of having a connection between the code and the domain knowledge.

2.2 Detached Domain Knowledge Making the domain knowledge available in some explicit form would only be a partial solution to the problem. Developers also need to know to which part of the implementation the knowledge applies to. Traditionally however, when knowledge is made explicit about an implementation, it is typically done detached from the implementation. This means that there is no explicit link available between the knowledge and the code. The evidence by Koskinen et al. mentioned before also conﬁrms that program-domain-situation knowledge is highly ranked by developers. This is not so surprising since developers are actually performing a continuous mapping of elements from the problem domain into the programming domain [MV95].

3 / 10 Volume X (2007) An Active Domain Meta Layer for Documented Software Malleability

Mapping the domain knowledge back to the code is difficult in nature. This is in part because the domain knowledge cannot always be brought back to one specific location in the code. This manifests itself especially in what is known as distributed domains since the corresponding domain functionality typically crosscuts the entire application. As the mapping process between the knowledge and the code is difficult and time-consuming, it is important that a developer can attach his findings to the code once the (manual) mapping is complete. To worsen the situation there also still exists a clear dichotomy of the traditional analysis- design-implementation phases. Broadly speaking this refers to the fact that the artifacts are decoupled each time control is passed from one phase to another. As a consequence, knowledge that is available in an explicit form at a certain point in time will become detached from the implementation in the end. In this section we have seen that developers not only require explicit domain knowledge. They also need to know to which part of the implementation the knowledge applies to. This indicates the need for a mechanism that helps developers to make the link between their domain knowledge and the implementation explicit. Next we discuss why it is important that developers do not perceive domain knowledge as a passive asset and as an overhead to their development activities.

2.3 Passive Domain Knowledge and Overhead for the Developer When domain knowledge is made explicit and when it is linked to the implementation, developers need to keep this information up-to-date. Yet this is not evident as a result of short-term software development economics. First of all this is due to the fact that developers do not perceive documenting as an activity that contributes to meeting their next deadline. As a consequence it is often neglected in favor of writing code. This is because the contribution of writing code to the next release of the system is clearly visible. You could say that the domain knowledge plays a passive role with respect to the execution of the system. We mean this in the sense that it does not participate actively to provide the functionality of the system in any way. Secondly, writing down the domain knowledge associated with a system is mostly done outside a development environment. This is perceived as an overhead by developers since they need to switch frequently between environments. A seamless integration of tools in such case is beneﬁcial for reducing the overhead introduced by the documentation system. From this you could conclude that the domain knowledge documentation and the implementation live in a state of antibiosis. This means that an adverse relationship exists between both sides in which one is adversely affected by the other. In essence this boils down to the fact that spending time on the documentation results in less time available for the code level. In the context of agile software development, the fact that domain knowledge plays a passive role poses an even bigger problem. Here, requirements are elicited and reﬁned on the go during the implementation of the system. Hence the software grows incrementally and is under constant revision. As a consequence it is unfeasible to have a conventional documentation system. If domain knowledge is made explicit in such a context, it will always be out-of-date unless the developers spend a lot of time on updating it each time the code is changed. It is clear that unless the domain knowledge contributes to the implementation, that developers will not or cannot dedicate any time to it.

Proc. Software Evolution 2007 4 / 10 ECEASST

In this section we have seen that one of the main reasons why domain knowledge becomes implicit and detached is because it plays a passive role. As a result it is not kept up-to-date and its usefulness as documentation will quickly degrade. This indicates the need for a mechanism that enables and promotes the activation of the domain knowledge. Moreover the mechanism should not be perceived as an overhead to the developer.

2.4 Summary In summary the problems discussed bring us to the following requirements that need to be addressed by the concept-centric coding environment we describe in the next section: Implicit Domain Knowledge A C3 environment must provide a mechanism to capture domain knowledge in an explicit form. This will reduce the possible loss of domain knowledge. Detached Domain Knowledge A C3 environment must provide a mechanism to couple the domain knowledge to the implementation. This will reduce the effort spent by developers on retroactively matching the knowledge to the corresponding implementation. Passive Domain Knowledge and Overhead for the Developer A C3 environment must provide a way to involve the domain knowledge actively in order to provide the functionality of the software system. This empowers a developer to improve the malleability of the implementation by devoting time to the domain knowledge documentation. Moreover a C3 environment must be built in a way that it is not perceived by developers as an overhead.

3 COBRO: a Concept-Centric Coding Environment

In this section we couple the four key points related to the absence of domain knowledge to the different elements of our solution. In short, the C3 environment is based upon a symbiotic integration between an active domain meta layer and a programming environment. In the following subsections we discuss how the C3 solution takes us from a situation where domain knowledge is implicit detached and passive towards a situation where it is explicit coupled and active. More- over special care is taken to make the use of the C3 solution by a developer as transparent as possible. Throughout the discussion we refer to COBRO, which is a proof-of-concept C3 tool suite developed in VisualWorks Smalltalk. For a detailed discussion of C3 and COBRO we refer to [Der06].

3.1 Setting up an Explicit Domain Meta Layer Making implicit knowledge explicit requires some kind of formalism in which the developer can express this knowledge. For our application context we opted for an open and lightweight formalism. This is intended to minimise the overhead perceived by developers when using it. Moreover, the openness of the formalism is required to enable the developer to customise it according to a particular task at hand. As we will discuss in section 3.4, we prefer to use the same syntax and interaction mechanisms of the programming language (i.e. Smalltalk) to manipulate and access the domain meta layer. This is in line with minimising the difﬁculties encountered by users as described by Shipman and Marshall [SM99]. First of all they suggest to minimize the cognitive overhead perceived by the users (e.g. by using a syntax that is familiar to the user).

5 / 10 Volume X (2007) An Active Domain Meta Layer for Documented Software Malleability

Secondly they stress that you should not enforce the user to commit to a premature structure (e.g. by not enforcing the use of class hierarchy if it is better to model in a different way). Finally they highlight the importance of enabling the user to tailor the representation according to the situation in which it is being used (e.g. by providing an open formalism that can be extended if necessary). We developed a frame-based representation named COBRO-CML in which domain concepts are related to each other within a domain meta layer. This layer can be considered to act as an ontology for both the developers and the implementation since it provides an explicit shared representation of a domain conceptualisation. In COBRO a concept is defined by a definition frame that contains definition entries. We present an example below in COBRO-CML:

(Concepts new: #{Adult}) hasLabel: ‘Adults age category’; superconcept: Concepts.AgeCategory; ageRange: ‘#(25 64)’; save.

In the example we illustrate the definition of the Adult concept which is an AgeCategory concept. Note that the syntax and interaction mechanisms of COBRO-CML are identical to Smalltalk for the purpose of transparency. The concepts from the domain meta layer are stored in a relational database, but this is not visible to the developer since they are first-class citizens. The definition entries consist of two elements: a relation (e.g. superconcept) and a destination (e.g. Concepts.AgeCategory). Destination values can be another concept or a terminal. A terminal represents a value about which we do not wish to record extra information in the concept network other than its value (e.g. #(25 64)). Hence its definition frame does not contain definition entries but just the value that it represents. In essence the choice of representing an element as a terminal or a concept defines the ontological granularity of the domain meta layer. The types of terminals that are supported by COBRO are extensible. Hence it is possible to adapt the concept representation according to the particular needs of the developer (e.g. to relate a concept to a drawing). This is realised through the notion of valueInterpreter’s in the domain meta layer, which define how a particular terminal value should be handled. Note that the relations that are used in the definition entries are also defined as concepts. As a consequence the domain meta layer is said to be self-describing. So in the example, the hasLabel, superconcept, and ageRange relations are also defined as concepts. This results in a highly extensible environment in which developers can tailor the meta layer to their needs. A prototype-based approach is followed for the domain meta layer. In a class-based approach the concepts would be represented as classes. Hence a concept could only exist unless there already existed a class that described the general characteristics of that type of concept. In contrast the prototype-based approach simply represents the actual concepts without this restriction. This is analogously to prototype-based programming languages and results in a more natural and highly dynamic way of interaction. For instance, you do not have to switch between class and object views to alter a concept definition. The choice for a prototype-based approach follows

Proc. Software Evolution 2007 6 / 10 ECEASST naturally from our goal not to enforce users to a premature structure. A class-based approach on the contrary would force the user to commit to a taxonomy of concepts from the very beginning. As a consequence a mismatch is often created if the pre-deﬁned interpretation of for example is-a is not in line with the user’s intention [WF94]. Often a distinction is made between ontology-aware, and ontology-driven applications [Gua98]. This distinction is based upon whether the concepts from the ontology are used either passively or actively by the application. As we shall see in the following sections, we move towards an environment that is best characterised as ontology-driven.

3.2 Coupling the Domain Meta Layer to the Implementation The coupling between domain concepts and code entities is done by representing the code entities (e.g. classes, methods) at the domain meta layer. The process of generating a concept representation for a code level entity is referred to as code level entity conceptification. In CO- BRO this is implemented through an extension of the Smalltalk language to support an up-down mechanism. For example you can ‘up’ a GameRating class to the domain meta layer by sending the message asConcept to it. This triggers the COBRO conceptification mechanism which will compute the concept representation for the meta layer. Note that the link between the code level entity and its domain concept counterpart remains explicit at all times. The conceptification process requires access to information about the code level. Hence it requires support for reflection from the programming language. Smalltalk excells in its reflective capabilities which was to our advantage when building the COBRO kernel. Deciding what to represent at the domain meta layer is the first choice to make with respect to the granularity of conceptification. You can restrict, for example, the available slots at the meta layer to instance variables, methods, and a superclass. A second granularity decision is how to represent the information you compute for the code entity. This boils down to specifying whether the value of a computed slot refers to a terminal or a concept. You could for example represent the value for a superclass slot as a concept and the value for an instance variable slot as a terminal. Since conceptification is an automated process, it follows a prescription based on the granularity that was chosen. This prescription defines what to represent and how to represent it, and is referred to as the intension of a concept. In COBRO this prescription can be easily customised since part of the COBRO implementation was realised by using the domain meta layer in an active fashion . At the domain meta layer, there is no difference between code level concepts and domain level concepts. This implies that they can be related to each other by adding a relation between them. Thus you can annotate the class GameRating at the domain meta layer by relating it to domain concepts such as Adult, Youngster, or Infant.

3.3 Activating the Domain Meta Layer for Malleability The way we activate the concepts in the meta layer is by making them accessible from within the code level. For this purpose COBRO extends the Smalltalk language kernel so that it becomes possible to write concept statements within normal code that consults, creates, updates or deletes domain concepts. We only illustrate this for consulting the domain meta layer by the following

7 / 10 Volume X (2007) An Active Domain Meta Layer for Documented Software Malleability code snippet of the ageCategory method from the LibraryMember class:

LibraryMember>>ageCategory ˆ Concepts.AgeCategory allSubconcepts detect: [:each| (self age >= each ageRange first) & (self age <= each ageRange second)]

The different AgeCategory concepts are ﬁrst retrieved from the domain meta layer, after which they are iterated over to ﬁnd the one that matches the age of a particular library member. Another method can now make use of this information to verify whether the user is allowed to borrow an item:

MediaLibrary>>canBorrowItem: aMember ˆ aMember ageCategory is: Concepts.Adult

This shows that domain concepts can indeed be involved in the computation at the code level. The resulting code is more generic and changes can be applied at the domain meta layer (e.g. adding age categories) without having to change the underlying code. Moreover instead of loos- ing the domain knowledge as a result of the genericity, we have actually embedded the domain knowledge explicitly within the implementation. COBRO also provides support to invoke conceptification by writing a statement at the code level (by sending the message asConcept). This gives a developer the means to ‘up’ a code level entity to the meta layer during the execution of a method. This enables a developer to write code that consults its own concept representation to perform a given task (e.g. to con- sult its annotations at the domain meta layer). A corresponding ‘down’ operation also exists (asSmalltalk), which returns the code level counterpart of a conceptified entity. When an active meta layer is installed, a developer can begin to refactor the implementation so it becomes driven by the domain meta layer. As a consequence, the concepts play an active role in the functioning of the software system and certain adaptations can be realised by changing the concepts instead of the code. This results in developer support for run-time malleability which was already used for ensuring a flexible and extensible implementation of the COBRO tool base. Note that the activation of the meta layer is the enabler to turn the antibiosis between the concept and code level into a symbiosis. Spending time on the domain concepts thus becomes advantageous to the code level and vice versa. As a consequence, the domain knowledge documentation is no longer tied to a passive promise of benefits for future evolution efforts.

3.4 Transparency for the Developer

As already illustrated, a ﬁrst step towards transparency is to use the same syntax to represent concepts as the syntax of the programming language. As a result, the developer is not required to learn another one. Moreover there is no need to switch between syntax each time a developer

Proc. Software Evolution 2007 8 / 10 ECEASST works on either the concepts or the code. Hence the programming experience is not disturbed by the concept language, since syntax-wise there is no visible difference between concepts or code. This is the reason why we did not use an existing ontology language such as OWL, or RDF. A second step to obtain transparency is to ensure that interacting with concepts and objects is done by using the same mechanisms. Hence, COBRO manipulates concepts by sending messages. This was already indicated in the code snippets, where the ageRange slot of the Adult concept was accessed by sending the corresponding message. Moreover, in order to be able to refer to concepts, a referencing scheme is needed that is similar to the one used by the programming language (e.g. Concepts.Adult). The third step to achieve transparency lies in the close integration between the programming environment and the domain meta layer. This means that all the tools available for interacting with concepts are closely integrated with the existing programming tools. Consequently, there is no need for a developer to continually switch between environments. Moreover it is desirable to provide an open malleable implementation of the concept environment. This enables the developer to adapt the environment to ﬁt more closely to the particular task at hand. As a consequence, the openness of the environment contributes to the fact that developers will no longer experience the domain knowledge documentation as an overhead.

4 Conclusion

We discussed COBRO, a concept-centric coding environment, which is based upon a symbiotic integration between a domain meta layer and a programming environment. The following requirements were detailed for our C3 environment: Explicit Domain Meta Layer: COBRO provides a mechanism that makes it possible to capture domain knowledge in an explicit form. This reduces the possible loss of domain knowledge. The domain meta layer that captures the knowledge is represented in a frame-based, prototype- based ontology. Coupling between the Domain Meta Layer and the Implementation: COBRO provides a mechanism to couple the domain knowledge to the implementation. This reduces the effort spent by developers on retroactively matching the knowledge to the corresponding implementation. Code level entities are deified towards the domain meta layer by a conceptification process that follows a prescription to generate the concept representation. This is referred to as the intension of the concept, which is based on the granularity chosen for what is represented at the domain meta layer and how it is represented. Activation of the Domain Meta Layer: COBRO provides a way to involve the domain knowledge actively so as to provide the functionality of the software system. This motivates developers not to neglect the domain knowledge, since it potentially yields a short-term benefit. Moreover an enhanced malleability of the software can be achieved by devoting time on the domain meta layer. Concept statements can be written within normal code so that domain concepts and conceptified code entities can be involved in the computation at the code level. Transparency and Reduced Overhead for the Developer: COBRO is built in a way that it is not perceived by developers as an overhead. This means that the interaction with the concept environment is set up as transparent as possible. The syntax of Smalltalk is used to represent con-

9 / 10 Volume X (2007) An Active Domain Meta Layer for Documented Software Malleability cepts at the code level. The mechanisms to interact with concepts are based on the mechanisms to interact with normal objects. The programming environment and the concept environment are implemented in close symbiotic integration with each other.

Acknowledgements: This research is funded by the IAP Programme of the Belgian State.

Bibliography

[ABDT04] A. Abran, P. Bourque, R. Dupuis, L. Tripp. Guide to the Software Engineering Body of Knowledge (Ironman Version). Technical report, IEEE Computer Society, 2004.

[CC05] G. Canfora, A. Cimitile. Software Maintenance. IT Metrics and Productivity Jour- nal, November 2005. Online article - e-Zine.

[CDBD04] T. Cleenewerck, D. Deridder, J. Brichau, T. D’Hondt. On the evolution of IMe- dia Implementations. Proceedings of the European Workshop on the Integration of Knowledge, Semantics and Digital Media Technology, 2004.

[Der06] D. Deridder. A Concept-Centric Environment for Software Evolution in an Ag- ile Context. PhD thesis, Vrije Universiteit Brussel, Programming Technology Lab, 2006.

[Fow01] M. Fowler. To Be Explicit. IEEE Software, November, December 2001.

[Gua98] N. Guarino. Formal Ontology and Information Systems. In Proceedings of FOIS 1998, Trento, Italy. IOS Press, Amsterdam, June 1998.

[KSP04] J. Koskinen, A. Salminen, J. Paakki. Hypertext Support for the Information Needs of Software Maintainers. Journal of Software Maintenance and Evolution: Research and Practice 16:187–215, 2004.

[Leh96] M. Lehman. Laws of Software Evolution Revisited. In European Workshop on Soft- ware Process Technology. Pp. 108–124. 1996.

[MV95] A. von Mayrhauser, A. Vans. Program Comprehension During Software Mainte- nance and Evolution. IEEE Computer, August 1995.

[Pﬂ98] S. L. Pﬂeeger. The Nature of System Change. IEEE Software, pp. 87–90, May/June 1998.

[SM99] F. M. Shipman III, C. C. Marshall. Formality Considered Harmful: Experi- ences, Emerging Themes, and Directions. Computer-Supported Cooperative Work 8(4):333–352, 1999.

[WF94] C. A. Welty, D. A. Ferrucci. What’s in an Instance? Technical report, RPI Computer Science, 1994.

Proc. Software Evolution 2007 10 / 10 ECEASST

Organizing Software Evolution According to Principles

Isabelle Cotˆ e´1, Maritta Heisel2, and Holger Schmidt3

1 [email protected] 2 [email protected] 3 [email protected] Department of Computational and Cognitive Sciences (CoCoS) Working Group Software Engineering University Duisburg-Essen, Germany

Abstract: We present a number of software evolution principles that serve to adapt existing software to new or changed requirements. These principles are represented in a uniform way according to a template. Furthermore, they are classiﬁed according to different high-level objectives. To support the systematic application of the principles, different relations between them are identiﬁed. These principles form the basis for a systematic software evolution method. Keywords: Software Evolution, Evolution Principles

1 Introduction

One of the most costly phases of software development is software maintenance and evolution. Evolution means to adapt existing software to new or changed requirements. In fact, software systems need to evolve continually to cope with changing requirements or environmental conditions. In this paper, we investigate evolution on the source code level. Any additional documentation to the source code is considered as a bonus. Hence, the starting point for evolving a software system is its plain source code. We propose to organize the evolution according to evolution principles, e.g. Inspect classes and their features or Solve by analogy. These principles are classiﬁed according to different high-level objectives, namely locating the source code parts relevant for the evolution, modifying the located parts, and determining whether the modiﬁcation is correct and complete, i.e. validating the evolution. Furthermore, we identify relations between the different evolution principles: the application of one principle may involve applying another principle, another principle may be alternatively applied, or a principle may be supplemented by applying another principle. The principles we elaborated are not new, nor do we claim having invented them. Instead, we can summarize our contribution as: • making the evolution principles explicit by representing them in a uniform way • classifying them according to high-level objectives • relating the different evolution principles to each other • establishing a basis for a systematic software evolution method Other software engineering disciplines, such as refactoring [Fow00], already successfully apply similar concepts, however, with different intentions.

1 / 9 Volume X (2007) Organizing Software Evolution According to Principles

An evolution method based on our principles involves the repeated application of the principles with the objectives locate, modify, and validate. The paper is structured as follows: in Sect. 2, we present the evolution principles and their relations. We furthermore sketch their practical application. Section 3 treats related work. In Sect. 4 we summarize our results and give a prospect to future research.

2 Principles

In social studies [BT02], a principle is described by:

“Principle: A basic rule that guides or inﬂuences thought or action.”

This deﬁnition can be adapted to our understanding of software evolution, because it describes well what we intend to provide with our principles: guidance for an engineer while carrying out an evolution task through providing him/her a collection of basic rules, i.e. principles. This is comparable to a plumber’s toolbox. The equivalent for the evolution engineer is therefore the set of principles. We elaborated the evolution principles by carrying out some evolution tasks and deriving abstract descriptions of them. To provide further support for an engineer, we classify the principles according to different objectives (Sect. 2.1) and represent them in a uniform way (Sect. 2.2). We support the application of the different evolution principles by describing relations between the different principles (Sect. 2.3). Finally, we sketch the practical application of the principles and report on a case study where we performed some evolution tasks on an open-source software system (Sect. 2.4).

2.1 Principle Objectives

While carrying out different evolution tasks, we recognized that it is possible to identify three main objectives an evolution process consists of. These high-level objectives are:

Locate Find the source code parts that need to be changed to fulfill the new/changed requirement(s). Modify Change the source code parts identified through the localization. Validate Decide when the modifications are sufficient to implement the new/changed requirement(s).

To achieve a certain high-level objective, it is necessary to perform activities that aim at accomplishing that objective. The activities, in turn, differ in the circumstances under which they are applicable. For example, searching for a file name is a promising activity when a file base with meaningful file names exists. If this is not the case, but a technical documentation is available, reviewing that documentation is an alternative. We classify the elaborated principles according to the high-level objectives. This results in a set of location principles, a set of modification principles, and (for the time being) one validation principle.

Proc. Software Evolution 2007 2 / 9 ECEASST

2.2 Principle Representation To be able to to find appropriate principles for a task, it is not sufficient to just classify the principles. A good means to characterize the principles is to equip them with meaningful names, similarly to design patterns [GHJV95]. Thus, it is possible to refer to or search for a particular evolution principle according to its name. A uniform representation additionally helps to structure the principles and make them comparable. We propose the following template to represent the derived evolution principles (see Figs. 1 and 2 for examples): Name specifies the purpose of the principle. We also indicate if it is a location principle (L), a modification principle (M), or a validation principle (V). Situation describes the circumstances under which the principle can be applied. In other words, this can be considered as the precondition of the principle. Goal describes the goals to be achieved by the principle. In other words, this describes the postcondition that is established after the principle has been applied. Activity describes the activities, which have to be performed in order to meet the goal. Remark gives further information concerning the given principle.

Principle Inspect code L Situation Principle Extract design documents L Other location principles have revealed Situation code parts, which will potentially evolve. Development artifacts of the design phase Goal are not present, or it is not known if they Gain an understanding of the purpose of the still reflect the actual state of the software investigated source code part. system. Activity Goal Inspect the code considering: Obtain a set of reconstructed design docu- • Purpose: What is the code part ments, e.g. call graphs, or class diagram needed for? Activity • Structure: How is the code part im- Try to use tools such as Doxygen [Hee07] plemented? to generate design artifacts automatically. • Relevance: Will it be modified? Will Should the extracted artifacts not suffice, something be added or removed? manual extraction must be performed. Remark Remark It is useful to combine the principle In- We strongly recommend to always apply spect code with the principle Locate out- this principle. put functionality or Locate input functionality whenever output or input functionality is looked for. Figure 1: The location principles Extract design documents and Inspect code

Table 1 provides an overview of the currently available principles. Describing all evolution principles is not possible due to space limitations. Therefore, we limit ourselves to describe the

3 / 9 Volume X (2007) Organizing Software Evolution According to Principles principles given in Figs. 1 and 2 as examples in more detail. The purpose of the location principles Extract design documents and Inspect code is to identify those code parts that will have to be altered to accomplish the evolution task. To achieve this, they use different mechanisms. When we apply the principle Extract design documents, we use code analyzers such as Doxygen [Hee07] to extract information out of the source code. In this way, some documents are generated that capture the current state of the system. Even if other documents are available it is still advisable to apply this principle. The reason is that the generated documentation can be used to check whether the documents at hand and the just generated documentation are coherent. With the tools, it is also possible to create different documents, e.g., call graphs, class diagrams etc. that depict the source code in a graphical representation. They help to gain an overview of the system and thus also help to identify the code parts relevant for the evolution. Additionally, it is possible to navigate through the sources in a comfortable way. In contrast to Extract design documents the principle Inspect code does not rely on tools to generate documentation. The approach here is to have a close look at the source code to understand what it realizes and how it does it. This investigation will also reveal, if the code part under consideration needs to be modiﬁed. Additionally, we gain an impression of the programming style and see to what extent refactoring will be necessary.

Principle Re-use code M Principle Solve by analogy M Situation Situation Some code fragments already realize parts New features may use similar mechanisms of the functionality requested by an evolu- to realize the functionality as features, tion requirement. which are already implemented. Goal Goal Re-use existing code fragments. Create the new feature based on existing so- Activity lutions. Check if existing code fragments can be re- Activity used for the modiﬁcation task. It will be Look how features for similar functionality necessary to adapt the identiﬁed code frag- have been implemented. Use this knowl- ments. Also adjust existing design docu- edge to implement the new feature. Also ments. If none are present, create the corre- adjust existing design documents. If none sponding documents. are present, create the corresponding docu- Remark ments. It should be avoided to introduce duplicated Remark code! A high modularity facilitates the ap- – plication of this principle.

Figure 2: The modiﬁcation principles Solve by analogy and Re-use code

We now describe the principles Re-use code and Solve by analogy as representatives for the modification principles. The principles of this class are used to modify those code parts which have been identified by the location principles before. Depending on the kind of modification, the corresponding modification principle is selected.

Proc. Software Evolution 2007 4 / 9 ECEASST

The principle Re-use code is applied whenever code parts already exist that (partially) realize functionality needed for accomplishing the evolution task. These parts are then re-used. In some cases it might be necessary to alter these code parts to cope with the new functionality. The principle Solve by analogy, on the other hand, uses the concept underlying already implemented features. This concept is then used to introduce the new feature following the idea of the already implemented one.

2.3 Principles’ Relations npc code Inspect code new Create npc documentation Inspect name ﬁle Inspect features their and classes Inspect debugger Use functionality output Locate functionality input Locate search by Locate documents design Extract code Re-use code existing Modify analogy by Solve Test

Inspect documentation a,h a,h a a,h a,h a,h a h Inspect ﬁle name a,h a,h a a,h a,h a,h a h Inspect classes and their features a,h a,h a a,h a,h a,h a h Use debugger a a a a a a a a,h Locate output functionality a a a,h a a a h Locate input functionality a a a,h a a a h Locate by search a a a,h a a,h a,h a h Extract design documents a a a,h a a,h a,h a,h h Inspect code a Re-use code a a a i Modify existing code a a a i Create new code a a a i Solve by analogy a a a i Test e Locate a alternative e Modify h helpful e Validate i involves Table 1: Objective and relation of the different principles

5 / 9 Volume X (2007) Organizing Software Evolution According to Principles

So far, the principles possess a uniform representation and are related to an objective. In addition, it is possible to identify different relations between the evolution principles. For example, extracting calling relationships out of a given source code (cf. evolution principle Extract design documents left-hand side of Fig. 1) helps in inspecting source code parts to find out their purpose (cf. evolution principle Inspect code right-hand side of Fig. 1). Analyzing all pairs of principles in a similar way, we were able to identify three types of relations, namely alternative, helpful, and involves. Table 1 shows an overview of the evolution principles and their relations. The table also shows the classifications of the different evolution principles. The principles with a light gray background belong to the category location principle. The principles with a dark gray background belong to the category modification principle. Finally, the principle Test indicated with a black background belongs to the category validation principle. The different entries in Tab. 1 are read as follows: a (alternative): The principle written horizontally (first column) is an alternative for the principle written vertically (first row). This means that before we apply the principle in the first column, we should check if another principle in the first row is perhaps better suited. For example, principle Use debugger (fourth entry in first column) is an alternative to the principle Inspect documentation (first entry in first row). Note that the relation alternative is symmetric, i.e., if principle x is an alternative to principle y, then principle y is also an alternative to principle x. h (helpful): The horizontally written principle in the first column is helpful for the vertically written principle mentioned in the first row. This means that its additional application should be considered. For example, the principle Inspect classes and their features (third entry in first column) is helpful for the principle Inspect code (cf. right-hand side of Fig. 1 (ninth entry in first row). In contrast to the alternative relation, the helpful relation is not symmetric. Even though Inspect classes and their features is helpful for Inspect code, the opposite is not necessarily true. i (involves): The principle mentioned in the first column involves the principle mentioned in the first row. This means that whenever the first principle is applied, the second one must be applied, as well. For example, the principle Re-use code (cf. left-hand side of Fig. 2) in the first column involves the principle Test in the first row. a,h (alternative, helpful): Whenever the principle in the first row is not applicable, the principle mentioned in the first column is an alternative to it. In the case that the principle in the first row is applicable, the principle in the first column is helpful. For example, the principle Inspect documentation is an alternative to the principle Locate output functionality, if Locate output functionality is not applicable. If Locate output functionality is applicable, the principle Inspect documentation is helpful for the principle Locate output functionality, and it should be considered, as well.

Proc. Software Evolution 2007 6 / 9 ECEASST

We can see in Tab. 1 that location principles are only related to location principles and that modification principles are only related to modification principles. This is because the two classes of principles serve different purposes. Furthermore, Tab. 1 reveals that the location principles complement each other to a large extent. For this reason, it is advisable to apply several principles of this category to consolidate the relevant source code parts for a given evolution task. Considering the modification principles, we can see that all the principles of this category are alternative to each other. They either consider existing code (e.g., principles Re-use code, and Modify existing code) or code to be newly written (e.g., principle Create new code). Moreover, all the principles of this category involve the principle Test.

2.4 Practical Application To illustrate the usefulness of the evolution principles, we sketch how they are applied in a practical evolution task. The initial situation for the evolution task is the presence of a software system with its corresponding source code. Furthermore, at least one evolution requirement (ER) must be given. An ER is a requirement that the software system is not able to fulfill in its current state. In the case that several ERs are given, the procedure is applied to every requirement, i.e., we treat only one requirement at the time. The first step is to locate those parts of the source code, which need to be modified in order to establish the ER under consideration. For this purpose, we have a look at the set of location principles. All the other evolution principles belonging to a different class do not have to be considered, as they serve to achieve a different objective (cf. clusters in Tab. 1). Depending on whether or not additional documentation besides the source code is present, we select a subset of the location principles. Let us assume that no documentation other than the source code is available. The source code is written in an object-oriented programming language, and the classes and their features possess meaningful names. Therefore, we decide to choose the principles Ex- tract design documents, Inspect classes and their features, and Inspect code. The combination of these evolution principles then reveals potential parts within the source code that (may) change. As no further development documents exist, we apply the location principle Extract design documents. We let the code analyzer generate a full set of all supported document types out of the source code to gain a first overview. Keeping the ER in mind, we start to investigate the just generated documents, especially the classes, methods, and attributes using location principle Inspect classes and their features. An example for a potential modification candidate, found by applying this principle, could be a method with a name similar to the feature we want to add. To verify, if the method body holds, what the name promises we apply the location principle Inspect code to investigate what the method does, i.e., find out its purpose. After the location step, we select one of the identified code parts and start to modify it. For this purpose, we take a look at the modification principles. Let us assume in this case, that we want to integrate a new external tool into the existing software system and that we know, that another external tool is already used. On this basis, we select the modification principle Solve by analogy (cf. right-hand side of Fig. 2). All calls to the new external software tool have to be added at the appropriate places. This may happen with the aid of the other modification principles. When the modification has been performed, it is necessary to find those code parts which depend on the

7 / 9 Volume X (2007) Organizing Software Evolution According to Principles just modified one. An example here could be that the signature of a method has been modified. Hence, all calls to this method need to be adapted. The dependent code parts are identified by applying once more the location principles followed by application of modification principles. This procedure is repeated until no further changes are necessary. To validate that the changes are complete, it is necessary to perform tests by applying validation principle Test. All in all, this procedure is repeated until all identified code parts have been modified and validated. At the end, one final validation is performed to ensure that the ER has been correctly and completely integrated into the software system.

We have applied our evolution principles to evolve the open-source software Doxygen [Hee07]. Doxygen is an open-source software allowing automated extraction of documentation out of a given source code. It supports several programming languages, such as C++, Java, Python, etc. The documentation can be generated to different output formats, e.g., HTML or PDF. Among other documentation support mechanisms, Doxygen offers the capability of drawing different diagram types, e.g. call graphs. We have performed several different evolution tasks on the Doxygen software system. For example, we extended call graphs and caller graphs by combined call-caller graphs, improved the readability of class lists, and added sequence diagrams known from UML [For05] as a newly supported graph type. It turned out that locating, modifying, and validating the relevant source code parts was astonishingly easy when using our evolution principles: it was sufﬁcient to concentrate on a small fraction of classes, methods, etc. within the overall source code base.

3 Related Work

Several different approaches considering software evolution exist. Examples are the work of Gall et al. [GHJ98] and Ducasse et al. [DGF05]. Their approaches put emphasis on the analysis of software evolution based on change histories. Ducasse et al. [DGF05] propose a meta-model for software evolution analysis. Our approach does not concentrate on such an analysis. Instead, we introduce evolution principles for manipulating source code in a systematic way to enable source code evolution. An approach, which appears to be similar to ours, is the work of Demeyer et al. [DDN02]. However, their intention is to provide a pattern system for object-oriented re-engineering tasks. This seems similar, because software evolution and software re-engineering are no disjoint disciplines. In fact, software evolution usually involves some re-engineering and refactoring [Fow00] efforts. Hence, it is only natural to rely on experiences and techniques of those disciplines.

4 Conclusion and Future Work

Software evolution is a challenging task. Therefore, it is necessary to perform a software evolution task in a systematic way to keep the effort feasible. To achieve this goal, we propose to organize the evolution task according to principles. We categorize these principles according to their purpose, i.e. locate, modify, and validate. We represent them on the basis of a template to ease their comprehension and usage. Furthermore, we determined different relations between

Proc. Software Evolution 2007 8 / 9 ECEASST the principles of a category: a principle can be an alternative for another, it can be helpful, or it can involve the application of another principle. This structure helps developers to identify and apply appropriate principles while carrying out an evolution task with a manageable effort. We validated our approach with several evolution tasks in an open-source context. We think, that our approach is promising and that it helps to reduce the effort of a source-code centric evolution task. In the future, we intend to further elaborate the approach presented in this paper, e.g., by adding more validation principles. We also work on developing a method based on the evolution principles. So far, the principles presented here were derived, validated, and used on object-oriented software systems. In the future, we would like to investigate our principles for evolving other types of software systems, such as embedded or distributed systems etc. to see how well they perform in different contexts.

Bibliography

[BT02] J. W. Bayer, K. Tamarkin. McGraw-Hill’s GED Social Studies: The Most Compre- hensive and Reliable Study Program for the GED Social Studies Test. McGraw Hill Higher Education, 2002. p. 419.

[DDN02] S. Demeyer, S. Ducasse, O. Nierstrasz. Object-Oriented Reengineering Patterns. Morgan Kaufmann, 2002.

[DGF05] S. Ducasse, T. Gˆırba, J.-M. Favre. Modeling Software Evolution by Treating History as a First Class Entity. Electr. Notes Theor. Comput. Sci. 127(3):75–86, 2005.

[For05] U. R. T. Force. OMG Uniﬁed Modeling Language 2.0: Superstructure. August 2005. http://www.uml.org.

[Fow00] M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000.

[GHJ98] H. Gall, K. Hajek, M. Jazayeri. Detection of Logical Coupling Based on Product Release History. In Proceedings of the International Conference on Software Main- tenance 1998 (ICSM’98). Pp. 190–198. 1998.

[GHJV95] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns – Elements of Reusable Object-Oriented Software. Addison Wesley, 1995.

[Hee07] D. v. Heesch. Doxygen - A Source Code Documentation Generator Tool. 2007. http://www.stack.nl/˜dimitri/doxygen.

9 / 9 Volume X (2007) ECEASST

Living on the Cutting Edge: Automating Continuous Customer Conﬁguration Updating

Slinger Jansen1, Sjaak Brinkkemper1, and Tijs van der Storm2

Information and Computing Sciences Institute Utrecht University, Utrecht, The Netherlands {slinger.jansen, sjaak.brinkkemper}@cs.uu.nl1 Centrum voor Wiskunde en Informatica Amsterdam, The Netherlands [email protected]

Abstract: Product software vendors cannot continuously update their end-users’ configurations. By not automating continuous updating, the costs to test, release, and update a software product remain exorbitantly high. This paper shows the feasibility and profitability of continuous customer configuration updating, with the help of two practical case studies. Automating continuous updating enables vendors and customers to define flexible policies for release, delivery and deployment. Such flexibility enables customers and vendors to be in full control of how and when product knowledge and updates are delivered, tested, and deployed, speeding up the process of software evolution. Keywords: Customer configuration updating, agile development, continuous integration, product software knowledge delivery

1 Introduction

Manufacturing product software is an expensive and non-trivial task for software vendors. Soft- ware vendors face challenges to divide their resources to develop, release, and deliver high quality software. Unfortunately, there always are more requirements and opportunities than a tenfold of developers could implement. Extreme competition forces software vendors to reduce time to market and to release new features as often as possible. As products and updates are changed and released more often, effort is saved by automating Customer Configuration Updating (CCU). In earlier work CCU has been positioned as the release, delivery, deployment, and usage and activation processes of product software [JB06]. In this paper we focus on the automation of these processes to reduce overhead per release. The release process is how and how frequent products and updates are made available to testers, pilot customers, and customers. The delivery process consists of the method and frequency of update and knowledge delivery from vendor to customer and from customer to vendor. The deployment process is how a system or customer configuration evolves between component configurations due to the installation of products and updates. Finally, the activation and usage process concerns license activation and knowledge creation on the end-user side. The importance of CCU is often underestimated as systems nowadays are increasingly supplied to customers as an on-line service, thus requiring no more software delivery and deploy-

1 / 11 Volume X (2007) Living on the Cutting Edge: Automating Continuous Customer Configuration Updating ment on the customer side. There are multiple sides to this service orientation trend, however. These days, services are deployed on home user systems as well. Simultaneously, an increase is seen in the use of product software on mobile devices, requiring different deployment mechanisms. Examples can even be found of services and products that are deployed on mobile and embedded devices, offered as services, and on customer PCs. One such example is TomTom, offering its product on embedded devices in the TomTom Go, as an online service with TomTom Maps, and deployed on your portable device with TomTom Navigator. Another example is developed by Google, offering the Google Mini embedded device, Google on-line websearch, and Google Desktop for the home PC. Interesting blends of software are becoming more common than traditional retail software products, increasing the need for smart CCU. Automating steps in the CCU process contributes to product software vendors in four ways. First, software vendors serve a larger number of customers when less overhead is required per customer [JB06]. Secondly, due to more frequent integration builds and automated test runs developers see results of their contributions quicker and testers can test more recent versions of the software, improving the vendor’s internal development process. Also, when deployment is automated developers and testers lose less time (re)deploying the application locally after different developers have contributed to the project. Finally, managing specific policies on both the customer and vendor side enables advanced release, delivery, and (re-)deployment scenarios. Vendors can flexibly define when a product must be released, whereas customers can decide to periodically check for new updates and not install them until formal approval has been given. In section 2 we introduce the concept of continuous CCU and define the research approach and identify tools that potentially automate continuous CCU. One such tool, Pheme, is described in section 3 and specifically built to serve this purpose. In section 4 we show, by means of two case studies, that continuous CCU can be automated with relatively little effort. Finally, in section 5 we conclude that continuous CCU tools provide more flexible processes at lower costs.

2 Continuous CCU

By automating steps in the CCU process as much as possible, CCU cost and effort can be reduced effectively and larger numbers of customers can be served [JB06]. Automating steps in the CCU process ultimately contributes to Continuous CCU (C-CCU). C-CCU is defined as being able to continuously provide any stakeholder of a software product with any release of the software, at different levels of quality. This way developers, testers, and even end-users can always be fully up to date. Before an organization can properly set up C-CCU, however, policies must be defined for all processes in the software product life cycle. These policies are displayed in Figure 1, which models the C-CCU process for any type of product release, such as a new product, a major update, or a minor bug fix. In the software product lifecycle different policies define the method and freqency of the release, delivery, deployment, logging, feedback, and debug processes. C-CCU must not restrict customers or vendors in any way, instead, it should be a mere facil- itator for more responsive software product management. C-CCU enables a software vendor to become more responsive to changes in customer and market demands. It provides developers and testers with the most recent (working) version available. C-CCU is an organizational driver for

Proc. Software Evolution 2007 2 / 11 ECEASST continuous integration, continuous testing, and continuous quality control. As such, customers are provided with better guarantees of quality when code is released. As long as the software vendor and customer share knowledge and manage it explicitly, CCU becomes less error-prone and less time consuming. The current trend towards agile development only strengthens the be- lief that C-CCU is essential in the current market and that the return on investment into C-CCU automation is high.

2.1 Research Approach The aim of this research is to find out whether automating C-CCU is feasible and profitable for software products. C-CCU automation feasibility is established by showing two cases in which we have automated C-CCU. Profitability is established by showing the low overhead for automating C-CCU. Two cases were selected with different development technology, working on different platforms. Then a tool selection was made to automate and implement the C-CCU process for these applications following an inventorization of C-CCU automation tools. Finally, some aspects of C-CCU have been automated for the two applications, implementation time was written down per feature. The C-CCU automation was considered successful when the following three criteria were met. First, updates to the software had to be seamless, without any manual intervention. Sec- ond, the development and delivery process had to be improved significantly. Finally, the investment had to be small. Figure 1: C-CCU and its Policy Context Threats to validity of this study [Yin03] are that the applications are not representative and that process changes are underestimated. Two applications were selected, Joomla1 and the Meta- Environment2, both freely available as open source products. The applications are very different with regard to development methodology (monolithic vs component-based) and technology (PHP/MySql vs. Java, C and several domain specific languages).

2.2 Related Work and Tools The tools evaluated for this research range from scientiﬁc open source prototypes to commercial products with a very high turnover. For a more extensive discussion on product update tools (such as package managers, knowledge delivery tools, etc.) we direct the reader to [JBB05].

1 http://www.joomla.org/ 2 http://www.meta-environment.org/

3 / 11 Volume X (2007) Living on the Cutting Edge: Automating Continuous Customer Conﬁguration Updating

Nix - Nix [DJV04] is a package management system that ensures safe and complete installation of packages for Unix based systems. Nix approaches software deployment as a memory management problem, concurrently storing different versions and variants of components (values) identified by unique hashes (pointers). Nix ensures atomic updates and rollbacks that guarantee that existing component dependencies never break. Such updates can be downloaded from channels in which updates for specific components are published, and are deployed as binary patches and as source patches. Because Nix manages all dependencies of every component, it derives continuous releases from continuous integration. With regard to C-CCU Nix supports deployment policy management. However, writing Nix expressions that describe dependencies amongst components in their domain specific language, is not a trivial task. Furthermore, Nix is currently a scientific research tool that is restricted to Unix-like software environments. Sisyphus - Sisyphus (http://sisyphus.sen.cwi.nl:8080/) is a component-based continuous integration and release tool. Component versions are built in an incremental fashion, i.e. only if there are affecting changes, sharing previous build results if possible. Accurate bills of mate- rials (BOMs) are maintained in a database that allows derivation of release packages for every successful build [vdS05, vdS07]. Passing the integration build is but the first QA milestone. Be- cause every build corresponds to a (internal) release, testers can easily update their configuration on a regular basis. Formal releasing a product simply consists of labelling a particular build that satisfies the required quality properties. This allows the development organisation to setup different channels that have different frequencies of release. FLEXnet - Macrovision’s FLEXnet (http://www.macrovision.com) is a suite of release, delivery, and deployment products, such as InstallShield, InstallAnywhere, FLEXnet Connect, and AdminStudio. Macrovision’s product suite provides tooling to create releases for any platform, install them on any platform, and let them be managed by a system administrator. Their tools provide licensing, copy protection, and patch delivery solutions. Macrovision’s strength can be found in the fact that they manually support many of the process steps that are part of C-CCU. Software Dock - The Software Dock [HHW99] is a system of loosely coupled, cooperating, distributed components that are connected by a wide area messaging and event system. The components include field docks for maintaining site specific configuration information by consumers, release docks for managing the configuration and release of software systems by producers, and a variety of agents for automating the deployment process. The Software Dock is an early attempt to correctly, consistently, and automatically deliver and deploy software. The Software Dock does not focus on release management or continuous release practices and is lacking in the area of knowledge delivery from customer to software vendor. The tools and research projects discussed in this section are focused on one particular aspect of the customer configuration updating process (see Table 1, these properties have been determined by reading documentation and testing the tools with small cases, A means that the tool supports the process automatically, i.e., no user intervention is required and policies can be flexibly defined. M means that the tool requires manual steps from the user). Sisyphus supports continuous release, but has no feedback loop from the customer to the vendor. Nix is primarily geared towards deployment as is the Software Dock; both are lacking in the areas of release and customer feedback. MacroVision’s FLEXnet supports many of the processes manually, but not automatically. The next section introduces the knowledge distribution framework Pheme that is designed to remedy this situation. In Greek mythology, Pheme was the personification of fame

Proc. Software Evolution 2007 4 / 11 ECEASST and renown, described as “she who initiates and furthers communication”3.

Nix Sisyphus FlexNet SWDock Pheme Release A M M A Delivery A A A Deployment M M M A Logging M A Feedback A M A Debug M Table 1: Manual (M) or Automated (A) Tool Support for Policies

3 The Pheme Delivery Hub

Pheme is an infrastructure that enables a software vendor to communicate about software products with end-users and enables system administrators to perform remote deployment, policy propagation, and policy adjustment. The infrastructure consists of a server tool (Pheme), a protocol between software product and Pheme, a protocol between Phemes, and a GUI. The Pheme server resides on each system that acquires and distributes software knowledge through subscribe/unsubscribe channels. The server can accept and distribute all types of knowledge, including policies concerning software knowledge delivery and deployment that describe behaviour of the Pheme tool. These policies can be manipulated securely and remotely. Pheme enables software vendors to publish software knowledge in the form of licenses (for one end-user), software updates (for a group of end-users), software content, and software news (for another group of end-users). Pheme enables customers to send knowledge in the form of usage and error feedback. A system administrator can use Pheme to instruct other Phemes, change and distribute delivery and deployment policies, control all communication between end- users and vendor, and redistribute software (knowledge). Finally, an end-user can edit policies, execute deployment policies (such as remove/install/update a software product), determine when and how feedback will be sent to the vendor, and refresh all types of knowledge such as licenses. The processes in Figure 1 are all covered by advanced tools and methods, such as release by Sisyphus and deployment by Nix. However, none of the tools fully cover deployment policy and delivery policy management for multiple participants in a software supply network (SSN) [JFB07]. Pheme was created to enable these participants to explicitly manage and share knowledge about software components, and thus provide coverage for the release publication, feedback, and knowledge delivery process steps.

3.1 Pheme Architecture Pheme’s architecture is modelled in Figure 2. The core components are policy management, package management, user management, and channel management. The policy management component enables the user of Pheme to deﬁne delivery policies (check for and download software updates on a weekly basis, for instance) and deployment policies (check every time when

3 http://en.wikipedia.org/wiki/Pheme/

5 / 11 Volume X (2007) Living on the Cutting Edge: Automating Continuous Customer Configuration Updating the product is shut down whether any new updates have been downloaded and deploy the newest one). The package management component supplies Pheme with knowledge package support, in the form of files, reports, facts about the product (version numbers, dependencies, etc.) and human readable product news. The user management component enables different types of users to be known to the Pheme instance. Such users can be local administrators, knowledge suppliers, and knowledge consumers. The user management component also enables the Pheme administrator to contact other Phemes and indirectly change policies of other Pheme instances. Finally, the channel management component manages different channels that can automatically and manually push or pull knowledge packages to and from other Phemes and URLs. Pheme is interacted with through its user interface, through another Pheme, and through the software product itself using SOAP procedure calls. Software products use Pheme as a gateway to vendor release and feedback repositories. Typically such interactions include receiving updates, product news, and sending feedback and usage statistics. Pheme handles knowledge packages as opaque artifacts, however, in some cases where software product knowledge is required, the package handling component can be used as a fact base. These facts are then used to store, for instance, a product configuration. Pheme then serves as a knowledge base from which both the vendor and the customer can get information. Furthermore, this enables a vendor to develop a specific fix for a specific group of customers. The suitability of the update can then be decided by Pheme. An example setting is presented in Figure 3, where four different instances of Pheme on four different hosts are shown. A COTS vendor sells components to a vendor, who can distribute knowledge through its channels to the system administrator, such as the an- nouncement of a new release. The system administrator can communicate with the end-user(s) of the prod- Figure 2: Pheme Architecture uct. Finally, end-users send information regarding the day-to-day use of the product back to the vendor. The Joomla case study, presented in the next section, takes place in a similar setting.

4 Case Study Results

4.1 Joomla Joomla is a leading open source content management system that is widely adopted for its intuitive user interface and low barrier for acceptance. It has a large user base and a large team of developers. Furthermore, a large collection of components and user generated content are available. Joomla can be installed on any web server that supports PHP and MySQL. Traditionally, Joomla applications are updated by hand. Minor releases exclude datamodel changes, so these can overwrite current deployments. For major releases tutorials are released that explain the

Proc. Software Evolution 2007 6 / 11 ECEASST

Figure 3: Example Environment for Pheme proper method for updating the datamodel and the source code. The manual process of updating is error-prone, since it is possible to overwrite source files from a Joomla configuration with newer versions. This leads to many Joomla deployments that are never updated, which increases the risk of hacks. The main advantages for the Joomla product in automating C-CCU are found in effort savings. Each developer, tester, and customer will at some point have to deal with an evolving instance of the product because they want new features or wish to plug a security leak. Their time can be saved by not having to manually evolve the configuration of their Joomla instance. Furthermore, we speculate that the Joomla development team can automatically generate and test releases and publish them on-line, which will no longer require the manual effort of checking the release for completeness and such. Finally, Joomla customers can be sure that their CMS contains the most recent security updates. To automate C-CCU for Joomla the processes of release, delivery, and deployment are automated. In order to prepare a release, the source code is checked out from the Joomla SourceForge repository periodocally. To deliver the source code to the customer the source bundle is sent to the customer system. A policy control system is set up on the customer system to automatically deploy any new versions that come in for Joomla. To automate deployment the system automatically calculates the differences between a new version and the currently deployed version. The changes are then made to the deployed data model and source code. Automating C-CCU for Joomla - To automate C-CCU for Joomla the tools Pheme4, Sub- Version5, DataDiff6, and MySqlDiff7 are used. In this case study a release, an administrator, and a customer system are used. The release system locally prepares the releases by simply bundling the source code, data model, and data into one compressed file. The administrator system is used to instruct the customer system with delivery and deployment policies, such as “check for Joomla bundles from the release system every hour” and “deploy a new Joomla version as soon as it arrives”. The release system obtains the sources on a daily basis, by using an automated check-out script. Furthermore, the release system zips the contents of the new release, and places

4 http://www.cs.uu.nl/Pheme/ 5 http://subversion.tigris.org/ 6 http://freshmeat.net/projects/datadiff/ 7 http://www.mysqldiff.org/

7 / 11 Volume X (2007) Living on the Cutting Edge: Automating Continuous Customer Configuration Updating it in a Pheme release channel. The system administrator system also runs Pheme, to instruct the customer system with new policies. The customer system runs Joomla, Apache, and MySql for its daily operations. Pheme is used to check hourly for new updates from the release system and to run the appropriate commands when a new release bundle comes in. When a new release bundle comes in the release is deployed as if it were a “fresh” deployment. The configuration script, configuration.php, is overwritten with the configuration script from the deployed version, with a change in the database name. The data model is then created, using joomla.sql. The difference between the data models is calculated using MySqlDiff and a data model update script is generated. The update process is a three part process where the database structure is first updated, the new data is added, and then the changed files are overwritten. Software delivery and deployment, software knowledge delivery, and feedback delivery were automated for Joomla. Software delivery and deployment cost two full days. The delivery of knowledge cost 4 hours of development time, including the adjustments to Joomla. Finally, to implement logging also cost 4 hours including development time. Technical Challenges - Our approach is not safe. The automatic data model update does not apply any knowledge from the development process, which can lead to data loss, empty columns, and other data update problems [Sjo93]. Furthermore, there is no assurance whether the downloaded bundle is of reliable quality. Also, since updates occur at runtime the system can become unstable. For such runtime updating state-safe techniques can provide solutions [VEBD06]. To complete the C-CCU process an extension was built to Joomla’s error handling mechanism, such that errors and warnings were reported back to Pheme and stored for further analysis. Process Challenges - With C-CCU in place, a number of process changes are required from the Joomla team and its customers. To begin with, the release process needs to be redesigned. To guarantee that high quality code is released to customers, a number of criteria can be devised to delay releases, such as test failures. Joomla can also, instead of opting for continuous CCU, define intervals at which new versions will be released (such as a once weekly update). After all C-CCU is a concept that provides maximum flexibility to customers and developers, and should not introduce extra risks or effort. For a future deployment system, knowledge about “preferred update routes” must be specified and shared between the Joomla release team and the Joomla customer, such that quality guarantees can be provided for defined sequences of updates. Joomla’s Software Supply Network - To display news from Pheme in the Joomla backend a module has been created called ModPhemeNews. This module will only work with approved versions of Joomla resulting in the fact that the ModPhemeNews team must approve of any new version of Joomla before an update of the full Joomla package can take place on the customer side, which is a common way of working with add-ons. If C-CCU were to be automated in such a process, customers could possess new code quicker because this dependency can be specified and shared. The Joomla creators could, for instance, provide an early release for module and add-on builders. Furthermore, the ModPhemeNews creators could automatically download any new releases for Joomla immediately, automatically test the new combination of Joomla and ModPhemeNews, and notify customers of its approval of the Joomla update.

Proc. Software Evolution 2007 8 / 11 ECEASST

4.2 The Meta-Environment

The second case study concerns the Meta-Environment, a integrated development environment (IDE) for language development, source code analysis and transformation. It is a component- based application consisting of tools for parsing, transforming, pretty printing and analyzing programming language sources connected together using dedicated middleware. The Meta- Environment is an open framework that can easily be extended or customized with third-party components. For the Meta-Environment the introduction of C-CCU decreases development, release creation, and deployment effort which is valuable in a setting where the developers are all full-time researchers. Before introducing C-CCU, the Meta-Environment was built using a daily build system, whereas today the Sisyphus continuous integration system is used which builds complete systems on every change to the source control (Subversion). Every component contains a manifest listing its dependencies. The manifest is used by the build system to determine how a component should be built and which earlier build result can be reused to satisfy these dependencies. Before the introduction of Sisyphus, release amounted to manually changing the version numbers of all components and the dependency specification accordingly and creating a release package using the tool AutoBundle [dJ02]. However, since such compositions did not directly follow from the build system and were not formally tracked (i.e., in a database of builds) many mistakes were made in this process. This turned out to be a serious impediment to schedules employing more frequent releases, let alone continuous releases. Automating C-CCU for the Meta-Environment - For the Meta-Environment the release, delivery, and deployment processes were automated. The release process provides a new release as soon as one of the Meta-Environment components is changed. With regard to release, Sisyphus is used to automatically release the most recent version that fully passed an integration build. To automate delivery, Pheme has been installed on the end-user system to automatically download the latest binary distribution on an hourly basis and deploy it on a nightly basis. Pheme checks whether the Meta-Environment is running and, if it is not, the new release is installed. Since installations of the Meta-Environment are stateless old files are overwritten. The implementation of Sisyphus for the release process took a developer five full days. Furthermore, to automate delivery and deployment with Pheme cost a developer two days. Technical Challenges - The Meta-Environment does not support any error recovery or reporting at runtime. To build such error recovery, the architecture needs to be redesigned in such a way that the component configuration remains robust and can send an error report at runtime before a crash occurs. A complication is that the Meta-Environment is a heterogeneous system; i.e. the components are implement in different languages (C, Java, proprietary). Process Challenges - The C-CCU process for the Meta-Environment is not perfect. To begin with the quality criteria (it must pass the integration build and a large number of unit tests) are weak. Sisyphus has the infrastructure to provide for stronger criteria. Some manual intervention is required in order to label successful builds with the accompanying quality attributes. By publishing such releases at specific URLs, customers can choose among different release channels, such as “cutting edge”, “daily”, “weekly”, “minor”, “major” etc. Furthermore, there is no facility for users to report problems back to the developers except through the regular media such as e- mail and bugzilla. However, this way users have to manually link their error report to the version they have installed. Subsequently developers have to read the email and manually reproduce the

9 / 11 Volume X (2007) Living on the Cutting Edge: Automating Continuous Customer Conﬁguration Updating problem. One would wish for the automatic identiﬁcation of the installed version whenever a problem occurs at the customer site. Meta-Environment’s Software Supply Network - The Meta-Environment is a component composition, with different open source components coming from different development locations. When a Meta-Environment release is created, stable versions of components are explicitly labelled to be part of the next release. This method of releasing reduces risk, although it does force a customer to install components that are potentially outdated. In future releases of the Meta-Environment, automation of Sisyphus and strict quality checking enables releases with the most up-to-date third-party components and a decrease in integration effort. The components of the Meta-Environment themselves are not strongly coupled, meaning that in the future components could be updated independently.

5 Conclusions and Future work

This paper presents the concept of continuous customer conﬁguration updating. Secondly, a new tool that facilitates delivery of software knowledge between vendors and customers is presented. Also, two cases are presented for which, under certain conditions, automation of C-CCU improves development. Automating C-CCU reduces overhead from the release. delivery, deployment, and usage processes, enabling software developers to focus on their product instead of the supporting processes and tools. Furthermore, automating and implementing C-CCU in a software vendor’s organization enables it to become more responsive to change [Boe02]. The time to automate some of the C-CCU processes (three days for Joomla and seven days for the MetaEnvironment) is negligible compared to the time saved. The quick automation, however, could only be done with the availability of strong development support tools such as Sisyphus and Pheme. With the availability of such tools, software vendors can more easily adopt automatic CCU, since it enables software vendors to pace the heartbeat of software development and delivery [vdS07]. Because C-CCU encourages releasing often, the quality assurance process must be designed to continuously test new releases. Furthermore, by delivering straight from the source repositories the cases only provide crude examples of what can be done by automating C-CCU. These automations would be used to provide recent releases to development, test, and integration personnel in practice. Automation of C-CCU in such a manner that updates are safely and securely deployed (possibly at runtime) requires knowledge about product structure and architecture. The two presented case studies do not make use of product architecture information and can thus not guarantee safe and secure updates at run-time. A generic tool could be built that automates the update process for different types of software architectures, such as SOAs, plug-in systems, and monolithic systems. We consider this as future work. Furthermore, part of our future work is to build the Pheme prototype into a commercial product in cooperation with a number of industrial partners.

Bibliography

[Boe02] B. Boehm. Get Ready for Agile Methods, with Care. Computer 35(1):64–69, 2002.

Proc. Software Evolution 2007 10 / 11 ECEASST

[DJV04] E. Dolstra, M. de Jonge, E. Visser. Nix: A Safe and Policy-Free System for Soft- ware Deployment. In Proceedings of the 18th Conference on Systems Administration (LISA 2004), Atlanta, USA, November 14-19, 2004. Pp. 79–92. 2004.

[HHW99] R. S. Hall, D. Heimbigner, A. L. Wolf. A Cooperative Approach to Support Software Deployment Using the Software Dock. In International Conference on Software En- gineering. Pp. 174–183. 1999.

[JB06] S. Jansen, S. Brinkkemper. Deﬁnition and Validation of the Key Process Areas of Release, Delivery and Deployment of Product Software Vendors: turning the ugly duckling into a swan. In proceedings of the International Conference on Software Maintenance (ICSM2006, Research track). September 2006.

[JBB05] S. Jansen, S. Brinkkemper, G. Ballintijn. A Process Framework and Typology for Software Product Updaters. In Ninth European Conference on Software Mainte- nance and Reengineering. Pp. 265–274. IEEE, 2005.

[JFB07] S. Jansen, A. Finkelstein, S. Brinkkemper. Providing Transparency in the Business of Software: A Modelling Technique for Software Supply Networks. In Proceedings of the 8th IFIP Working Conference on Virtual Enterprises. 2007.

[dJ02] M. de Jonge. Source Tree Composition. In Proceedings: Seventh International Conf. on Software Reuse. LNCS 2319, pp. 17–32. Springer-Verlag, Apr. 2002.

[Sjo93] D. Sjoberg. Quantifying Schema Evolution. Inf. Softw. Tech. 35(1):35–44, 1993.

[vdS05] T. van der Storm. Continuous Release and Upgrade of Component-Based Software. In Proceedings of the 12th International Workshop on Software Conﬁguration Man- agement (SCM-12). 2005.

[vdS07] T. van der Storm. The Sisyphus Continuous Integration System. In Proceedings of the Conference on Software Maintenance and Reengineering (CSMR’07). IEEE Computer Society Press, 2007. To Appear.

[VEBD06] Y. Vandewoude, P. Ebraert, Y. Berbers, T. D’Hondt. An alternative to Quiescence: Tranquility. In Proc. of the 22nd IEEE International Conference on Software Main- tenance. Pp. 73–82. IEEE Computer Society, Washington, DC, USA, 2006.

[Yin03] R. K. Yin. Case Study Research - Design and Methods. SAGE Pubs., 3rd ed., 2003.

11 / 11 Volume X (2007) ECEASST

Evolutionary Problems in Aspect-Oriented Software Development2

Kim Mens1 and Tom Tourwe´2

1 [email protected], http://www.info.ucl.ac.be/∼km/ Departement´ d’Ingenierie´ Informatique, Universite´ catholique de Louvain, Belgium

2 [email protected], http://www.win.tue.nl/∼ttourwe/ Software Engineering & Technology Lab, Eindhoven University of Technology, Netherlands

Abstract: When adopting aspect technology, regardless of whether it is to develop a new software system or to migrate a legacy one, the developers will eventually be confronted with evolutionary problems. This paper highlights some of these problems in aspect-oriented programming. Although many of the problems have already been identiﬁed by researchers and some promising techniques are currently being investigated, this research domain is still relatively immature and warrants further investigation by the community. Keywords: aspect-oriented software development, software evolution, aspect exploration, aspect extraction, aspect evolution

1 Introduction

Just like the industrial adoption of object-oriented programming in the early nineties led to a demand for migrating software systems to an object-oriented solution — triggering a boost of research on software evolution, reverse engineering, reengineering and restructuring — the same is currently happening for the aspect-oriented paradigm. Aspect-oriented software development is a novel paradigm that tends to provide a solution for the software developers’ inability to represent in a modular way certain concerns in a given software system, when those concerns crosscut the chosen decomposition of the software in modules. In absence of aspect-oriented software development techniques, crosscutting concerns lead to duplicated code fragments throughout the software system, which is believed to negatively impact evolvability, maintainability and understandability of the software. Aspect-oriented software development proposes a solution to this acclaimed problem by introducing the notion of aspects, which are designated language constructs that allow a developer to localise a concern’s implementation, and thus improve modularity, understandability, maintainability and evolvability of the code. Adopting a new software development technology brings about particular risks, however, and aspect-oriented programming forms no exception. In our view, one of the most important remaining obstacles for adopting aspect-oriented software development technology is the fact that it has to be introduced into existing software systems. Most software systems today are not developed from scratch, but rather are enhanced and maintained legacy systems. We predict that

2 This paper is a reduced version of a 28 page book chapter on “Evolution Issues in Aspect-Oriented Software Development” by the same authors that will appear in a software evolution book later this year. [MT07]

1 / 10 Volume X (2007) Evolutionary Problems in AOSD real widespread adoption of aspect-oriented programming will be achieved only if the risks and consequences of adopting aspect-oriented programming in existing software are studied, and if the necessary tools and techniques become available for dealing with those risks. This paper addresses some of the issues and challenges related to such adoption of aspect- oriented software development from a software evolution perspective. Although we will not present any solutions to the problems mentioned3, the overview of evolutionary problems given in this paper can be useful to adopters of aspect technology to get a better idea of the evolution issues they may confront sooner or later and of the risks involved. For researchers it can serve as a map of interesting problems remaining to be studied.

Aspect Evolution LEGACY system Aspect LEGACY system Aspect BASE system Exploration Extraction Aspect Aspect Aspect

Figure 1: Software evolution and aspect-oriented software development.

As illustrated by Figure1, the discussed issues range from the exploration of crosscutting concerns in legacy code, via the extraction of this code to an aspect-oriented solution, to the evolution of the ﬁnal aspect-oriented program over time. In the next section we give a brief introduction of aspect-oriented programming. Sections3 to5 will then each discuss the three activities of aspect exploration, extraction and evolution in more detail. In particular, we will focus on the the challenges and risks that need to be dealt with or will be encountered when conducting those activities.

2 A crash course in aspect-oriented programming

The goal of aspect-oriented programming is to provide an advanced modularisation scheme to separate the core functionality of a software system from system-wide concerns that cut across the implementation of this core functionality. To this extent, AOP introduces a new abstraction mechanism, called an aspect. An aspect is a special kind of module that represents a crosscutting concern. Aspects are deﬁned independently from the core functionality of the system and integrated with that base program by means of a dedicated aspect weaver, a dedicated tool similar to a compiler that merges aspect code and base code in the appropriate way. Figure2 illustrates this idea. In most current-day aspect languages, of which AspectJ (http://www.eclipse.org/aspectj/) is the most well-known, aspects are composed of pointcuts and advices. Whereas advices correspond to the code fragments that would crosscut an entire program, pointcuts correspond to the locations in the source code of the program where the advice will be applied (i.e., where

3 See the full book chapter [MT07] of which this position paper is a summary, for a more detailed discussion of some of the proposed solutions.

Proc. Software Evolution 2007 2 / 10 ECEASST

aspect 3 aspect 1 aspect 2

Aspect Weaver

core application functionality

woven output code

Figure 2: Aspect-oriented programming.

the crosscutting code will be woven). A pointcut essentially specifies a set of joinpoints, which are well-defined locations in the structure or execution flow of a program where an aspect can weave in its advice code. Typical AspectJ joinpoints are method invocations or field accesses, for example. Pointcuts which merely enumerate the signatures of all methods they need to capture are called extensional o enumeration-based pointcuts. Such pointcuts are brittle and can break easily when the base program evolves. More robust pointcut definitions can be obtained by mentioning explicitly only the information that is absolutely required and using wildcard patterns or other mechanisms to abstract over certain implementation details. Such pointcuts are referred to as intensional or pattern-based pointcuts. In summary, pointcuts, whether they are extensional or intensional, specify those places in the code or its execution where the advice code needs to be woven. This means that aspects are not explicitly invoked by the program. The base program (i.e., the program without the aspects) is not aware of the aspects that apply to it. Instead, it is the aspects themselves that specify when and where they act on the program. This property, which has been referred to as the obliviousness property of aspect orientation [FF00], is one of the most essential characteristics of an aspect- oriented programming language.

3 Aspect exploration

Before introducing aspects in existing software, one should explore whether that software actually exhibits any crosscutting concerns that are worthwhile being extracted into aspects. The tyranny of the dominant decomposition [TOHSMS99] implies that large software is likely to contain crosscutting concerns. During the aspect exploration phase we try to discover aspect

3 / 10 Volume X (2007) Evolutionary Problems in AOSD candidates in the software, i.e., we try to discover what the crosscutting concerns are, where and how they are implemented, and what their impact on the software’s quality is. However, migrating a legacy software system into an aspect-oriented one is a non-trivial en- deavour. The sheer size and complexity of many existing systems, combined with the lack of documentation and knowledge of such systems render it practically infeasible to manually transform their crosscutting concerns into aspects. To alleviate this problem, a growing body of research exists that proposes a number of tools and techniques to assist software engineers in semi-automatically migrating crosscutting concerns to aspects. Most of these approaches distinguish two phases in this migration process: aspect exploration and aspect extraction. Whereas Section4 will focus on the aspect extraction phase, the current section discusses issues and challenges related to aspect exploration. We deﬁne aspect exploration as the activity of identifying and analysing the crosscutting concerns in a non aspect-oriented system. A distinction can be made between manual exploration supported by special-purpose browsers and source-code navigation tools, on the one hand, and aspect mining techniques that try to automate this process of aspect discovery and propose their user one or more aspect candidates, on the other hand. [KMT07] When exploring an existing software system for relevant crosscutting concerns that potentially could be turned into aspects, the following questions need to be addressed:

What (kind of) crosscutting concerns can be discovered? Examples of crosscutting concerns that are often mentioned in literature, and exempliﬁed by small-scale example projects, include simple and basic functionalities like tracing, logging or precondition checking. Do such simple concerns actually occur in industrial code? Is aspect-oriented programming only suited to implement such simple concerns? Do industrial software systems contain more complex crosscutting concerns? How good is aspect-oriented programming at tack- ling those?

How are crosscutting concerns implemented in absence of aspects? Since crosscutting concerns in a traditional software system are per deﬁnition not well-localised, they need to be implemented over and over again. To minimise this implementation overhead, developers tend to rely on a variety of programming idioms and naming and coding conventions. What (kind of) crosscutting concerns are implemented by which programming idioms and conventions?

(How) do crosscutting concerns affect software quality? When crosscutting concerns occur in a software system, (how) do they affect the quality of that software? How can we measure their impact on quality factors like understandability, maintainability and adaptability? How can these measures help us assess whether extracting the concerns into aspects is beneﬁcial?

How to ﬁnd where crosscutting concerns are located in the code? When we want to turn a crosscutting concern into an aspect, we need to know where exactly it is located in the code. This knowledge is important to determine an appropriate pointcut for the extracted aspect. How can we be sure that we have found all relevant crosscutting concerns, that we have covered them completely, that there are no false positives or negatives?

Proc. Software Evolution 2007 4 / 10 ECEASST

Over the last few years, aspect exploration has become quite an active research domain and a whole range of different approaches, techniques and tools for supporting or automating the activity of aspect exploration have been proposed. Several researchers have studied complex crosscutting concerns that occur in real-world industrial software systems, and they are starting to get an idea about how such concerns are implemented in the absence of aspect-oriented programming techniques. Nevertheless, more such studies on industrial-size software systems are needed. Similarly, although preliminary research attempts have been undertaken for the remaining two challenges (i.e., how crosscutting concerns affect software quality and how to locate them in the software), more research is needed in order to come up with satisfying answers and solutions. For example, more empirical work and quantitative studies are needed on how crosscutting concerns affect software quality. The impact of crosscutting concerns on software quality factors like evolvability is not yet clear, and has been investigated mostly on small-scale example software only. Part of the problem stems from the fact that aspect-oriented programming is a relatively young paradigm, and hence little historical information (in the form of revision histories etc.) is available for study. Another problem is that, more often than not, a traditional version and an aspect-oriented programming version of the same software system are not available, making it hard to conduct objective comparisons. As for the identiﬁcation of crosscutting concerns, all known techniques are only partly automated and still require a signiﬁcant amount of user intervention [KMT07]. In addition, most aspect mining techniques are only academic prototypes and, with few exceptions, have not been validated on industrial-size software yet. Although this may hinder industrial adoption, the existence of such techniques is obviously a step forward as opposed to having no tool support at all. Another issue with applying automated aspect mining techniques is that preferably the user should have some knowledge about the system being mined for aspects. Indeed, different aspect mining techniques rely on different assumptions about how the crosscutting concerns are implemented.

4 Aspect extraction

Once the crosscutting concerns have been identified and their impact on software quality has been assessed, we can consider migrating the software to an aspect-oriented version. We refer to this activity as aspect extraction. If we do decide to migrate the software towards an aspect- oriented solution, we need a way of turning the aspect candidates, i.e., the crosscutting concerns that were identified in the exploration phase, into actual aspects. At the same time, we need techniques for testing the migrated software to make sure that the new version of the software still works as expected, as well as techniques to manage the migration step, for example to ensure that we can still keep on using the software during the transition phase. Aspect extraction is the activity of separating the crosscutting concern code from the original code, by moving it to one or more newly-defined aspects, and removing it from the original code. Since an aspect is typically defined as a collection of pointcuts and associated advice code, extraction entails the identification of suitable pointcuts and the definition of the appropriate advice code corresponding to the crosscutting concern code.

5 / 10 Volume X (2007) Evolutionary Problems in AOSD

Research on aspect extraction thus focusses on how to automate the activity of extracting aspects from existing source code. Only with an automated approach, an extraction that is both efﬁcient and accurate can be achieved. Existing software systems often consist of millions of lines of code, and a real-world crosscutting concern thus easily consists of thousands of lines of code. Manually extracting aspects from these crosscutting concerns, if feasible at all, would not only be very time-consuming, but prone to errors as well. A correct aspect weaves the appropriate code at the appropriate joinpoints, and hence requires correct advice code and correct pointcuts. These are hard to construct, given the scattered and tangled nature of crosscutting concerns, and the size of current-day software systems. In order to be able to extract crosscutting concerns code from the original code into the appropriate aspects, the following questions need to be addressed:

How to separate crosscutting concerns from the original source code? Sophisticated program analysis and manipulation techniques are needed to separate crosscutting concern code, since by deﬁnition such code is tangled with other code. Depending on the kind and the amount of tangling, some code is easier to separate than other code. Tracing code, for example, is often relatively independent of the code surrounding it, whereas Bruntink et al.’s experiment [BvDT06] showed that exception handling code exhibits signiﬁcantly more tangling.

How to determine appropriate joinpoint(s) for the extracted aspects? An aspect needs to specify the exact location where advice code needs to be woven, by means of a (set of) pointcut(s) that select(s) the appropriate joinpoints. However, aspect languages impose certain restrictions on the locations in the static or dynamic software structure that can be made available as joinpoints. Hence, determining the appropriate joinpoints requires signiﬁcant attention.

How to determine the appropriate pointcut(s) for the extracted aspects? Assuming that appropriate joinpoints can be found, the next problem is that of determining the appropriate pointcut(s) that describes these joinpoints. Additionally, the pointcuts need to expose the appropriate context information for the advice code.

How to determine the appropriate advice code for the extracted aspects? The crosscutting concern code typically cannot be transformed “as is” into advice code. Small modiﬁcations are often required, due to the code being deﬁned in a different context, but also due to small variations in the scattered snippets of crosscutting concern code.

How to ensure correctness of the extracted code? The correctness requirement is of course related to behaviour preservation, i.e., extracting aspects from existing source code is expected to preserve the external behaviour of that code. Even for traditional refactorings this is already considered a non-trivial problem [Opd92]; when extracting aspects from traditional programs the problem only becomes harder. Obviously, automating the transformations that are applied can help meeting this requirement, as automated transformations can be proven correct by using preconditions [Opd92]. Additionally, appropriate test suites are of great value, but are not always present in (legacy) software. Furthermore,

Proc. Software Evolution 2007 6 / 10 ECEASST

since the extraction process affects the original code structure, certain tests that rely on that structure may need to be restructured as well. In particular, certain tests may need to be transformed into their aspect-oriented equivalent.

How to manage the migration step? A ﬁnal issue that is of particular value for industrial software is how to ensure that we can keep on using the software during the transition phase.

Research on aspect extraction is still in its infancy, as most researchers focussed primarily on aspect exploration first. Nonetheless, work exists that contributes to the growing body of aspect extraction research [BDvDT07, MF04, MF05, EV04, BCH+05, HMK05, HOU03]. Unfortu- nately, although the major issues and problems related to aspect extraction seem to have been identified by the aspect-oriented community, no satisfactory solutions exist yet. Most existing techniques touch upon a specific part of a particular problem, but no single technique provides a complete solution to all problems identified. This is no surprise, as research on aspect extraction is only just emerging. First of all, the level of automation of current extraction techniques is poor, and most could benefit significantly from more automation. Second, the issue of preserving the behaviour of the software after extraction has not yet been tackled explicitly. Proving the correctness of aspects that were extracted manually is practically impossible. Automated techniques, however, could be proven correct. Given Opdyke’s experience in this matter [Opd92], it is clear that constructing formal proofs for the complex extraction transformations is far from trivial. However, formally defining the necessary preconditions for such transformations should be feasible, but has currently not yet been realised. Related to testing behaviour-correctness of performing aspect extraction, the issue of migrating the original test suites to the migrated software system remains. Unfortunately, little work exists on testing aspect-oriented systems (notable exceptions are the works of Xu and Xu [XX06] and Xie and Zhao [XZ06]), let alone on the migration of the original tests to their aspect-oriented equivalent. Finally, little or no empirical validation of the proposed techniques on large-scale, real-world software systems has been performed. This makes it hard to assess whether the techniques actually work in practice, what their advantages and disadvantages are, whether they scale to large industrial software, and whether the extraction actually improves the quality of the software.

5 Aspect evolution

According to Belady and Lehman’s ﬁrst law of software evolution [LB85], every software system that is used will continuously undergo changes or become useless after a period of time. There is no reason to believe that this law does not hold for aspect-oriented software too. But to what extent is evolution of aspect-oriented software different from evolution of traditional software? Can the same techniques that are used to support evolution of traditional software be applied to aspect-oriented software? Do the new abstraction mechanisms introduced by aspect-oriented programming give rise to new types of evolution problems that require radically different solutions?

7 / 10 Volume X (2007) Evolutionary Problems in AOSD

Once the crosscutting concerns in the original software system have been explored and the system has been migrated to a new aspect-oriented version, the system enters a new phase in which it will need to be continuously maintained and evolved in order to cope with changing requirements and environments. In this section, we highlight some of the issues and problems related to such evolution of aspect-oriented systems. As was argued in the introductory section, aspect-oriented software development overcomes some of the problems related to software evolution, in particular the problems related to maintaining and evolving independently the different (crosscutting) concerns in a system. But since all software systems are subject to evolution (remember the first law of software evolution), aspect- oriented systems themselves too will eventually need to evolve. We define aspect evolution as the process of progressively modifying the elements of an aspect-oriented software system in order to improve or maintain its quality over time, under changing contexts and requirements. While research on aspect exploration is only starting to produce its first results and research on aspect extraction is still gaining momentum, research on aspect evolution is even younger. This is largely due to the fact that few large-scale aspect-oriented software systems exist today. Even if they would exist, they would be too young in order for them to be the subject of a rigourous scientific study regarding their long-term evolution problems. Despite the immaturity of the field, some initial research questions have been raised, related to how the evolution of aspect-oriented software differs from evolving traditional software and whether techniques and tools, successful in supporting traditional software evolution, can still be applied to the evolution of aspect-oriented software. It seems that the very techniques that aspect-oriented programming provides to solve or limit some of the evolution problems with traditional software, actually introduce a series of new evolution problems. This phenomenon is sometimes called the evolution paradox of aspect-oriented programming [TBG03]. To conclude, it is clear that aspect evolution is still an emerging research area, in which not all important research questions have been identified, let alone answered. Nevertheless, it is important to mention that an awareness of the problem is growing inside the aspect-oriented software development community, and that more and more researchers in that community are starting to investigate such problems [HOU03][MF05][KS04][SG05][SGS+05][MBG06][HNB06][LHBL06].

6 Summary

In this paper, we highlighted some important evolution-speciﬁc issues and challenges related to the adoption of aspect-oriented programming. We identiﬁed three different stages that adopters of aspect-oriented programming may need to go through: exploration, extraction and evolution. The overall conclusion that can be drawn for each of these stages is that aspect-oriented software development is still a young paradigm, that still needs to mature and requires much more rigourous research. Nonetheless, it is a promising paradigm that receives a lot of attention, and gives rise to several tools and techniques that already provide at least some kind of support for early adopters. For a more detailed overview of on these tools and techniques we refer to our book chapter [MT07].

Proc. Software Evolution 2007 8 / 10 ECEASST

Bibliography

[BCH+05] David Binkley, Mariano Ceccato, Mark Harman, Filippo Ricca, and Paolo Tonella. Automated refactoring of object oriented code into aspects. In Proc. Int’l Conf. Software Maintenance (ICSM), pages 27–36. IEEE Computer Soci- ety, 2005.

[BDvDT07] Magiel Bruntink, Maja D’Hondt, Arie van Deursen, and Tom Tourwe.´ Simple crosscutting concerns do not exist. In Proc. Int’l Conf. Aspect-Oriented Software Development (AOSD). ACM Press, 2007.

[BvDT06] Magiel Bruntink, Arie van Deursen, and Tom Tourwe.´ Discovering faults in idiom-based exception handling. In Proc. Int’l Conf. Software Engineering (ICSE). ACM Press, 2006.

[EV04] Ran Ettinger and Mathieu Verbaere. Untangling: a slice extraction refactoring. In Proc. Int’l Conf. Aspect-Oriented Software Development (AOSD), pages 93–101. ACM Press, March 2004.

[FF00] R. Filman and D. Friedman. Aspect-oriented programming is quantiﬁcation and obliviousness, 2000. October 2000, Minneapolis. http://ic-www.arc.nasa.gov/ic/ darwin/oif/leo/ﬁlman/text/oif/aop-is.pdf.

[HMK05] Jan Hannemann, Gail C. Murphy, and Gregor Kiczales. Role-based refactoring of crosscutting concerns. In Proc. Int’l Conf. Aspect-Oriented Software Devel- opment (AOSD), pages 135–146. ACM Press, 2005.

[HNB06] W.K. Havinga, I. Nagy, and L.M.J. Bergmans. An analysis of aspect composition problems. In Proceedings of the Third European Workshop on Aspects in Software, August 2006, University of Bonn, pages 1–8, 2006.

[HOU03] Stefan Hanenberg, Christian Oberschulte, and Rainer Unland. Refactor- ing of aspect-oriented software. In Proc. Int’l Conf. Object-Oriented and Internet-based Technologies, Concepts, and Applications for a Networked World (Net.ObjectDays), pages 19–35. Springer-Verlag, 2003.

[KMT07] A. Kellens, K. Mens, and P. Tonella. A survey of automated code-level aspect mining techniques. Trans. AOSD, 2007. To be published.

[KS04] Christian Koppen and Maximilian Storzer.¨ PCDiff: Attacking the fragile pointcut problem. In Kris Gybels, Stefan Hanenberg, Stephan Herrmann, and Jan Wloka, editors, European Interactive Workshop on Aspects in Software (EIWAS), September 2004.

[LB85] Meir M. Lehman and L. A. Belady. Program Evolution: Processes of Software Change. Apic Studies In Data Processing. Academic Press, 1985.

9 / 10 Volume X (2007) Evolutionary Problems in AOSD

[LHBL06] Roberto E. Lopez-Herrejon, Don S. Batory, and Christian Lengauer. A disciplined approach to aspect composition. In PEPM, pages 68–77, 2006. [MBG06] Kim Mens, Johan Brichau, and Kris Gybels. Managing the evolution of aspect- oriented software with model-based pointcuts. In D. Thomas, editor, Proc. Eu- ropean Conf. Object-Oriented Programming (ECOOP), volume 4067 of Lecture Notes in Computer Science, pages 501–525. Springer-Verlag, 2006. [MF04] Miguel P. Monteiro and Joao˜ M. Fernandes. Object-to-aspect refactorings for feature extraction. In Proc. Int’l Conf. Aspect-Oriented Software Development (AOSD). ACM Press, 2004. [MF05] Miguel P. Monteiro and Joao˜ M. Fernandes. Towards a catalog of aspect- oriented refactorings. In Proc. Int’l Conf. Aspect-Oriented Software Development (AOSD), pages 111–122. ACM Press, 2005. [MT07] Kim Mens and Tom Tourwe.´ Evolution Issues in Aspect-Oriented Programming, page 28. 2007. To be published. [Opd92] William F. Opdyke. Refactoring: A Program Restructuring Aid in Designing Object-Oriented Application Frameworks. PhD thesis, University of Illinois at Urbana-Champaign, 1992. [SG05] Maximilian Stoerzer and Juergen Graf. Using pointcut delta analysis to support evolution of aspect-oriented software. In Proc. Int’l Conf. Software Maintenance (ICSM), pages 653–656. IEEE Computer Society, 2005. [SGS+05] K. Sullivan, W.G. Griswold, Y. Song, Y. Chai, M. Shonle, N. Tewari, and H. Ra- jan. On the criteria to be used in decomposing systems into aspects. In Symp. Foundations of Software Engineering joint with the European Software Engineer- ing Conf. (ESEC/FSE 2005). ACM Press, 2005. [TBG03] Tom Tourwe,´ Johan Brichau, and Kris Gybels. On the existence of the AOSD- evolution paradox. In Lodewijk Bergmans, Johan Brichau, Peri Tarr, and Erik Ernst, editors, SPLAT: Software engineering Properties of Languages for Aspect Technologies, March 2003. [TOHSMS99] Peri Tarr, Harold Ossher, William Harrison, and Jr. Stanley M. Sutton. N degrees of separation: multi-dimensional separation of concerns. In Proc. Int’l Conf. Software Engineering (ICSE), pages 107–119. IEEE Computer Society Press, 1999. [XX06] Dianxiang Xu and Weifeng Xu. State-based incremental testing of aspect- oriented programs. In Proc. Int’l Conf. Aspect-Oriented Software Development (AOSD), pages 180–189. ACM Press, 2006. [XZ06] Tao Xie and Jianjun Zhao. A framework and tool supports for generating test inputs of AspectJ programs. In Proc. Int’l Conf. Aspect-Oriented Software De- velopment (AOSD), pages 190–201, 2006.

Proc. Software Evolution 2007 10 / 10 ECEASST

Improved Program Comprehension with Revision Control System Repository Analysis

Andrew Burn

Department of Computer Science, Durham University, UK

Abstract: Program comprehension is a crucial element in software maintenance. A maintainer can use analysis and visualisation tools to gain a degree of understanding of an unfamiliar project, but analysis of a single version of that project is limited in the scope of the information it can produce. Analysis of a number of versions of that project can a greater depth information, as well as providing insights into the behaviour of previous developers and the development process itself. Revision control systems such as SubVersion or CVS are an integral part of any software development project, especially in a distributed development environment. Because an RCS repository contains numerous revisions of the project, not just the current working version, analysis of that repository can be used to derive information on the evolution and development of that project, information which can greatly aid in program comprehension. This paper presents Perceive, a system for analysing RCS repositories and generating reports and visualisations to aid in program comprehension. A case study in which Perceive is applied to the source repositories from a collection of Software Engineering Group (SEG) projects from Durham University’s Computer Science degree demonstrates that Perceive provides useful results that can aid in the comprehension and assessment of these projects. Keywords: Visualisation, SubVersion, Version Control, Program Comprehension

1 Introduction

The evolution and increasing complexity of software over its lifetime [LR01] dictates that software maintenance can be a very difﬁcult process. This is exacerbated when maintainers ﬁnd themselves working with no prior knowledge of the software, poor documentation and no access to the original developers [BR00]. Without analytical tools to aid them maintainers can easily introduce more problems than they address. Thankfully a number of tools exist to aid in program comprehension [PPBH91] and impact analysis [Aji95] - i.e. helping the maintainer understand the software and to assess the effects of their change activities. Visualisation models to help the maintainer build a mental model of the software are frequently integral parts of these tools. The two types of software analysis - static and dynamic - can be used in these tools, but static code analysis typically proves more useful for program comprehension [PRW03]. However, even code analysis has limits to the information it can provide. By analysing the history of the project as well as the current version, a program comprehension tool can provide an extra dimension of information to the maintainer. This history can be likened to the software documentation - it

1 / 10 Volume X (2007) Improved Program Comprehension with RCS Repository Analysis allows the maintainer to understand not just the code “as-is” but why the code was written that way, how it arrived at its current state and what processes the developers went through to reach the current version. Revision control systems (RCS) are vital tools in software development. They provide a central source of software assets (e.g. source code or documentation), backup functionality and provide a workflow process for multiple users to work on the same project simultaneously. As well as being a useful tool for development, the repository created and used by a revision control system contains the whole history of a project’s implementation, a history which can provide a great deal of information about that project, including developer behaviour and patterns, project structure, details on workflow and collaboration and can even be used to make predictions and guide further work. This paper presents Perceive, a system for data-mining a version repository and presenting information on the evolution of a project over the course of its development, from inception through to maintenance. This information is presented both in textual/tabular formats and via a variety of visualisations, all of which can be customised dynamically to best suit the user and the task at hand. The paper concludes with a case study; the system is applied to a series of projects from a university second year group-based software development module. This case study evaluates what benefits instructors can gain from repository analysis when assessing the projects, which maps to the benefits that would be gained by maintainers working on commercial projects. To further evaluate Perceive, it is also applied to some mature, open source projects and the results are compared to those from the students’ projects.

2 Related Work

Data mining of version repositories to analyse project change is not a new concept. Gall et al [GJKT97] created a database of changes to a large software project, characterising various aspects of the project and discovering differences in the evolution of various modules, going so far as to suggest candidates for restructuring or reengineering. Weissgerber et al [WD05] have presented a method, ROSE, for using a version repository to perform impact analysis, a task typically conducted through a static analysis of source code. ROSE demonstrates that analysis of version repositories can provide useful, reliable results comparable with existing methods, but more importantly it demonstrates that historical data is a way of accessing the experience of other developers. For a maintainer with little experience of the project being developed, this access can be invaluable and can help to overcome the potential problems of poor documentation and lack of access to the original developers. Other research [Gla06], [RD04], [WMSL04] has shown that repository analysis can greatly aid program comprehension and maintenance. Studies and surveys have repeatedly shown [Kos03], [BK01], [SWM00] that visualisation tools are an invaluable aid to program comprehension and software development, but that care must be taken to ensure that the visualisations employed are relevant and intuitive to the user. Other research has demonstrated that the manner in which a visualisation is deployed is as important as the tool itself [OBM05]. The sheer amount of information to be presented in the source code of a typical project can

Proc. Software Evolution 2007 2 / 10 ECEASST be immense, and this is ampliﬁed when attempting to visualise multiple versions of that code. To overcome this, ﬂexible, navigable visualisations are employed. A number of methods can be used to focus on some areas of the code while collapsing or removing others [JY04], [PC05], but these can fail if the user is not familiar with the topology used.

3 Perceive

Perceive is a system and a proof-of-concept tool for analysing version repositories and extracting useful information from them that might not otherwise be available. This section details the methods and visualisations Perceive employs to generate and present this information.

3.1 Analysis An important aspect of Perceive is that a subset of revisions can be selected for analysis and compared with the overall set. This subset can be selected based on a range (not necessarily contiguous) of revisions, or by selecting one or more developers. For example, someone using Perceive might only be interested in the set of revisions from a single developer between two dates, or of all developers from one team for the duration of the project. The first function Perceive shows is the project summary, which shows information including the start and end dates of the project, project duration, the number of files, users, revisions and changes, the number of messages (and the message-revision ratio), as well as some metrics on the number of changes per revision, such as mean, median, minimum and maximum. If a revision subset is selected, then each of these items is accompanied by the same measure for the selection, as well as the percentage the selection is of the total. This makes it trivial, for example, to get an overview of a single developer’s contribution to the project. This functionality allows a maintainer to quickly understand the overall form of a project. Next are two breakdowns of revisions times. Firstly, the revision times are aggregated by the hour the revision was made in. This enables developers to see at what times of day activity takes place. Secondly there is a grouping of revisions into days, which enables developers to chart how many revisions or changes were made across the lifetime of the project (or the selected section). Timeline analysis is a feature more relevant to project managers than to maintainers, but it has some benefits to program comprehension. The ability to determine where activity has been concentrated, or where development has perhaps been rushed will indicate areas of code of more interest to a maintainer. Factors such as a spike in the number of changes per day or an increase in “out of office hours” work could lead a maintainer to find more problematic code. Next is the Impact Analysis section. This allows the user to select a file and Perceive will suggest other files which may be related, indicating that if the user is changing the selected file, they may wish to change these files as well. This system is similar - but more lightweight - to ROSE, developed by Weissgerber et al [WD05]. Like ROSE, Perceive provides “support” and “confidence” with each suggestion. Support is the number of revisions that the selected file (A) and the suggested file (B) both appeared in, while confidence is the ratio of “Appearances of both A and B” to “Appearances of A”. Obviously, if A only appears in one revision then every other file changed in that revision will be given a confidence of 100%. To counter this, Perceive

3 / 10 Volume X (2007) Improved Program Comprehension with RCS Repository Analysis allows users to specify threshold levels for both support and confidence. Like ROSE, Perceive can merge consecutive revisions if they are from the same user and occur within a specific time period - this can help to create additional links between files that might have otherwise been omitted. The impact analysis carried out by Perceive is lightweight compared to ROSE - it can only work at the file level, while ROSE can give suggestions for changes to individual code entities. On the other hand, Perceive is entirely language agnostic and can find links between any types of files without having to know how to parse them. Also, the ability to restrict the impact analysis to data from a subset of revisions or users is unique to Perceive and provides an additional layer of analysis. For various reasons, a maintainer may want to ignore data from certain users (perhaps to restrict suggestions to data gained from the developer most experienced with the affected files) or time spans (for example, in the case of the introduction of new development practices, a maintainer may want to use data from that moment onwards).

3.2 Visualisation

As well as the textual and tabular information presented so far, Perceive also generates a number of visualisations which can be manipulated or explored by the user.

3.2.1 Modiﬁed Icicle Plot (MIPVis)

As discussed previously, one major problem with visualising a software project is the amount of data to be presented. Allowing a user to view an entire project at once and focus on various areas of it is an invaluable feature, and can be made possible by segregating all of the files in a project into groups by some grouping or clustering algorithm and presenting them in an icicle plot [BN01]. The obvious method for grouping files is by creating a hierarchy based on directory structure. Other, more useful or relevant mechanisms may exist, but this method has the advantage that the topology it creates is immediately familiar and accessible to the user and maps directly to his understanding of the project. Perceive uses a horizontal, colour-coded icicle plot to present the project. Each file and group of files is represented by a block, which can be expanded or collapsed as desired. This ability for users to navigate the visualisation ensures that the entire project can be visualised at once while reducing the problems of scale by allowing the user to focus in on the areas relevant to them. When a file is selected the visualisation performs an impact analysis of a change to that file and highlights all other files visible that will be affected (see Figures 1(a) and 1(b)). This highlighting is based on the confidence of the suggestion, so a slight effect will have a lighter shading and will not stand out as much as a strong suggestion with a heavy shading. As well as highlighting files, each group box that is visible but has not been expanded (“leaf” groups) will be shaded based on an aggregate of the analysis of all files contained within it. This enables the user to easily see effects that may happen in unexpected areas of code, without having to expand the whole project to find them. As with all other areas of Perceive, the MIPVis can be constrained based on the selection of users and revisions, so the impact analysis can be limited to the user’s choices.

Proc. Software Evolution 2007 4 / 10 ECEASST

(a) The root of a MIPVis. (b) A MIPVis with a ﬁle selected. Figure 1: MIPVis

3.2.2 The Radial Visualisation (RadVis)

While the MIPVis allows a user to view an entire project, navigating to areas of interest, it is also useful to be able to have an overview of the whole project at once, with nothing collapsed or hidden. By exchanging detail scale, the Radial Visualisation displays the project as a graph with its nodes arranged in concentric circles. The nodes are the ﬁle groups, radiating out from the root group, and the ﬁles exist as children of their parent groups. At each “level” in the graph, nodes are given a “slice” of the graph proportional to their total size, which is calculated based on the number of descendants (see Figure 2(a)).

(a) RadVis, centred on the root directory. (b) The “net” shows inferred relations between ﬁles. Figure 2: RadVis

The nodes are connected by two sets of edges. Firstly, and most simply, the topological links are drawn (linking groups to their children); secondly links are drawn between files using the same relational method as the MIPVis (see Figure 2(b)). This allows a full, project wide visualisation showing the entire structure of the project, and all the significant links between files. The visualisation has some interaction - users can select specific nodes, which displays their name and highlights all of their links (see Figure 3(a)). Secondly, each component (files, groups, radial edges and relational edges) is optional, and can be drawn or hidden at will.

5 / 10 Volume X (2007) Improved Program Comprehension with RCS Repository Analysis

The most important form of interactivity however is that when a selection of users or revisions is made, instead of restricting the visualisation to just that selection, each group is shaded based on the selection’s contribution to that group (see Figure 3(a)). So if a single user is selected it becomes immediately obvious which areas of the project they worked on, and how much. Alternatively, if a range of revisions is selected it is easy to see how much of the project was affected by that range.

(a) A project with no selection made. (b) A subset of developers selected. Figure 3: RadVis: The effects of selecting a subset of developers on the visualisation.

The RadVis is extremely useful in gaining a broad understanding of the links between various areas of the project - the impact analysis “net” clearly shows areas that are closely linked, and its absence shows areas that stand alone. This is useful for both maintainers and developers, especially in a distributed development environment such as cross-site collaboration.

3.2.3 The Flow Visualisation (FlowVis) Both the MIPVis and RadVis show only a single version, or an aggregate, of the project being visualised, trading information on evolution for topology. In other words, there is no depiction of change or project flow in the previous visualisations, but the project structure is more readily apparent. FlowVis addresses this by providing a display that reduces the emphasis on topology in favour of showing every revision of the project. The model is simply a 2D grid, with the X-axis as the files and with the Y-axis as the revisions. Each point on the grid is colour coded depending on the state of that file in that particular revision - absent, present, created, deleted, copied or changed (see Figure 4(a)). Further colour coding is used if a range of revisions or developers is selected. In this case, any revision not included in the selection is dimmed, highlighting the selection in the visualisation. If the user selects a code group (a directory) then all files (or entities) within that group are highlighted (see Figure 4(b)). This two-way selection allows a very quick overview of the project and what contributions were made where, when and by whom. An obvious drawback of this visualisation is that it can quickly become cumbersome - a project that has seen years of active development is likely to have several thousand revisions and files. This, by necessity, makes FlowVis images very large - too large for an average monitor. Coupled with the fact that a single pixel is a single data point, it cannot easily be scaled down. A possible solution to this is to restrict the ranges drawn, perhaps using only a subset of files, or a specific

Proc. Software Evolution 2007 6 / 10 ECEASST

(a) No selection made. (b) A selection of developers highlighted. Figure 4: FlowVis

time span.

4 Case Study and Evaluation

4.1 Software Engineering Group Project (SEG)

As part of its second year Software Engineering course, Durham University Computer Science Department includes a software engineering group (SEG) project [BD02]. In past years this has been limited to a Durham students, but recently it has partnered with Newcastle University. This two-campus project creates groups which include students from both universities, requiring much more use of collaboration technology and practices[DD06]. For the 2006/07 projects there were twelve teams, each comprising a number of students mixed between Durham and Newcastle universities. To aid in collaboration during the implementation phase of the project, each team was supplied with a SubVersion repository, use of which was not mandated or compulsory. Perceive is applied to the SEG repositories as it would be by an assessor or instructor, with an emphasis on program and developer comprehension, analogous to the use of the system by maintainers and managers.

4.2 Real-World Projects

Many open source projects use SubVersion as their revision management system and a few have made complete dumps of their repositories available for public download - two such projects are Putty (http://www.chiark.greenend.org.uk/˜sgtatham/putty/) and CapiSuite (http://www.capisuite.de). Both of these projects are mature and developed by experienced programmers, and so provide a suitable basis for comparison with the smaller, less experienced SEG projects.

7 / 10 Volume X (2007) Improved Program Comprehension with RCS Repository Analysis

4.3 The SEG Case Study 4.3.1 Use of SubVersion A feature of SubVersion is the ability to leave a message with each revision, giving other users an indication of what was changed. Putty and CapiSuite have a 100% message/revision ratio - every single revision, no matter how small, has a message attached. This behaviour is typical for mature projects and provides a useful form of documentation. In SEG projects however, the average ratio was a mere 31%. Proper use of revision control systems, especially in a distributed development environment is vital, as the message logs can facilitate more rapid program comprehension, and the ability to search through the messages allows more efﬁcient maintenance.

4.3.2 Visualising SEG The visualisation tools in Perceive are designed to either improve program comprehension or perform impact analysis. MIPVis is primarily designed for impact analysis, but in the case of SEG projects it is revealed that the method being used (basing it on past developer behaviour) is ineffective over such a short time period, as there is little time to develop meaningful relationships between areas of code. However, the work done by Weissgerber et al [WD05] shows that the technique is effective in the long term, and thorough evaluation of their technique supports its use. RadVis, however, is much more useful at improving program comprehension, even on smaller projects. Even at first glance, it provides a large amount of information about the structure of a project, and simple manipulation of the revision/user selection quickly reveals which users contributed to which aspects of the project. Figure 3(b) shows a SEG project with the developers from a single site selected; a user can quickly which areas of the project that site was responsible for, and by selecting a few high-level groups their names of the affected groups are quickly determined. FlowVis provides another extremely useful analysis of workload distribution in SEG projects. Because it highlights revisions based on selections, it gives immediate and intuitive feedback on how and when work was done. Figure 4(b) shows the FlowVis for a SEG project with the developers from a single site selected. This reveals several things - how the work of one site varied over time and how that work appears to significantly outweigh the other site, but it also shows which files were most active at any given time. There are large groups of files and directories that are created, occasionally worked on, and then left for the remainder of the project. Such results could provide useful suggestions about which files to filter out of analysis and visualisations in future as they take up significant space but have little relevance to the needs of many potential users of Perceive.

5 Conclusions and Future Research

Perceive has been developed as a model for analysis and visualisation of revision control system repositories, with a wide range of applications in mind. The case study has shown that Perceive does indeed provide a number of useful methods of exploring a project and its history which are

Proc. Software Evolution 2007 8 / 10 ECEASST applicable to a range of users and tasks. Importantly, they are greatly useful in aiding program comprehension, a vital process for any maintainer. By providing insight into the development of a project as well as the current state, Perceive can help a maintainer in understanding what has led to the current version of the software. Although the case study was focussed on small, academic projects, the applications demonstrated are equally useful to commercial projects where assessors and students are replaced by maintainers, managers and developers. It is intended that future research will involve projects from upcoming SEG projects to create a pool of data large enough to draw statistically signiﬁcant results from, and also to involve students themselves in assessing the use of Perceive in their projects. Feedback from the developers will help guide the direction Perceive takes in the future as well assessing the validity of some of the assumptions made and results produced. Perceive will also continue to be used with real world projects to further guide its development and ensure that it is applicable to as many users and as many tasks as possible.

Bibliography

[Aji95] S. Ajila. Software Maintenance: An Approach to Impact Analysis of Objects Change. Softw. Pract. Exper. 25(10):1155–1181, 1995.

[BD02] L. Burd, S. Drummond. Forging Planned Inter Year Co-operation Through a Peer Mentor System For Group Work Projects. In 3rd Annual LTSN-ICS Conference. 2002.

[BK01] S. Bassil, R. K. Keller. Software Visualization Tools: Survey and Analysis. In IWPC ’01: Proceedings of the 9th International Workshop on Program Comprehension. Pp. 7–17. IEEE Computer Society, 2001.

[BN01] T. Barlow, P. Neville. A Comparison of 2-D Visualizations of Hierarchies. In IN- FOVIS ’01: Proceedings of the IEEE Symposium on Information Visualization 2001 (INFOVIS’01). Pp. 131–138. IEEE Computer Society, Washington, DC, USA, 2001.

[BR00] K. H. Bennett, V. T. Rajlich. Software maintenance and evolution: a roadmap. In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering. Pp. 73–87. ACM Press, New York, NY, USA, 2000.

[DD06] S. Drummond, M. Devlin. Software Engineering Students’ Cross-site Collabora- tion: An Experience Report. In HEA ICS 7th Annual Conference. 2006.

[GJKT97] H. Gall, M. Jazayeri, R. Klosch, G. Trausmuth. Software Evolution Observations Based on Product Release History. In ICSM ’97: Proceedings of the International Conference on Software Maintenance. Pp. 160–170. IEEE Computer Society, 1997.

[Gla06] L. Glassy. Using version control to observe student software development processes. J. Comput. Small Coll. 21(3):99–106, 2006.

9 / 10 Volume X (2007) Improved Program Comprehension with RCS Repository Analysis

[JY04] S. G. K. James Abello, R. Yusufov. Visualizing Large Graphs with Compound- Fisheye Views and Treemaps. In Pach (ed.), Graph Drawing, New York, 2004. Pp. 431–441. Springer, 2004.

[Kos03] R. Koschke. Software visualization in software maintenance, reverse engineering, and re-engineering: a research survey. Journal of Software Maintenance 15(2):87– 109, 2003.

[LR01] M. M. Lehman, J. F. Ramil. Rules and Tools for Software Evolution Planning and Management. Annals of Software Engineering 11(1):15–44, 2001.

[OBM05] C. O’Reilly, D. Bustard, P. Morrow. The war room command console: shared visualizations for inclusive team coordination. In SoftVis ’05: Proceedings of the 2005 ACM symposium on Software visualization. Pp. 57–65. ACM Press, New York, NY, USA, 2005.

[PC05] S. S. Petra Neumann, M. T. Carpendale. ArcTrees: Visualizing Relations in Hier- archical Data. In Proceedings of Eurographics, IEEE VGTC Symposium on Visual- ization (EuroVis2005). Pp. 53–60. Eurographics, 2005.

[PPBH91] S. Paul, A. Prakash, E. Buss, J. Henshaw. Theories and techniques of program understanding. In CASCON ’91: Proceedings of the 1991 conference of the Centre for Advanced Studies on Collaborative research. Pp. 37–53. IBM Press, 1991.

[PRW03] M. J. Pacione, M. Roper, M. Wood. A Comparative Evaluation of Dynamic Vi- sualisation Tools. In WCRE ’03: Proceedings of the 10th Working Conference on Reverse Engineering. P. 80. IEEE Computer Society, 2003.

[RD04] F. V. Rysselberghe, S. Demeyer. Mining Version Control Systems for FACs (Fre- quently Applied Changes). In Proceedings of the International Workshop on Mining Software Repositories. Pp. 48–52. IEEE Computer Society, 2004.

[SWM00] M.-A. D. Storey, K. Wong, H. A. Müller. How do program understanding tools affect how programmers understand programs? Sci. Comput. Program. 36(2- 3):183–207, 2000.

[WD05] P. Weissgerber, S. Diehl. Mining Version Histories to Guide Software Changes. IEEE Trans. Softw. Eng. 31(6):429–445, 2005. Student Member-Thomas Zimmer- mann and Member-Andreas Zeller.

[WMSL04] X. Wu, A. Murray, M.-A. Storey, R. Lintern. A Reverse Engineering Approach to Support Software Maintenance: Version Control Knowledge Extraction. In WCRE ’04: Proceedings of the 11th Working Conference on Reverse Engineering (WCRE’04). Pp. 90–99. IEEE Computer Society, 2004.

Proc. Software Evolution 2007 10 / 10 ECEASST

Refactoring for Performance: An Experience Report

Matthias Rieger1 and Bart Van Rompaey1 and Bart Du Bois1 and Karel Meijfroidt1 and Paul Olievier1

1 [email protected],[email protected],[email protected], http://www.lore.ua.ac.be/ Lab On Reengineering University of Antwerp, Belgium

2 [email protected],[email protected] Access Network Division Alcatel-Lucent Belgium

Abstract: Object-oriented implementation techniques are highly debated in the embedded world, as they are said to be memory and performance hungry. This paper reports about a pilot project where the evolution of a C++ subsystem was threatened by the lack of performance. We identiﬁed some speciﬁc parts of the system that were contributing the most to the memory overhead and which had the least motivation to be represented by objects. Using a structured approach we refactored these objects into basic types, resulting in a 51% reduction in memory footprint as well as a startup time improvement with 33%. Keywords: performance anti-patterns, refactoring, object-orientation

1 Introduction

The world of embedded software with its severe constraints of memory and runtime performance has long been a strong domain for “lower level” languages like C which allow tight control over these aspects. The break through of object–oriented programming into this domain has been hindered because of its reputation of being memory and performance hungry. With time, however, the OO paradigm, especially in the “better C” that is C++, is finding its proponents also in this world. We have found, however, that an overeager application of OO design principles can indeed lead to the above mentioned problems. In this paper, we describe a pilot project where an OO transport system of a network access node that was threatening to become obsolete due to its memory footprint and consequential slow startup, was “saved”. We selectively refactored certain key parts of the object representation, moving from a fully OO design to a hybrid solution which keeps objects and primitive data side by side. This paper is structured as follows. Section 2 introduces related work. In Section 3 we refine the pilot project’s context and motivate the problem statement. Next, in Section 4 we describe the structured approach we followed while defining and isolating the problem as well as the actual activities undertaken to salvage the system. We discuss the lessons learned and draw conclusions in Section 5.

1 / 9 Volume X (2007) Refactoring for Performance

2 Related Work

Chung et al. proposes a decomposition of performance in a soft-goal interdependency graph [2], in accordance with the characteristics of efﬁciency suggested by ISO 9126 [7]. Yu et al. and Andreopoulos propose the use of such soft-goal interdependence graphs to guide refactoring towards improved performance without sacriﬁcing simplicity [13, 1]. Smith and Williams have published a series of papers on the subject of Software Performance Anti-Patterns [9,10,11]. They enlist the originating problems and indicate the role of refactoring in the associated solutions. Temmerman et al. illustrate a refactoring scenario that optimizes the energy consumption of embedded systems by removing redundant data and their accesses as well as moving methods closer to the data [12]. Demeyer demonstrates that refactoring large conditionals into polymorphic calls may improve the performance in C++ programs [4]. Overbey et al. suggest to automate hand optimizations common in supercomputer programming by a refactoring engine, and to defer their execution until build time, in order to preserve the maintainability of the original code base [8]. Examples of these refactorings are the unrolling of loops, and the optimization of data structures based on the machine’s cache size.

3 Context

Our pilot project consist of a 130 kSLOC C++ subsystem managing configuration parameters for network lines. The system is implemented in a distributed fashion; middleware ensures communication between the separate processors. A framework has been developed which provides middleware services, among other things like memory management, and persistency. A home grown code generator turns specifications into framework classes that can be used by client code. One design goal for this framework was to make every data element look uniform so that data manipulation, be it serializing for communication or persistency, could be handled in a common manner (simplifying, for example, the code generator). This especially meant to represent primitive types as objects too as illustrated in Figure 1. In addition, each such primitive type class has an associated fixed or variable-length array class, depending on how the primitive type is being used in the system. One of the system’s main tasks is to load the configuration data in the form of spectrum profiles from the database at startup, and distribute them to the remote extensions. In the current implementation, the chosen representation is a hierarchical object tree. The spectrum profile and its parts are described in a simple specification language, the code generator creates the framework classes. Once instantiated they are then able to be sent over the network immediately. The system has been around for three years and is already dangerously close to exhausting the memory and runtime reserves. New requirements ask for the number of spectrum profiles being doubled. A complete rewrite is necessary if we cannot find a way to keep the system alive by making it perform under the new requirements.

Proc. Software Evolution 2007 2 / 9 ECEASST

Figure 1: Part of the primitive class hierarchy that derives from ULong.

4 A Structured Approach

In this section we work through the individual steps of the pilot project, from the selection of the problem to the concrete refactoring measures taken to solve it. We focus on the design aspect of choosing an object-oriented representation for the spectrum proﬁle data.

4.1 Getting a Speciﬁc Problem Description We learnt about the problem using a two pronged approach: we performed static problem detection analysis on the source code, and we did an experience-based assessment by interviewing the current maintainers of the system. What the static analysis could not deliver, i.e. information about performance, was provided by the “war stories” of the maintainers [5, 3]. Their awareness of the problems came from comparisons with other subsystems performing similar tasks in a more efﬁcient way, and also from hands-on debugging, revealing the many levels of indirection that the service implementations exhibited. Both information sources led us to believe that an nondiscriminatory use of objects was to blame for much of the performance problems. Consequently we looked for ways in which to remodel parts of the data structure without objects.

4.2 Identifying Improvement Opportunities We employed two criteria while looking through the spectrum proﬁle data structure to ﬁnd parts which could be improved:

• ”No substantial new functionality” is associated with the data. Mere data holders that do not provide operations—beyond getters and setters—on their members will only introduce an additional level of indirection. Since they do not make use of object-oriented features, remodeling them using basic types would only marginally affect the client code.

3 / 9 Volume X (2007) Refactoring for Performance

Note that we disregard the inherited framework services here. We needed to sacriﬁce some of the framework’s uniform interface to achieve the required performance enhancements.

• A large number of these objects must be present in the system. Only then will refactoring them contribute substantially to the reduction of the memory overhead.

Using these criteria we identiﬁed two such parts of the spectrum proﬁle. We explain for each case what the proposed restructurings consists in.

Wrapped Primitives. The leaf nodes of the spectrum proﬁle object hierarchy are instances of a set of Wrapped Primitives classes which each encapsulate a single data member of a basic type. The only operations that Wrapped Primitives offer are the ones that already exist for the basic types Wrapped Primitives are the basis of all complex objects. They are therefore abundantly present in the object hierarchy (1500 objects of this kind need to be created at startup). As such, this design resembles the Excessive Dynamic Allocation performance anti-pattern [9], yet it is different as (i) the Wrapped Primitives are mostly instantiated at startup; and (ii) due to the nature of the contained data other solutions than e.g. an object pool are possible. We call the observed performance anti-pattern Redundant Objectiﬁcation. As refactoring, we propose to revert the Wrapped Primitives into primitive data types again, freeing up the overhead per instance of object alignment, and virtual table pointer space. Most operations on the object such as access and calculations are immediately or easily supported on primitives as well.

PSDShapes. The PSDShape is a set of configuration data for an external device. The class representing the PSDShape does not contain any additional operation. In fact, the PSD- Shape data is only passed from the database to the external device after a short inspection step, which needs to determine whether the data had changed with respect to a previous instance. The semantics of the individual fields of the data are therefore not needed. A PSDShape is the largest part of a spectrum profile (it’s about 40 times bigger than the average data member), and is contained more than a dozen times in each profile. If we can reduce its size, we achieve a significant impact on the memory overhead. The PSDShape problem is a good illustration of the design space optimization challenge in terms of memory footprint and number of data accesses that Temmerman et al. pose: laying out the data structure in memory (called Associative Array) offering direct data access versus a Sequence characterized by minimal storage [12]. Realizing that the direct data access that is offered by the old layout is not really needed by the current system, we can emphasize the memory-optimal side of the equation without encountering drawbacks. This is another example of the Redundant Objectification anti-pattern. We propose to replace the object representation of the PSDShapes with a simple byte array. Comparison of two arrays, the only operation performed on PSDShapes, is readily done with a simple iteration over all fields of the array.

Proc. Software Evolution 2007 4 / 9 ECEASST

In both cases, the framework services (serialization, ...) will have to be provided by independent functions for the now primitive data types. This implies to move the implementations, that were formerly part of the wrapper classes, to global functions.

Figure 2: A comparison of the memory allocated for an instance of the basic type int and the wrapped primitive provided by the framework.

4.3 Estimating Effort, Risks and Gains 4.3.1 Effort We split up the effort estimation between refactoring (i) the code generator and (ii) the application code. The code generator is an central element in the use of the framework as about 75% of the code of the system is generated. To introduce primitives, the internal of the generator had to undergo a complex structure change: representing primitive and complex types instead of only complex ones. As the behavior of the generated code needed to remain unchanged, we estimated that testing would require a considerable effort as well. As the Wrapped Primitives were a key part of the framework and form the leaf nodes of the profile data hierarchy, they were used extensively in the non-generated application code. In an attempt to get a quantification of the modification effort, we located about 3100 occurrences of the Wrapped Primitives names in the source code using common instance names in regular expressions (e.g. LineId instances were typically named lineid or tmpLineid). The assessment confirmed our expectation that the objects were only used in a few categories: data access and modification, and the framework services. Next, these occurrence categories were fit into a model estimating required effort.

No change required. Since the objects were designed to behave like primitives and because we typedef’d the names of the wrapper classes to the names of the primitives types, many occurrences didn’t require any change. 93.4% of occurrences, such as declarations of local variables and attributes as well as formal parameters fall under this category.

Trivial, repetitive changes. An example of such a change is refactoring a method call on the original object into a function call with the primitive as ﬁrst parameter. A large part of these changes could be automatically performed. This category represents about 5.5% of the occurrences.

5 / 9 Volume X (2007) Refactoring for Performance

Complex changes. In a limited number of cases (1.1%), classes inheriting from the same Wrapped Primitive override base class operations differently. When reverting to primitives, we had to relay all original framework calls to correct, corresponding function implementations generated by the adapted code generator.

4.3.2 Risks The restructuring would involve complex actions on the—to us—unfamiliar code generator. The generator itself was not covered with any tests, except indirectly by the subsystem tests covering the generated code. By concentrating on the generated code, the best exhibition of the generator’s behavior, and comparing it with the previous output after each restructurung step, we were able to quickly establish test coverage. For the application code, we had to be especially careful with changes in the complex category. In those cases we had to replace the original method invocation with a call to the right replacement function, which required understanding of the context. Especially overloaded operators, a C++ construct frequently used in this subsystem, had to be checked against the standard primitives operator implementation. Three Wrapped Primitives fell under these conditions, requiring emulation of the original functionality and corresponding adaptation of client code.

4.3.3 Gains Before proceeding to the actual restructuring, the gain was estimated for both memory footprint and startup time. For the memory footprint, we relied on a static, quantitative analysis of objects in memory. For every node in the object hierarchy the size in number of objects as well as in bytes was calculated, based on the memory model of Figure 2. The results were compared with a target design that did not contain the complex objects any more. A part of the estimation can be seen in Table 1.

Parameter Name Parameter Type Old Size New Size ProfileIndex Int 8 4 ProfileName String 48 48 ProfileScope Scope 12 8 ProfileStatus Int 8 4 LineOpMode OpModes 20 20 LineDownstream Int 8 4 LineCarrierDownstream Array Uchar 524 76 ...... Total 2236 828 Table 1: Extract of the Estimation of Memory Reduction in the CommonData part of a spectrum profile. Size is given in bytes.

In order to estimate the gain in startup time, which was of a lesser concern to us, we calculated the number of constructor invocations. This is a simplistic model, and ultimately was not very accurate in predicting actual gain. The estimated improvement of 81% less memory was however

Proc. Software Evolution 2007 6 / 9 ECEASST deemed worthwhile to give a go ahead for the restructuring.

4.4 Refactoring Steps 4.4.1 Testing the Code Generator

We automated the test environment for the code generator as much as possible: After having extracted from the makeﬁles all the conﬁgurations in which the generator was run during a build, we could script execution, collection of results, comparison with output from the previous step, and check-in into a versioning system in case no difference was detected. Many of the smaller steps would not change the produced code at all, which let us assert the unchanged behavior of the generator with diff. The restructurings that were affecting the produced code were, in general, resulting in differences that could be captured with one or two patterns. These were easily recognizable when browsing the differences with a visual diff viewer, even with the approximately 70’000 lines of generated code. After the correctness was asserted, a check-in was triggered by hand.

4.4.2 Changing the Code Generator

We changed the code generator in two phases: in a ﬁrst phase, we employed “refactor to understand” [5] in various cleanup actions. We, for example, increased the information hiding of the generator’s class hierarchy by abstracting oft-repeated idioms. Although these actions were not strictly necessary to perform our restructuring, we found the selective increase of program understanding invaluable [6]. Since most of the cleanup steps were proper refactorings, i.e. they did not alter the behavior of the generator, we could rely completely on our simple testbed to determine the validity of our actions. Next, we proceeded into the actual refactoring operation splitting up the class hierarchy. Ver- sioning often, especially before a complicated refactoring step, proved to be valuable in cases where a wrong turn was taken in the restructuring. A detailed record of all steps including descriptions will also help to give explanations to maintainers who know the code from before, especially if the change has been of such a thorough manner which does not leave much of the original code untouched, and makes a simple before-after comparison useless.

4.4.3 Refactoring the Application Code

In order to get confidence in our effort estimation model, we started with refactoring the Wrapped Primitives that occurred the least, and refactored gradually until all of them were replaced. Al- though this task of manual refactoring the client code initially seemed a daunting task, it proved to be a lot easier and efficient than initially indicated by the calculated frequency of occurrence. First of all, the analysis pointed out that most of the occurrences required either no or only trivial changes. Secondly, many occurrences required similar changes, which were either automatable or easy to repeat after the first application. For the PSDShapes, we simplified the member-by-member comparison to a “blind” array comparison, where each field is compared to its corresponding field in the partner array. The

7 / 9 Volume X (2007) Refactoring for Performance comparison was done fully in the application code, which meant that we did not have to touch the code generator at all.

4.5 Results

Measuring the performance of the system before and after we assessed the following improvements:

Memory Reduction: The memory taken up by a spectrum proﬁle was reduced by 51%.

Startup time Reduction: The startup time per spectrum proﬁle could be reduced by 33%.

Both of these improvements contributed to the prolonged lifetime of the system, making a full re–implementation of the middleware framework unnecessary.

5 Conclusions

In this pilot project we were confronted with a system that suffered from a performance problem typical for embedded software, similar to and illustrating earlier performance anti-pattern descriptions. We contribute an anti-pattern named Redundant Objectification. We employed a structured approach to identify and tackle these performance problems. Start- ing from a generic problem description, we used a combination of developer interviews and static analysis to identify the most beneficial areas of improvement. Note that mostly due to the deep knowledge that we could tap into by asking developers familiar with the system, it was not necessary to employ dynamic analysis to locate the center of the problem. We subsequently proposed a more efficient design and assessed the expected gain as well as the effort and possible pitfalls of the refactoring operation. This allowed us to select and apply a development strategy ensuring the behavior preserving nature of the restructuring. As a contribution to the debate about using object technology in embedded systems we state that performance considerations must be heeded when dealing with the constraints of embedded systems. It may become necessary to relinquish the elegance and simplicity of a uniformly object–oriented design and seek a hybrid objects–and–primitives solution. This requires detailed knowledge of the problem domain, to decide where the tradeoff of improved performance vs. the hassle of mixing programming paradigms is most favorable. An interesting question in this respect is to ask where the cohesion of the data–behavior combination represented by an object is weakest, due to either the simplicity of the data structure, the lightweightness of the behavior half, or both characteristics combined.

Acknowledgments: This work was executed in the context of the ITEA project if04032 entitled Software Evolution, Refactoring, Improvement of Operational&Usable Systems (SERIOUS) and has been sponsored by IWT, Flanders.

Proc. Software Evolution 2007 8 / 9 ECEASST

Bibliography

[1] B. Andreopoulos. Satisﬁcing the conﬂicting software qualities of maintainability and performance at the source code level. In WER - Workshop em Engenharia de Requisitos, pages 176–188, December 2004. [2] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos. Non-Functional Requirements in Software Engi- neering. Kluwer Academic Publishers, 2000. [3] C. Del Rosso. Continuous evolution through software architecture evaluation: a case study. Journal of Software Maintenance and Evolution: Research and Practice (JSME), 18(5):351–383, 2006. [4] S. Demeyer. Refactor conditionals into polymorphism: What is the performance cost of introducing virtual calls? In Proceedings of International Conference on Software Maintenance, pages 627–630, 2005. [5] S. Demeyer, S. Ducasse, and O. Nierstrasz. Object-Oriented Reengineering Patterns. Morgan Kaufmann, 2002. [6] B. Du Bois, S. Demeyer, and J. Verelst. Does the ”refactor to understand” reverse engineering pattern improve program comprehension? In Proceedings of CSMR’05, pages 334–343, Manchester, UK, 2005. [7] ISO/IEC. 9126-1:2001 software engineering - product quality - part 1: Quality model, 2001. [8] J. Overbey, S. Xanthos, R. Johnson, and B. Foote. Refactorings for fortran and high-performance computing. In Second International Workshop on Software Engineering for High Performance Computing System Applications, Colocated with ICSE, 2005. [9] C. U. Smith and L. G. Williams. Software performance antipatterns: Common performance problems and their solutions. In Int. CMG Conference, pages 797–806, 2001. [10] C. U. Smith and L. G. Williams. New software performance antipatterns: More ways to shoot yourself in the foot. In Int. CMG Conference, pages 667–674, 2002. [11] C. U. Smith and L. G. Williams. More new software antipatterns: Even more ways to shoot yourself in the foot. In Int. CMG Conference, pages 717–725, 2003. [12] M. Temmerman, E. G. Daylight, F. Catthoor, S. Demeyer, and T. Dhaene. Optimizing data structures at the modeling level in embedded multimedia. Journal of Systems Architecture (Elsevier JSA), 53(8):539–549, August 2007. [13] Y. Yu, J. Mylopoulos, E. Yu, J. Leite, L.L.Liu, and E. D’Hollander. Software refactoring guided by multiple soft-goals. In The First International Workshop on REFactoring: Achievements, Chal- lenges, Effects colocated with WCRE, 2003.

9 / 9 Volume X (2007)

ECEASST

A case study in model refactoring to improve component-based software architecture

Khalid Allem† ‡

† Service de Génie Logiciel, Université de Mons-Hainaut ‡ SmalS-MvM/Egov, Rue du Prince Royal 102, 1050 Bruxelles, Belgique

Abstract: In model-driven engineering (MDE), the activity of model refactoring for J2EE applications is very important for improving quality and decreasing complexity. Architecture refactoring aims to improve the structure of a sotware architecture while preserving the external behaviour and other quality characteristics such as adaptability, understandability and performance. In this short article we introduce the concept of the refactoring software architecture using UML 2 component diagrams and basing on our industrial experience feedback, we shed more light on the current state-of-the-art in this important research domain, and we propose a case study showing architecture refactoring for improved maintainability, performance, and security.

Keywords: architecture refactoring, Component-Based Software Architecture, UML 2 component diagrams

1 Introduction In recent years, Model-Driven Engineering (MDE) has attracted considerable interest from both the research and industry areas, and it is fast becoming the principal paradigm in Software Engineering. MDE is an approach to software development where the primary focus is on models. With model driven engineering, software is not built from scratch, but rather by making use of existing reusable models. Models are built representing different views on a software system, a model is an artefact that conforms to a metamodel and represents a given aspect of a system. One of the most important operations in MDE is model transformation, a model transformation language is used to define how q set of source model is visited and transformed in a set of targets models. One essential technique to evolve and transform models is model refactoring. This technique restructures a model while preserving its behavioural properties. The aim is to improve the models by making them more generic, modular and reusable.

One of the emerging trends in MDE is the use of UML for system specification. Even if UML provides two kinds of physical diagrams, we present in this paper two essential diagrams to describe the physical relationship among software and the various components in a system and their dependencies: deployment and component diagrams. In the present work we present the concept of what we call “Architecture Refactoring”. In Architecture Refactoring we refactor the architecture itself, the aim is to improve the software evolution process and to prevent the decay of the system architecture.

2 / 8 Volume X (2007)

Architecture refactoring

2 Preliminaries Two essential concepts to evolve and transform architecutre are components and architecture refactoring: . A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces [OMG] . Architecture refactorings restructure the architecture while preserving its behavioural properties. The aim is to improve the architectures by making them more generic, modular and reusable, in this context, it is necessary to ensure that the refactored architecture preserves the behaviour oh the original architecture.

This paper deals with the problem of software evolution and the decay of software architectures. It presents our industrial experience feedback, which assists software evolution in its crucial part, the architecture refactoring. The assistance is performed for both technical and organizational aspects of the software evolution.

3 Architecture refactoring In this section we give a definition of software architecture in the context of the Rational Unified Process: an architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (Kruchten, Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999).

The size and the complexity of software systems has increased significantly since the beginning of the software industry. Because of this, it is crucial for any refactoring process to provide techniques to restructure a software architecture while preserving its behavioural properties. The aim is to improve the architectures by making them more generic, modular, and reusable. In this context, it is necessary to ensure that the refactored architecture preserves the behaviour of the original architecture.

Proc. Software Evolution 2007 3 / 8

ECEASST

In this paper, we introduce on several set of architecture refactorings we have experimented with and we give our feedback in the form of the following ideas:

Partition Responsibilities If a component or subsystem has too many responsibilities, partition the component or subsystem into multiple parts, each of which having semantically related functionality. Extract Service If a subsystem does not provide any interfaces to its environment but is subject of external integration, extract a service interface. Introduce decoupling layer If components directly depend on system details, introduce decoupling layer(s). Eliminate dependencies Reduce direct and wide-spread dependencies of parts in a whole part setting by introducing a central runtime component that centralizes dependency handling with dependency injection Rename Entity If entities have unintuitive names, introduce an appropriate naming scheme. Introduce hierarchies If several entities are only variants of a particular entity

4 First case study: architecture refactoring using component diagram

In this section, we shed more light on how to create business components. This has a number of benefits: . Business components enable us to divide presentation content from application logic. . Business components promote code reuse. We can write a library of useful subroutines and functions, package them into a business component, and reuse the same code. . Business components are compiled. . Business components can be written in multiple languages. . Business components enable us to build multitiered Web applications. For example, we can write a set of components that encapsulate your business logic.

A component diagram shows the various components in a system and their dependencies. A component represents a physical module of code. A component is often the same as a package, but it may be different, since components represent the physical packaging of code.

Situation before refactoring:

A motivating example is depicted in figure 1. A component contains two groups: business domain components and data model components, as shown next:

. Business domain components: are components that represent feautures of different business rules, business domain components are the most reusable business components.

4 / 8 Volume X (2007)

Architecture refactoring

. Data domain components: are components that collect and manage it, data model components are not as reusable as business domain components.

Application A Application B Application C

Figure 1. Business component before refactoring

The disadvantges of this architecture are:

Bad cohesion usually begets bad coupling, and vice versa, The interfaces IBusiness and IDao are related to the same component, but they do not form a coherent unit. So if one of the interfaces is modified, the component changes version. In this situation it is difficult to know if the front-end applications are impacted or not. Consequently, all the applications must have a maintenance. This situation can become embarrassing in the future.

Proc. Software Evolution 2007 5 / 8

ECEASST

Situation after refactoring :

A motivating example is depicted in figure 2. A diagram contains two business domain components and one service model component, as shown next:

Application A Application B

Application C

Figure 2. Business component after refactoring

The general idea of this refactoring is: to remove the interface "IDao" and to transform it into several interfaces "business services". The advantages of this architecture are: to give functionalities more conceptual than technical, and consequently to decrease the coupling between the applications and the data base,

6 / 8 Volume X (2007)

Architecture refactoring

Table of comparison :

Task Before refactoring After refactoring If we change a business rule all the components will be only component A will be in the component A impacted by this change impacted by this change without influencing the other components b if we test the confirmity of all the components will have only component A will be this change to be tested have to be tested if we deploy the component all the applications A, B and only application A will have C will have to be deployed to be deployed too

5 Conclusion The goal of the work presented in this paper was to develop a methodology for supporting the architecture refactoring of software systems. In this paper we presented our experience feedback in architecture refactoring using a concept of business component for our case study, by following the UML Component diagram. With our refactoring, the software architecture obtained is more fexible, testable and manageable, and it reduces the effort needed in the situation before refactoring.

6 References Correa A.,Werner C., « Applying Refactoring Techniques to UML/OCL Models », UML 2004 - The Unified Modeling Language, vol. 3273 of Lecture Notes in Computer Science, Springer- Verlag, p. 173-187, 2004. Du Bois B., A Study of Quality Improvements by Refactoring, PhD thesis, Universiteit Antwerpen, Belgium, September, 2006. Fenton N., Pfleeger S. L., Software Metrics: A Rigorous and Practical Approach, second edn, International Thomson Computer Press, London, UK, 1997. Fowler M., Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999. Kerievsky J., Refactoring to patterns, Addison-Wesley, 2004. Lämmel R., « Towards Generic Refactoring », Third ACM SIGPLAN Workshop on Rule-Based Programming, ACM Press, 2002. Markovic S., Baar T., « Refactoring OCL Annotated UML Class Diagrams », Proc. Int’l Conf. Model Driven Engineering Languages and Systems (MoDELS 2005), vol. 3713 of Lecture Notes in Computer Science, Springer, p. 280-294, 2005. Mens T., « On the use of graph transformations for model refactoring », Generative and transformational techniques in software engineering, vol. 4143 of Lecture Notes in Computer Science, Springer, p. 219-257, 2006. Mens T., Taentzer G., Runge O., « Analyzing Refactoring Dependencies Using Graph Transformation », Software and Systems Modeling, 2006a. Mens T., Tourwe T., « A Survey of Software Refactoring », Transactions on Software Engineering, vol. 30, n° 2, p. 126-162, February, 2004. Mens T., Van Gorp P., « A Taxonomy of Model Transformation », Electronic Notes in Theoretical Computer Science, vol. 152, p. 125-142, 2006b. Meyer B., « Applying “Design by Contract” », Computer, vol. 25, n° 10, p. 40-51, 1992. Opdyke W. F., Refactoring: A Program Restructuring Aid in Designing Object-Oriented Application Frameworks, PhD thesis, University of Illinois at Urbana-Champaign, 1992.

Proc. Software Evolution 2007 7 / 8

ECEASST

Simmonds J., Van Der Straeten R., Jonckers V., Mens T., « Maintaining Consistency between UML Models Using Description Logic », Série L’objet - logiciel, base de données, réseaux, vol. 10, n° 2-3, p. 231-244, 2004. Tahvildari L., Kontogiannis K., « Improving Design Quality Using Meta-Pattern Transformations: A Metric- Based Approach », Journal of Software Maintenance and Evolution: Research and Practice, vol. 16, n° 4-5, p. 331-361, 2004. Tichelaar S., Ducasse S., Demeyer S., Nierstrasz O., « A Meta-Model for Language-Independent Refactoring », Proc. Int’l Symp. Principles of Software Evolution, IEEE Computer Society Press, p. 157-169, 2000. van Deursen A., Moonen L., « The Video Store Revisited – Thoughts on Refactoring and Testing », Proc. 3rd Int’l Conf. eXtreme Programming and Flexible Processes in Software Engineering, p. 71-76, 2002. Alghero, Sardinia, Italy. Van Gorp P., Stenten H., Mens T., Demeyer S., « Towards automating source-consistent UML refactorings », UML 2003 - The Unified Modeling Language, vol. 2863 of Lecture Notes in Computer Science, Springer- Verlag, p. 144-158, 2003. Van Kempen M., Chaudron M., Koudrie D., Boake A., « Towards Proving Preservation of Behaviour of Refactoring of UML Models », Proc. SAICSIT 2005, p. 111-118, 2005.

8 / 8 Volume X (2007)

ECEASST

Design of Evolutionary Videogames for Special Education: A practical case of use in autistic learning process

José Luis González, Mª José Rodríguez, Marcelino Cabrera Software Engineering Department. University of Granada. Spain.

Abstract: Videogames make ideal learning tools since they provide training skills, promote independence, and increase and improve student’s concentration and attention; in addition, new concepts can be easily acquired and exercises carried out successfully. For special education students with learning difficulties, it is very important for the teacher to be able to design new learning strategies and to adapt the game to each pupil, taking into account each student’s cognitive level, skills, abilities, capabilities and needs. Our work focuses on designing games that can be adapted to each user’s cognitive level and characteristics, and that can evolve with the user according to his/her progress.

Keywords: Evolutionary software, adaptation, videogames, special education, autism.

1 Introduction The use and development of technical tools to help people with speech and communication disabilities (autism, cerebral palsy, ictus, dysphasia, etc.) is a challenge for our society since these tools offer the prospects of social and labour integration, rehabilitation and independence.

The main learning difficulties of people with special educational needs are due to their cognitive limitations or disinterest in the subject. A new method of alternative learning must therefore be used which offers mechanisms to stimulate them, to increase their attention and concentration, and focus on the children’s cognitive virtues and freeing them from the pressure of the traditional learning process.

Videogames are a direct, attractive platform for getting closer to children with disabilities, as not only do they offer new forms of human-computer and student-student interaction, but they also promote special education learning. Videogames enable knowledge to be developed through game contents and cognitive abilities are increased through play. Only in Spain, the video game industry is currently leading, in terms of turnovers, about 967 millions of euros in 2006 - Data published by Adese (Spanish Distributor’s Association and Software’s Entertainment Editors).

Many specialists educators agree on the importance of video games in the present social context [1] [2]. In the scholar context, video games have been traditionally considered as simple entertainment mechanisms to be used out of classrooms, thus missing their advantages as learning tools:

2 / 11 Volume X (2007)

Design of Evolutionary Videogames for Special Education

Scholar success: Pupils that have used video games, have increased reading comprehension capability. Cognitive abilities: Pupils train these abilities using environments discovery and creativity. Motivation: Games are an encouragement mechanism for children, they learning process easier and increase attendance considerably. Attention and Concentration: Attention and concentration are incremented to solve concrete problems due to pupils’ nature towards games.

To date, very few learning videogames have been designed for special education, and most of the ones that do exist tend to be difficult to access or to consist solely of teaching units with no game element. Computers continue to be the most used games platform rather than others with larger interaction and multimedia capabilities, and this is mainly because the driving force behind videogame companies is profitability and this would be reduced if they were to develop special and personalized games for small groups of people with different needs.

It is essential for special education to be tailored to each individual child, considering their skills and capacities, and each child must learn at their own rate of work. At the same time, the child’s integration must be improved, helping him to communicate with his fellow pupils and teachers.

Evolving techniques will be used to design a platform which allows the creation of videogames for learning and communicating, that can be personalized to each child and which can evolve as the child progresses with the game.

The second section of this paper presents various considerations about special education and videogames. Section 3 shows our method and process for creating personalized videogames. Finally, Section 4 outlines our conclusions and future lines of work.

2 Considerations about Special Education videogame’s Gameplay design Learning with special education games is based on psychopedagogical mechanisms. The game must be easy to personalize and it must allow different forms of interaction, avoiding discrimination as a result of the player’s cognitive and physical characteristics. Two main theories are considered to design this kind of videogames: “Multiple Intelligences” and “Stimulus Equivalence”.

Gardner [3] proposes the “Multiple Intelligences” theory which states that intelligence is not unique or indivisible, but can be considered as a set of abilities that can be trained. The training can be carried out using educational videogames. A person with autism, for example, is limited in his intrapersonal/interpersonal intelligence, but his logical, spatial or musical intelligences can be stimulated using a game so that his sensations, emotions or meditations can be expressed by means of association between symbols and meanings. For example, this

Proc. Software Evolution 2007 3 / 11

ECEASST occurs when an autistic child uses an AAC Tool [4] (Augmentative and Alternative Communicator). Sidman’s theories [5] of “Equivalence relationships between Stimulus” or “Stimulus Equivalence” can also be applied to the design of videogames for special education. By training explicit relationships between stimuli (direct training to the child), new implicit relationships appear which enable the pupil to learn to relate concepts with new relations that have been hidden. For example using pictographic symbols and written words (direct training) to obtain sounds (indirect training).

The relationships between stimuli are shown in Equation 1: Reflexivity (1), Symmetry (2), and Transitivity (3). Equation 1: Sidman’s Stimulus Relationships (1) An → An

(2) if (An → Bn ) ⇒ An → Bn

(3) if (An → Bn & Bn → Cn ) ⇒ An → Cn

In order to apply these theories in the design and development process of videogames we need to include some factors into the “Gameplay”. Gameplay [6] includes all player experiences during the interaction (what the player can do and how to do) with game systems. This term is used to describe the overall experience of playing the game excluding the aspects of graphics, sound, and the storyline. Some factors to be considered for Special Education game, are [7]:

To identify the player’s profile, his/her limitations and cognitive capabilities in order to choose the best multi-modal interaction mechanisms. The educational contents should be introduced into the game structure in a hidden way. The game should have its objectives as a game, and special objectives as a learning tool. Hence, the child can learn indirectly while playing. To evaluate the positive aspects that the game offers, without forgetting the negative aspects that can create vices or inappropriate conducts of the child. The game must offer feedback for each action. This feedback is focused on the cognitive need which the child must train when playing. To develop this feedback we will make use of the other intelligences as supporting tools and also of the child’s profile.

Using player's profile data we can design a correct gameplay in Special Education field. We propose a mechanism to generate and modify didactical videogames adapted to the player profile and accessible in the interaction play action, in other terms, we develop accessible videogames with a high grade of playability for children with special needs.

4 / 11 Volume X (2007)

Design of Evolutionary Videogames for Special Education

3 Our Proposal for Adaptative and Evolutionary Videogames for Special Education Our proposal arises from the alternative and augmentative communication system Sc@ut [8] which was developed by our research group. Sc@ut is a platform which enables the creation and evolution of communicators based on a hypermedia net with images, sounds and links. Sc@ut communicators are adapted to each user and run on Pocket PCs or computers. Communicators can also be used as teaching units in which the user can select the concepts requested by the teacher, concepts which have previously been programmed by the teacher to appear in the system. We have observed a series of deficiencies in Pocket PCs during the use of this communicator:

Fragility: The touch screen is very delicate, getting scratched or breaking easily. Autonomy: About 3 hours. The battery requires replacing several times a day, being this aspect a great inconvenience for children and tutors. Multimedia: The main memory is limited and consequently also the multimedia objects and user interfaces which make them not attractive to children. Price: High, around 300e, being a negative factor for parents and tutors.

Due to the limitations of the Sc@ut communicator, we cannot achieve the same learning advantages as we can with videogames. We therefore searched for a new platform to play the educational videogames and we selected Nintendo DS™ for the following reasons [9]:

Feedback: It has two screens. One of them is a touch screen which offers more interaction possibilities. Multimedia: It’s a game device with great multimedia options (sound, video and graphics) without apparent limitations of memory. Autonomy: Approximately 11 hours. Connectivity: Wireless (Wi-Fi), to communicate with other DSs and PCs Price: About 150e, much more affordable than a Pocket PC device. Durability: It is a device designed to be used by children Motivation: Other commercial games can be used as a complement, gift o reward for children.

The objective of the games that we propose is to teach various concepts. The game comprises different stages, each of which trains a different concept, and each stage is further divided into levels which describe an exercise for training concepts, incorporating new concepts that act as distractors (following the Sidman’s theory). The positive and negative stimuli or reinforcements, and the goal that must be reached in order to proceed to a higher level are also defined in each level. The interactions and feedbacks methods are designed using the best intelligences as supporting tool (Gardner’s Multiple Intelligences) to compensate the weakened intelligence (Fig. 1, learning of vowels in Spanish and food).

Proc. Software Evolution 2007 5 / 11

ECEASST

Fig. 1: Two different examples of educational videogames

In Special Education children have a different cognitive and physical spectrum, so we try to develop a special game to each one of these children. A “special” child could have an interaction different to others. We can adapt the interaction mechanism to the skills player’s profile. Other problems are the concepts to teach and to learn. For example, the autistic children have their own perception of the real world. They build the semantic of the real world using their own ideas or concepts.

The main objective is develop a videogame where the teacher could personalize the game interaction and the game concept using the player profile, and the game could evolve with the children re-adapting the concepts and the gameplay options (difficult levels, numbers of distractors, feedback…).

3.1 Evolution proposal design to videogames Based on the two-layer structure of the Sc@ut platform, we have also defined two layers to design our videogames: one is an instance of a meta-game, and the other is the platform which creates and personalizes the game. This architecture allows the separation of concerns to be considered during the design process of the videogame.

The platform includes other three layers: the meta-game, the meta-phase and the metalevel. With this meta-structure we model the behaviour and the functionality of our game engine independently of player skills or concepts to be learned.

Correspondingly, the responsibilities of each meta-structure are in the game engine are:

Meta-game: This offers concepts that the teacher can select for training with a specific child. Meta-phase: This involves the educational contents: concepts to be learned and the multimedia contents that represent the concepts. Meta-level: This allows defining educational exercises for training the concept.

6 / 11 Volume X (2007)

Design of Evolutionary Videogames for Special Education

The Meta-game layer considers two dimensions:

Accessibility: Describes the User’s Interface to each child. Accessibility options are built taking into account the player’s skill profile and disabilities to offer alternative presentations of concepts or interaction methods.

Gameplay: Defines the principal characteristics of the game considering the user profile, and the objectives and educational contents to be taught. A main character or hero is used in the game, who acts as a guide in the learning process. Each game must have goals. The learning process should be in rise, based on multi-levels or missions where the level of difficulty increases gradually. For each right action, a reward is obtained: animations, songs, videos, points, objects, and even, gifts in the real world.

Table 1 shows the artefacts or aspects that can be modified in each one of these layers. This table is completed with examples of instantiations of these aspects for the vowels game shown in Fig. 1.

Table 1: Videogames Meta-Structure

META Modifiable Aspects Instance: Vowels Game STRUCTURE Subtitles No Dialogues Yes Alternative ACCESIBILITY Voice Recognition Navigation Colors Palette Black/White Images Size Normal Meta-Game Hero Leoncio, The Lion (Engine and IU Feedback Music and Text Options) Interaction Stylus Difficulty Normal GAMEPLAY Objective Teaching Vowels Context Adventures Nº Phases 5 Initial Phase Letter “A” Objectives Learn “I” letter Meta-Phase List of Concepts I letter, Indian (Concepts to be Multimedia contents of the concepts “I” sound, Indian Sprite, taught ) Intro “I” Island Ending Indian Playing Kind of Exercise Stimulus Equivalence Meta-Level Stimulus Sound/Images (Exercises to learn Sound: “Very Well!, this is a into a games “I” letter Positive Reinforcement structure) and Indian start with “I” Video: “Very Well”

Proc. Software Evolution 2007 7 / 11

ECEASST

Sound: “This letter isn’t right. Negative Reinforcement Don’t worry, try it other time!” Video: “Don’t Worry” Distractors “A”, “E”, “O” Transparency level Medium. Searching a patter with the Objetive pictogram Indian and letter I Order Random

The multimedia contents are available in a database to be used by the platform which creates and modifies the game. They are sounds (music), video, images or text that can be referenced by every layer of the meta-structure.

The instantiation of the meta-structure initializes the game engine with concrete values, getting in “ad-hoc” way different and personalized games adapted to the player and their limitations to teach concepts. During the use of the game, some aspects can change in the user profile: the child can progress, improving his ability to interact with the game; his knowledge can be increased, the response to the stimulus can be different, and also the context in which the game is played. Besides, the educators can perform some changes to modify the educational contents and the way in which they are shown. These changes force the game to evolve to readapt to the new situations of playing (Fig. 2).

Fig. 2: Structure of our proposal of Evolutionary Videogames

8 / 11 Volume X (2007)

Design of Evolutionary Videogames for Special Education

3.2 Classification of our proposal design of Evolutionary Videogames The evolving characteristics of our videogames will be described according the Taxonomy of Software Evolution of Mens et als [10].

Table 2: Characteristics of our proposal of evolving videogame

Dimension Refactoring Factor Comments Nintendo DS requires reload the memory with the new code Time of change Compile Time written in SDK PC (Static Evolution) When Each version is adapted to the Change history Sequential child progress. Guided by the child results and Change frequency Periodically the new learning contents Gameplay, UI, Multimedia These are the basic aspects of Artifact contents, Learning our design. methods and goals Fine degree of Where Granularity See Figure 1 and 2 granularity Every design Impact See Table 1 components If a didactic concept changes, Change propagation Cascade other game aspects must change Stop to incorporate Stop the Nintendo DS to reload Availability changes the game Educators make changes based Reactive on game reports generated by the Game. Activeness The difficulty levels can What Proactive changes according the punctuation A platform to design, make, and Openness Open adapt games for every player’s profile, will be created The platform will guaranty the Safety Static correct game Every changes are manual Degree of automation Partially automated except the difficulty levels Using frequency tables for Degree of formality Low analyzing results to readapt the difficulty How Automatic analysis With this information the child Process support of game session progress is known Some gameplay and interface Change type Structural components could be added, removed or modified

Proc. Software Evolution 2007 9 / 11

ECEASST

We can use the game reports to readapt the difficulty of levels, introducing an Artificial Intelligence into the game engine to auto configure the difficulty and the levels or phases to make suitable the game process with the learning process. With this method we feed the game- engine with real time information about user to readjust and make the game (in an implicit way, the learning tool) more complete.

4 Conclusions and Future Work We have presented the possibility of creating videogames which are personalized to people with disabilities and which can be adapted to suit the user characteristics and adjusted to the user’s cognitive level and disabilities according to his/her progress.

We are designing a visual platform to create evolving videogames following a development process in which aspects as user interface, educational contents, multimedia and interaction methods are described in separated and incremental steps, in easy way to the teacher to generate the structured files that we use in the game engine to generate the adapted and evolutionary games.

Now we have implemented a videogame for learning the vowels and food on the Nintendo DS following the layers structure of the game exposed.

While we have not encountered any problems at the design level of adaptive and adaptable videogames thanks to our experience in the design of evolutionary systems, we are encountering problems when it comes to implementing the games because of the limitation of the languages and platforms on which they can be supported. We will therefore continue to search for alternatives in order to achieve our objectives of implementing evolutionary games so that they can be used by teachers and pupils with special needs.

Acknowledgements: This research is funded by the Consejería de Educación of Junta de Andalucía (Spain), project SC@UT, and the Comisión Interministerial para la Ciencia y la Tecnología (CICYT-Spain), project AMENITIES grant number TIN2004-08000-C03-02.

References

1. McFalane, A., Sparrowhawk, A. & Heald, Y. Report on the educational use of games: An exploration by TEEM of the contribution which games can make to the education process. (2002). http://www.teem.org.uk/publications/teem_gamesined_full.pdf

2. Rosas, R., Nussbaum, M., Grau, V., López, X., Salinas, M., Flores, P., Correa, M., & Lagos, F. Más allá del Mortal Kombat: Diseño y evaluación de videojuegos educativos para Lenguaje y Matemáticas para el Nivel Básico I. Psykhé, 9. pp: 125–141. (2000).

10 / 11 Volume X (2007)

Design of Evolutionary Videogames for Special Education

3. Gardner H., Frames of Mind: The Theory of Multiple Intelligences. Basic Books. ISBN 978-0465025107

4. Mirenda, Pat. Toward Functinal Augmentative and Alternative Communication for Students With Autism: Ma-nual Signs, Graphic Symbols, and Voice Output Communication aids. Amerrican Speech-Languaje-Hearing Association. Vol 34 (July 2003) pp 203-216

5. Tepaeru, S., Jones, M., Elliffe, D., Muthykumaraswamy, S. Stimulus Equivalence, Testing Sidman’s (2000) Theory. Journal of the Experimental Analysis of Behaviour, 85, pp: 371- 391 (2006)

6. Rollings, A., Morris, D. Game Architecture and Design. New Riders Games. ISBN: 07- 357-1363-4

7. González Sánchez, J. L.; Cabrera, M.; Gutiérrez, F. L. "Using Videogames in Special Education". XII International Conference on Computer Aided Systems Theory (Eurocast 2007).

8. Rodríguez, M.J.; Paderewski, P.; Rodríguez, M.L.; Gea, M. Unanticiped RuntimeAdaptation of a Communicator for Autistic Children. FUSE 2004. Workshop on Foundations of Unanticiped Software Evolution, pp. 40-47. 2004.

9. González Sánchez, J. L.; Cabrera, M. Sc@ut DS: Sistema de Ayuda a la Comunicación y al Aprendizaje. IV International Conference on Multimedia, Information and Communication Technologies in Education (m-ICTEE2006). ISBN: 84-690-2472-8. pp: 1116-1120. (2006).

10. Mens, T., Buckley, J., Zenger, M., Rashid, A. Towards a Taxonomy of Software Evolution. International Workshop of Unanticipated Software Evolution. 2003.

Proc. Software Evolution 2007 11 / 11 ECEASST

A Meta-model for expressing ﬁrst-class changes

Peter Ebraert1, Bart Depoortere1 and Theo D’Hondt1

1 pebraert, bdepoort, [email protected], http://prog.vub.ac.be/ Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 B-1050 Brussel, Belgium

Abstract: First-class changes were proven to provide useful information about the evolution history of software programs. The subjects of first-class changes are expressed on the building blocks of the program which they affect. Those building- blocks are described by a meta-model. The goal of this paper is to find a proper meta-model to express first-class changes. We first establish four criteria for comparing different meta-models and form the basis of a taxonomy to classify them. Afterwards, some meta-models are evaluated with respect to those criteria. Famix is found as the best match with respect to the imposed criteria. Famix, however, still has some minor shortcomings, which can be overcome by the extensions we propose to it. Keywords: Meta-model, software evolution,

1 Introduction

First-class changes are objects which represent change and can be referenced, queried and passed along [EPD07]. They were proven to provide useful information about the evolution history of software programs [RL07]. The subject of a first-class change object is expressed on the building blocks of the program which they affect. Those building-blocks are described by a meta-model. The goal of this paper is to find a meta-model suitable to express first-class changes. The remainder of this paper is structured as follows. In Section 2, we establish four criteria to which the meta-models need to adhere in order to be express first-class changes. Afterwards, we use the established criteria in Section 3 to compare some existing meta-models and discuss about them. Section 4 discusses about the meta-model which is found to be the best suited for modeling changes and proposes some extensions to that meta-model. We conclude in Section 5 and provide some avenues of future work.

2 Criteria for meta-models

In order to compare the different meta-models, we ﬁrst have to identify the criteria which are important with respect to modeling changes. This section introduces four criteria which are relevant with respect to modeling changes on software programs.

1 / 10 Volume X (2007) A Meta-model for expressing ﬁrst-class changes

Support for multiple programming languages – It is desirable to obtain a cross-language specification of change types. Such a specification could be used as an intermediary format for software evolution tools to study, compare and exchange information about the evolution of applications which were possibly implemented in different programming languages. This would bring along the extra advantages that the software evolution tools do not need to be specified for each programming language separately, but rather on the cross-language specification itself. A cross-language specification of change types can only be achieved if the meta-model of their building blocks supports multiple programming languages. To accomplish this, the meta-model must be as general as possible and thus omit language specific features.

Extensibility hooks – The expressiveness of artifacts is often to limited in order to reason thoroughly about evolution facets of a software application. Especially when language-specific features are omitted in the meta-model to support a cross-language specification. This can be overcome by allow the core of the meta-model to be extended. Extending the meta-model, however, may decrease the degree of language independence (e.g. extending it to be able to cope with language specific features). As such, a good balance between a cross-language core and language specific extension possibilities must be established.

Derivable system invariants – Design inconsistencies should be avoided at all times. Apply- ing changes on the design of an application, however, inﬂuence the design and could introduce inconsistencies. In order to avoid that, system invariants – constraints that must be satisﬁed by the system at any time – can be of great help. All different change types are annotated with pre- and post-coniditions which verify wether an instantiation of that change type does not violate the system invariants. The system invariants are actually imposed by the meta-model. While some meta-models provide an extensive list of the invariants, others only provide them implicitly. In both cases, we require that the meta-model serves as a basis for deriving those invariants.

Easy information exchange – The cross-language specification of change types may be used by the software evolution tools as an intermediary format to communicate. Therefore that specification and the meta-model upon which it is based must be complete, consistent, easy to interpret and can not contain any ambiguities. These properties are further referred to as easy information exchange. A high degree of language independence increases the ease of information exchange while a high degree of extensibility decreases the ease of information exchange. Therefore it is important to find a good balance between language independence and extensibility.

3 Towards a taxonomy of meta-models

This section discusses four alternative meta-models and their support with respect to the previously deﬁned criteria.

Proc. Software Evolution 2007 2 / 10 ECEASST

3.1 The Uniﬁed Modeling Language (UML)

UML is a general-purpose modeling language widely used in the world of software engineering [BJR96, Gro99]. It includes a graphical notation used to specify, visualize, construct and document designs. The UML speciﬁcation consists of a meta-model that describes the language for specifying UML models (e.g. class diagrams).

Support for multiple programming languages – UML supports the entire software development process starting from analysis and design omitting implementation speciﬁc issues. There- fore its meta-model is designed to model software systems implemented in various classed-based object-oriented programming languages and thus supports multiple languages.

Extensibility hooks – The UML meta-model provides three extensibility mechanisms. Tagged values permit users to annotate any model element with extra information (value) paired with a keyword (tag). Figure 1 shows an example of a tagged value in the bottum right corner. It is visualized as a note on the design while the keyword documentation is stored in the background.

<> CourseType Language Enrollement Student Science 1 0..* 0..* 1 max: int

We can have maximum {enrollements.size() <= max 10.000 students in our school

Figure 1: UML tagged values, stereotypes and constraints - Example

Stereotypes allow users to further specialize model elements, it is an extensibility mechanism equivalent to inheritance. Figure 1 depicts an example of a stereotype: the enumeration stereotype denotes that CourseTypes is an enumeration providing some deﬁned types of courses. Users can apply semantic restrictions to model elements by using constraints which may be speciﬁed in free-form text or in Object Constraint Language (OCL). OCL is a declarative language that is part of the UML standard and is used for describing rules that apply to UML models. An example of OCL is expressed in the left bottum corner of Figure 1. Students have the possibility to enroll for courses from a certain type whereas each course type has a maximum number of allowed students.

Derivable system invariants – System invariants can be derived from the meta-model’s elements. They can be derived for instance, from the relationships between those entities, their cardinalities or OCL constraints.

3 / 10 Volume X (2007) A Meta-model for expressing ﬁrst-class changes

Easy information exchange – UML is very expressive due to its large number of available concepts and its extensibility mechanisms. This, however, makes it harder to exchange information about UML models. Furthermore, there are some additional problems associated with the UML meta-model speciﬁcation which decrease the ease of information exchange. First, it is incomplete, vague and inconsistent [HS01, RW99]. Second, modelers using OCL restrict their audience since OCL is a complex language and few people can read and write it [Amb04]. As such, we conclude that UML does not provide an easy information exchange.

3.2 RevJava RevJava is a tool which operates on compiled Java code and checks if that software systems is conform to specified design rules [Flo02]. Its meta-model defines all relevant concepts of a Java software system (e.g. package, class or method) and the associations between them (e.g. inheritance definition, method call or variable access).

Support for multiple programming languages – the meta-model is designed for modeling Java-programs but it is general enough to capture the core concepts of software systems implemented in other class-based object-oriented programming languages.

Extensibility hooks – RevJava’s meta-model is incorporated in the RevJava tool. The author has not explicitly speciﬁed any extensibility mechanisms in the document describing the tool.

Derivable system invariants – system invariants can be derived from the Java meta-model speciﬁcation. All derived invariants however apply to the Java programming language and only in some extent to other class-based programming languages.

Easy information exchange – RevJava’s meta-model is easy to read and understand since its number of available concepts remains small. No extensibility mechanisms are speciﬁed by RevJava. As such, we can conclude that it provides support for an easy information exchange.

3.3 FAMIX FAMIX stands for FAMOOS Information Exchange Model and was created to support information exchange between interacting software analysis tools by capturing the common features of different object-oriented programming languages needed for software re-engineering activities [DTS99, DD99, Tic01]. Figure 2 shows a conceptual view of the FAMIX model. On the left side, we see different programming languages used to implement several case studies. On the right side, we see various experiments conducted by several software analysis tools on the provided case studies. In the middle, we see the information exchange model that only captures the common features of class-based object-oriented programming languages such as classes or methods. To cope with language speciﬁc features, the FAMIX model can be extended by using the provided hooks represented by the grey bars at the bottom of the ﬁgure.

Proc. Software Evolution 2007 4 / 10 ECEASST

Figure 2: Conception of the FAMIX model (based on [DTS99])

Support for multiple programming languages – the FAMIX model is designed to model software systems at source code-level independent from the implementation language. To achieve language independence, the FAMIX model only captures common features of different class- based object-oriented programming languages, omitting language-speciﬁc features. It thus supports multiple languages.

Extensibility hooks – The FAMIX model provides three extensibility mechanisms. New concepts can be deﬁned in order to specify new model elements. New attributes can be added to existing concepts in order to store additional information in the model elements. Annotations can be added by the user to any model element for attaching extra information to it.

Derivable system invariants – System invariants can be derived from the model’s elements. They can be derived for instance, from the relationships between those entities, their cardinalities or their constraints.

Easy information exchange – The FAMIX model was created to support information exchange between tools. Hence, it provides very good support for an easy information exchange.

3.4 Graph based alternative Mens and Lanza suggest representing software systems as graphs. Program entities are then represented by nodes, relationships between them by edges [ML02]. To accomplish that, they speciﬁed a typed meta-model consisting of typed edges (e.g. inheritance and accesses) and typed nodes (e.g. class or method). Multiple edges between two nodes are allowed and attributes can be added to each node or edge.

Support for multiple programming languages – The meta-model behind the graph representation supports any programming language whose concepts can be represented by either nodes or edges.

Extensibility hooks – The authors have not speciﬁed any extensibility mechanisms. Extensi- bility seems possible but is deﬁnitely not eased by the provided meta-model.

5 / 10 Volume X (2007) A Meta-model for expressing ﬁrst-class changes

Derivable system invariants – System invariants can be derived from the meta-model’s spec- iﬁcation.

Easy information exchange – The used meta-model is easy to read and understand since its number of available concepts remains small. Extensibility is not encouraged. This helps in providing an easy information exchange.

3.5 Comparison of alternatives Table 1 shows an overview in which the stated criteria are compared against the different alternatives discussed in the previous sections. An “X” indicates that the corresponding criterium is badly or not supported by the meta-model while a “V” indicates the opposite. The ﬁgure shows that the FAMIX model scores the best of all explored alternatives as it supports all criteria.

Requirements/ Meta-Model UML RevJava FAMIX Graph Support for multiple languages V V/X V V Extensibility hooks V X V X Derivable system invariants V V V V Easy information exchange X V V V Table 1: Comparison of alternatives

4 Extensions to FAMIX

Some software systems may never be shut down and require modifications to their source-code at run-time. In those cases, it may be useful to capture the dynamic information of that running system (e.g. the creation of a new instance). We propose to extend the FAMIX model with notions that capture the state of a running system. Any object-oriented programming language (e.g. Smalltalk or Java) defines entities unique to that language. The second extension we propose copes with language specific artifacts in order to derive Smalltalk specific changes (e.g. FAMIX multiple inheritance vs Smalltalk single inheritance). The following two subsections respectively explore the extensions for dynamic state and Smalltalk-specific features.

4.1 Extension for dynamic state The FAMIX model does not provide any elements to store dynamic information such as living instances of a particular class or the value of some global variable. It is however necessary to store dynamic information whenever one wants to specify changes concerning the dynamic software evolution. An example could be a garbage collecting functionality that removes all non- referenced instances. The following subsections discuss the dynamic extension of the FAMIX model.

Instance – The green parts in Figure 3 show the extensions regarding living instances of a certain class. A new class Instance (inheriting from the Object class) has been added which

Proc. Software Evolution 2007 6 / 10 ECEASST

Figure 3: Dynamic extension - Instance & Global Variable

keeps a reference to the class of which it is an instance (denoted by the isInstanceOf relationship). This enables an Instance instance to query the referenced isInstanceOf class for all its deﬁned attributes and methods. AttributeValue has been added to hold the value of a particular Attribute belonging to an Instance instance (belongsToInstance).

Global variable – The orange parts of Figure 3 show the extensions regarding adding global variables of any running program. GlobalVariableValue keeps a reference to the global variable of which it holds the value (valueFor) which in its turn is an Instance instance.

4.2 Extension for Smalltalk The FAMIX model serves as a meta-model for different implementation languages without specifying language specific artifacts. As such, it does not cover the Smalltalk-specific language features. When expressing change types about Smalltalk programs, hoever, such extensions are desirable. This section deals with this kind of extensions and is based on the work of Tichelaar who extended the FAMIX model to capture Smalltalk’s language features [Tic01]. Extra modifications are provided to capture information not suggested by Tichelaar. Following subsections discuss these extensions: extensions suggested by Tichelaar are indicated with “(T)”, additional extensions are denoted by “(*)”.

Class – Each Smalltalk class has an associated metaclass that describes it. This metaclass does not have its own name hence Smalltalk generates a name by concatenating the base class name with the “ class” String. FAMIX deﬁnes a Class class allowing to model both class types. The orange parts in Figure 4 shows that one attribute has been added: isMetaClass, a Boolean indicating whether or not the class represents a Smalltalk metaclass.

7 / 10 Volume X (2007) A Meta-model for expressing ﬁrst-class changes

Figure 4: Smalltalk extension - Class & Behavioral entity

Behavioral entity – Return types of methods are not explicit in Smalltalk. Tichelaar proposes to populate declaredReturnClass and declaredReturnType with the most general type of an object-oriented programming language namely Object. Tichelaar states that functions are not used in Smalltalk which implies that the Function entity of FAMIX will never be populated [Tic01]. Smalltalk, however, does allow block closures which are first-class anonymous functions that take a number of arguments and have a body. In our extension, we use the Function entity to represent Smalltalk’s block closures. The green part in Figure 4 shows that the BehavioralEntity class was extended with an inferredReturnClass association which refers to all possible candidates for the return type of the concerned behavioral entity. Tichelaar has pushed down the following attributes to the Method entity. Each method has a unique signature and a isPureAccessor, which is a Boolean that indicates whether or not the represented method is a pure getter/setter. Figure 5 also shows that the belongsToProtocol relationship has been added. A protocol is the name for a group of methods allowing to organize them. For instance the “accessing” protocol groups all accessing methods (getters and setters). An association between the Method and Package classes has been added as a method belongs to exactly one package in Smalltalk. The value of the belongsToPackage reference may differ from the package in which the containing class is defined. The isConstructor field indicates whether or not the behavioral entity creates and initializes new instances of its containing class.

Structural entity – Smalltalk is a dynamically typed language meaning it does not require the developer to explicitly type variables. Type checking happens at run-time and types of variables are determined by the values assigned to them. Therefore Tichelaar proposes to populate the declaredType ﬁeld and declaredClass association with the most general type of an object-oriented programming language: Object. The green parts of Figure 5 reveal that the inferredClass association has been added to the StructuralEntity class. This association refers to all possible candidates for the type of the structural entity. Smalltalk allows initialization of attributes and global variables.

Proc. Software Evolution 2007 8 / 10 ECEASST

Figure 5: Smalltalk extension - Structural entity & Inheritance deﬁnition

That is why the initializationValue attribute has been added to the Attribute and GlobalVariable classes. Furthermore, the position attribute has been added to the LocalVariable class and maintains the index of the local variable in the behavioral entity’s list of temporary variables. Smalltalk imposes that all attributes are protected and are only accessible within the deﬁning class and its subclasses. Hence Tichelaar proposes to populate the accessControlQualifier attribute with the “protected” Qualifier.

Inheritance deﬁnition – The FAMIX model allows multiple inheritance whereas Smalltalk does not. In Smalltalk, classes always inherit from one single class (except the root class, Object). The red part in Figure 5 depicts a constraint imposing single inheritance. Tichelaar proposes to populate the index attribute of the InheritanceDefinition class with the null value since in this case an index has no meaning. Inheritance in Smalltalk is always pub- licly accessible: all methods (public) and attributes (protected) are inherited by the subclass and have the same visibility.

5 Conclusion and future work

A meta-model can be considered as an explicit description of which building blocks (program entities) are defined in the model of the programming language(s) adhering to it. A meta-model is needed to derive first-class changes which are suitable units that can express the evolution of a software system. This paper discusses four criteria for choosing the appropriate meta-model: support for multiple programming languages, extensibility hooks, derivable system invariants and easy information exchange. Four different meta-models were analyzed with respect to those four criteria. The analysis reveals that Famix satisfies all four criteria. The FAMIX model serves as a language independent meta-model and was introduced to exchange information between different software analysis tools that study the architecture at source-code level of class-based object-oriented software. Two extensions to the FAMIX model are presented. The first extension involves the capability to express changes on the dynamic state of a running system. The second extension copes with language specific artifacts in order to

9 / 10 Volume X (2007) A Meta-model for expressing first-class changes derive Smalltalk specific changes. The most important track of future work consists in testing whether the extended Famix meta-model is expressive enough to specify first-class change types on class-based object-oriented programming.

Acknowledgements: We want to thank the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT Vlaanderen), for providing Peter Ebraert with a doctoral scholarship, and as such ﬁnancing this research.

Bibliography

[Amb04] S. Ambler. The Object Primer Third Edition Agile Model-Driven Development with UML 2.0. Cambridge University Press, 2004. [BJR96] G. Booch, I. Jacobson, J. Rumbaugh. The Uniﬁed Modelling Language for Object- Oriented Development. Documentation set, version 0.9, Rational Software Corpora- tion, 1996. [DD99] S. Ducasse, S. Demeyer. The FAMOOS Object-Oriented Reengineering Handbook. University of Bern, 1999. [DTS99] S. Demeyer, S. Tichelaar, P. Steyaert. FAMIX 2.0 - The FAMOOS Information Ex- change Model. Technical report, University of Berne, 1999. [EPD07] P. Ebraert, E. V. Paesschen, T. D’Hondt. Change-Oriented Round-Trip Engineering. In Atelier RIMEL: Rapport de recherche. Volume VAL-RR2007-01. 2007. [Flo02] G. Florijn. RevJava: Design critiques and architectural conformance checking for Java software. SERC, 2002. [Gro99] O. M. Group. Uniﬁed Modeling Language 1.3. Technical report, Rational Software Corporation, June 1999. [HS01] B. Henderson-Sellers. Some problems with the UML 1.3 meta-model. In Proceedings of the 34th Hawaii International Conference on System Sciences. IEEE Computer Society, 2001. [ML02] T. Mens, M. Lanza. A Graph-Based Metamodel for Object-Oriented Software Metrics. Electronic notes in Theoretical Computer Science 72(2):12, 2002. [RL07] R. Robbes, M. Lanza. A Change-based Approach to Software Evolution. Electronic Notes in Theoretical Computer Science 166:93–109, 2007. [RW99] G. Reggio, R. Wieringa. Thirty one Problems in the Semantics of UML 1.3 Dynamics. 1999. [Tic01] S. Tichelaar. Modeling Object-Oriented Software for Reverse Engineering and Refac- toring. PhD thesis, University of Bern, 2001.

Proc. Software Evolution 2007 10 / 10 ECEASST

Evolutionary System for Sc@ut Communicators

Paredes-Garrido, Mar´ıa-Dolores1, Rodr´ıguez-Fortiz,´ Mar´ıa-Jose´2 and Medina-Medina, Nuria3

1 [email protected], http://lsi.ugr.es/∼gedes/ 2 [email protected], http://lsi.ugr.es/∼gedes/ 3 [email protected], http://lsi.ugr.es/∼gedes/ Grupo de Investigacion´ en Especiﬁcacion,´ Desarrollo y Evolucion´ del Software. ETS Ingenier´ıa Informatica´ Universidad de Granada, Espana˜

Abstract: Sc@ut Communicators are augmentative and alternative communication systems (AAC) that have been developed by the Sc@ut platform. These communicators help people with communication problems and their main feature is that they may be adapted to each individual. These communicators are currently being used by autistic children, and professionals require us to develop a system with greater autonomy so that they can conﬁgure and adapt the communicator. Keywords: Evolution, Adaptive Hypermedia System, Communicators.

1 Introduction

There is a wide cross-section of the population with disabilities which impedes their speech or makes their communication difﬁcult to understand [Mir03]. Augmentative and alternative communication systems (AAC) are a growing ﬁeld of study and are concerned with providing devices and techniques for increasing the people’s communicative ability. The Sc@ut project is a platform that allows adaptive communicators [PPR+06] to be created for people with certain communication needs due to disability. The communicator runs on a Pocket PC device which has the advantages of being cheap, versatile and portable. We are currently focusing on autism, but due to the numerous settings that Sc@ut offers, we have designed communicators which can be adapted for other people with disabilities such as cerebral paralysis or dysphasia [PR06]. These communicators are being used by 26 children in 18 schools of Spain and these numbers are growing. Re-adaptations are needful because a child with autism evolves frequently his capacities and habilities. Nowadays these re-adaptations are being done manually by us. Educators and parents demand us a new system to have more independence, helping them to re-adapt the communicator. For this, it is neccesary to design and to create a new system, the Evolutionary System of Sc@ut. In this work, we are explaining how we can evolve Sc@ut communicators. Sc@ut Platform is explained in Section 2, both its architecture and the process to create a communicator. In Section 3 we introduce the new system of the platform, and in Subsection 3.1 we describe how

1 / 10 Volume X (2007) Evolutionary Sc@ut

Figure 1: Sc@ut Architecture and Process this new system is linked in the architecture of two levels. Then, in Section 4 we describe evolution process of Evolutionary System. Finally, we contribute conclusions and further lines of work about Evolutionary System and Sc@ut Platform.

2 Sc@ut Platform

The Sc@ut Platform is based in an architecture of two-levels [GRP02]. The lower level consists of software system (or the communicator sytem). The communicator is a hypermedia system which enables the user to navigate through pages with different scenarios and to select components with images and sounds from each page to express what the child wants. Each person has his own communicator due to differences in abilities to understand language, capabilities and skills (user profile) [PPR+06]. The communicator can be created using another tool in the first level of the architecture, the meta-communicator or meta-system. The meta-communicator is used by parents and professionals (educators) to configure and create the communicator and to adapt it to each individual user. These users are called authors or developers [GC01] . The end user of communicators are people with need of communication, like children with autism, they are called users or readers. In “Figure 1” we can observe this architecture together with the process to design Sc@ut communicators. Now, we are going to describe how we to design and create a Sc@ut Communicator.

2.1 The Communicator Before, we had commented that a communicator has scenarios where the child can navigate. The scenarios are constructed by considering the knowledge domain of the child modelled in a

Proc. Software Evolution 2007 2 / 10 ECEASST

Figure 2: A Sc@ut communicator with scenario breakfast conceptual structure. Each scenario comprises elements and represents a real-life action that the child knows and can perform. The elements associated to the action are the scenario components. The number and kind of components that has a scenario is defined by the user-profile. “Figure 2” shows the example of a communicator with an scenario for ”have breakfast”, which includes three components: sandwich, custard and cookies. Each component is located in a componentor square on the hypermedia screen and consists of an image, a text label and sounds. a The image associated to a component can change due to its state of selection: deactivated if there are any precondition that is not satisfied previous to the component selection, and unavailable if there is a number of units of the component that have been depleted. Due to multiples settings of configuration of a communicator we can create communicators adaptive and flexibles to re-adapt it. A complet descripcion about Sc@ut communicator is in the work of [PPR+06].

2.2 The Meta-Communicator The meta-communicator is the application used by educators to create the communicator for each specific child. Thanks to the two architectural levels of our platform, the user profile and the templates (with components, images, sounds and links) are structured information that the communicator system is able to interprete in order to generate a personal communicator. The meta-communicator creates and manages this structured information, which is stored in XML files. Changes in a the user profile of a person or in his communicator are changes in the XML files. The meta-communicator has been designed to be used by educators who do not have much experience with computers or PDAs. The following steps were taken to create the communicator: (1) Specification of the user profile, (2)Representation of the knowledge domain: scenarios, (3) Creation of the hypermedia model: navigation and (4) Adaptation. User Profile. The characteristics considered in the user profile are: child skills, communication habits, guidelines for creating usual scenarios, interaction preferences, educator objectives, interaction shortcuts, and a schedule with the child’s main activities. Different interaction prefer-

3 / 10 Volume X (2007) Evolutionary Sc@ut ences can be chosen in the child’s profile such as the number of squares or components on each page, information mode or interaction type, etc. Scenarios and Navigation. The knowledge domain is necessary for modelling the world perceived by the children in a way that is friendly and close to them. As we have seen in the process of constructing of the user profile, the educators participate actively to describe the scenarios and activities that the child is able to recognise and understand. Using the post-requirements associated to the components for navigating the system [Hub01], we construct a hierarchy of levels which define how the system is navigated and the syntax of the language for the child. So, the child can construct phrases like: subject (in the first level of the hierarchy) + verb (in the second level) + complement (in the last level, there are a set of specific complements for each verb). Templates constructed by meta-communicator constitute one of the possible media used to establish communication with the user and are represented in hypermedia format [TG03]. Adaptation. We have to differentiate Adaptation vs Evolution. With the adaptation we represented the information in an optimal way for an individual user according to his special needs. And with the evolution we study the user’s behaviour with the communicator detecting new needs. Summary, the evolution carries the adaptation of system in the necessary moment for the user. The elements that we adapt are all of the elements of the user profile, scenarios and navigation, according to several rules that assure the integrity of communicator. This proccess is the main theme of this work.

3 Evolutionary System

Communicator generates log files while the child interacts with it. The log file includes information that can be used by the professional to discover the user’s interaction and to decide to change his profile and scenarios to fit the child’s characteristics. But what type of information is managed? The following examples show the type of information included in a log file: the scenarios or templates (i.e.pages from the hypermedia system) selected, components from these pages that have been selected; the number of times that each concrete component has been selected, and the number of units initially associated to it; the validity or not of the selection of the component depending on whether its precondition has been satisfied; the navigation order, and path followed to reach a concrete component from the first template, or from another concrete component. Educators must intervene to control the child evolution. So, we focus our effort with the help of psychology and pedagogy experts, and educators who know the children and know whether their profile or environment has changed. Evolution is semi-automatic because the system can guide the professional to the decisions to be taken about why, when and how changes should be made to best suit the user. This system is new Evolutionary System of Sc@ut.

Proc. Software Evolution 2007 4 / 10 ECEASST

Figure 3: Sc@ut Architecture and Process

3.1 New Architecture of Sc@ut Following with two layers architecture, Evolutionary System is at the same level of Communi- cator System inside of Sc@ut architecture. In “Figure 3” we can observe where Evolutionary System is linked.

4 Evolution Process

The evolutionary process is shown in “Figure 4”. This process is integrated by three phases. These phases are activated corelatively. The first one is to configure detection rules. Second one is to analyze the child’s log files according to these detection rules to propose changes and the third phase is to apply the selected evolution [PR06]. Now, let’s describe the three phases and whom perfom them.

4.1 Configurating Detection Rules System must know when the interaction of a specific user’s differs from that expected by the professional who designed communicator [Dau00]. System can measure the information included in one or various log files collected during one or several sessions. These measures are used by the professional to configure Detection Rules (DRs) in an informal language. A detection rule consists of a condition about one or several measures and an alert message if the condition is true. System translates Detection Rules into a formal language to be processed automatically. Educator could assign a degree of priority between the rules to avoid coupling. For example, the professional hopes that component i is selected more than 3 times and so he creates a Detection Rule:

5 / 10 Volume X (2007) Evolutionary Sc@ut

Figure 4: Evolutionary Process Sc@ut

If component i has been selected fewer than 3 times in the last 7 days, alert x

which is translated to:

session (today,today-7): If component(i).selection < 3 then alert(x)

When DRs are deﬁned, the next step is to analyze the log ﬁles according to these DRs. So, the system could detect anomalistic behaviour in the user interaction.

4.2 Analyzing the Information In this phase, the log files are studied by the system to detect any abnormal interaction according to the detection rules. But, how do we analyze the log files? A great part of this analysis is carried out using transition matrixes. A transition matrix captures information about the components selected by the child in the templates but, besides, it con- templates the conceptual relationships implicitly followed during that process of interaction. The transition matrix (MT ) has a row and a column for every component visualized in any template of the communicator. The component MT [c1,c2] counts the number of times that after selecting the component c1, the child has chosen the component c2. For example, after the interaction shown in the “Figure 2”, the value of the component MT [“Iwant”,“Sandwich”] is increased by one. We have a transition matrix for the valid selections and another ont for the non valid selections (i.e. when the child selects a component that is disabled in that moment). For example, the child selects “Cookies” without any effect because the component is disabled (there are not cookies or he has prohibited to eat them) and just later he selects “Finish”, the component 0 0 MT [“Cookies”,“Finish”] in the invalid transition matrix (MT ) is increased. Using the first transition matrix we obtain the following information:

• High value for a component c1(Σ jMT [c1,c j] ≥ threshold): This means that the child selects with plenty of frequency the component c1 in the distinct templates where it appears.

Proc. Software Evolution 2007 6 / 10 ECEASST

• Low value for a component c1(Σ jMT [c1,c j] < threshold): This means that the child never or almost never selects the component c1. For example, based on it the educator can remove or change the picture of this component in the templates where it appears.

• High value for a conceptual relation c1 → c2(MT [c1,c2] ≥ threshold): This indicates that very often the child after choosing c1 chooses c2, which permits to the educator detects sequence of actions repeated by the child. So, he can identify a progress in its learning (then reinforce it) or an inappropriate conduct (then restrict it).

• Low value for a conceptual relation c1 → c2(MT [c1,c2] < threshold): This indicates that almost never the child chooses c2 after choosing c1, which permits to the educator detects sequence of actions not performed by the child and to act consequently. Obviously, only are taken into account the possible relations, that is, the couple of component (c1,c2) that in the current structure of templates can be selected consecutively.

The invalid transition matrix permits a similar analysis, obviously, with differences of interpretation: for example, in this case, a high value for a component indicates that it is selected many times being disabled. The educator would to decide, for example, to change the restrictions of access to that cell. In addition, the study of this matrix permits to identify the conducts repeated by the child before situations of frustration, i.e. how does it react when he press a disabled component? What component does he press subsequently? Evolutionary Actions are proposed as change alternatives. When a Detection Rule holds, an alert is activated in the system. This alert triggers one or several Evolutionary Actions which will be carried out only if the Integrity Rules (IRs) related to them are satisﬁed. Evolutionary Actions and Integrity Rules must be designed by a software developer of the meta-system rather than by educator. Examples of Evolutionary Actions are: adding or deleting a component from a template, changing the images, sounds and links associated to a component which represents a concept or action, changing the navigation order from one component to another, etc. An example of an Integrity Rule associated to Evolutionary Action “deleting a component from a template” is:

A component i which links to a template T can be deleted if T is linked by another component j

Expressed in a more formal language:

delete(component(i),P) ← link((component(i),P),T) and ∃ (component(j),S) / link((component(j),S),T) where P and S are templates and j is a component. This Integrity Rule ensures that there are not disconected templates. The Evolutionary Action could also be performed if the professional is informed and accepts that template T will not be used from now on. In this case, the professional intervenes in the evolutionary process changing or selecting the constraints associated to an evolutionary action. Therefore, we can deﬁned several levels of integrity.

7 / 10 Volume X (2007) Evolutionary Sc@ut

4.3 Selection of Change and Evolution In this step, educator chooses the most appropriate Evolutionary Action for the user in that moment. Then, Evolutionary System sends these EAs to meta-communicator where they will be applied to the child’s communicator. The intervention of the educators are essential for taking decisions about changes, since they are the ones who observe the child, best know his needs and can interpret his responses to the communicator. For example, a child has not selected the milk component in the last four days. Therefore, according to the Detection Rules previously deﬁned by the educator, several Evolutionary Actions are activated and offered to change the communicator. These rules are: 1.- Change image. 2.- Don’t show component. 3.- Change order of components in template. and educator selects Option 1. Then, evolutionary system sends to meta-communicator the evolutionary action selected. Meta-communicator carries out the generation of a or several new XML templates according to this change. Expressed in a more formal language: action(x) ← change(image,component(i),T;image new) action(y) ← delete(component(i),T) action(z) ← change(order,component(i),T;ﬁrst(T)) where i is the milk component and T is the breakfast template.

5 Conclusions and Further Lines of Work

We have proposed a flexible architecture that allows us to easily add or modify communicators used by people with communication and learning problems. We have constructed a system that is able to interpret XML files (the communicator)with image and sounds files, and another that writes these XML files (the meta-communicator. Bboth together constitute the original Sc@ut platform. We currently have a robust version of the platform and Sc@ut communicators are being used in several teaching centers in Spain. Professionals need an automatic or semi-automatic tool (meta-communicator) that helps them to modify the communicators, i.e. the XML files which constitute the meta-communicator’s data, without having to resort to computer engineers. We can also help them to automatically analyze the children’s interactions and suggest valid changes. This is the responsibility of the Evolutionary System that we have added to the Sc@ut Platform. In this work we have showed how to perfom evolutionary process in a semi-automatic way. First, Detection Rules are defined by educators to detect anomalistic behaviour. Second step, Evolutionary system learns child’s interation due to log files. Then, Evolutionary system alerts the educator, according to these detection rules, about anomalistic behaviour. System offers educator several coherent decisions trying to model and correct this behaviour. In this moment, educator has an essential role selecting most appropriate option to evolve the communicator. Last step, evolutionary system sends evolutionary actions to another top-layered system (meta- communicator) to allow it to perform them. Communicator integrity is assured by Integrity Rules that are defined by a software developer.

Proc. Software Evolution 2007 8 / 10 ECEASST

Also, this developer deﬁnes associations between evolutionary actions and integrity rules. These deﬁnitions are allocated in meta-communicator. Our immediate work is the full formalization of the updating and detection rules, as well as integrity constraints and for this, we are focusing on our previous work into evolving hypermedia systems. In the future, we plan to implement the proposal and to prove them using the real cases we are currently working on. We have received two prizes for our work, one from a federation of professionals of autism in Spain [RGP+07] and another from Microsoft. Three students which are working in our group are the winners of the Imagine-CUP 2007 in Spain.

Acknowledgements: This research is supported by the Sc@ut project (Consejer´ıa de Edu- cacion´ y Ciencia de la Junta de Andaluc´ıa, Government of Spain) and ADACO project TIN2004- 08000-C03-02 (CICYT, Government of Spain).

Bibliography

[Dau00] K. Dautenhahn. Design Issues on Interactive Environments for Children with Autism. In Proceedings International Conference on Disability, Virtual Reality and Associated Technologies (ICDVRAT). Pp. 153–161. Alghero, Sardinia, Italy, Sept. 2000. citeseer.ist.psu.edu/392016.html

[GC01] L. Garc´ıa-Cabrera. SEM-HP: Un Modelo Sistmico, Evolutivo y Semntico para el desarrollo de Sistemas Hipermedia. PhD dissertation, Granada University, Department of Computer System and Languages, 2001. Title Translation: SEM-HP: A Semantic, Evolutionary and Systemic Model for Hypermedia System Development.

[GRP02] L. Garc´ıa-Cabrera, M. J. Rodr´ıguez-Fortiz,´ J. Parets-Llorca. Evolving hypermedia systems: a layered software architecture. Journal of Software Maintenance 14(5):389–405, 2002. doi:10.1002/smr.262

[Hub01] R. Hubscher. What’s in a Prerequisite. icalt 00:0365, 2001. doi:10.1109/ICALT.2001.943946

[Mir03] P. Mirenda. Toward Functional Augmentative and Alternative Communication for Students With Autism. American Speech-Languaje-Hearing Association 34:203– 216, July 2003. doi:10.1044/0161-1461(2003/017)

[PPR+06] M. D. Paredes-Garrido, O. Pino-Morillas, M. J. Rodr´ıguez-Fortiz,´ M. Gonzalez-´ Gonzalez,´ E. Rodr´ıguez-Parra. A Platform for Creating Adaptive Communicators. Lecture Notes on Computer and Science 4061:847–854, June 2006. doi:10.1007/11788713 123

9 / 10 Volume X (2007) Evolutionary Sc@ut

[PR06] M. D. Paredes-Garrido, M. J. Rodr´ıguez-Fortiz.´ An evolutionary system for the Sc@ut platform. SIGACCESS Access. Comput. 86:36–39, 2006. doi:10.1145/1196148.1196157

[RGP+07] M. Rodr´ıguez-Fortiz,´ M. Gonzalez-Gonz´ alez,´ M. Paredes-Garrido, E. Rodr´ıguez- Parra, et al. Comunicador Aumentativo Para Ninos˜ Autistas. Investigacion´ E Inno- vacion´ En Autismo, pp. 129–166. Editorial AETAPI. Fundacion´ Caja Madrid, May 2007.

[RPRG04] M. Rodr´ıguez, P. Paderewski, M. Rodr´ıguez, M. Gea. An approach for evolving an adaptive and unanticipated system: a communicator for children with autism. Pp. 40– 47, July 2004.

[TG03] F. Tortosa-Nicolas,´ M. Gomez-Villa.´ Tecnolog´ıas de ayuda y comunicacion´ aumen- tativa en personas con trastornos del espectro autista. Tecnolog´ıa de ayuda en personas con trastornos de la comunicacion´ , pp. 211–246, 2003. Title Translation: Aid Technologies and Augmentative Communication for people with autism spectrum disorder.

Proc. Software Evolution 2007 10 / 10 ECEASST

Evolution styles: change patterns for Software Evolution

Olivier Le Goaer1 and Peter Ebraert2

1 [email protected], http://lina.atlanstic.net/ Laboratoire Informatique de Nantes Atlantique University of Nantes 2 rue de la houssiniere F-44000 Nantes, France

2 [email protected], http://prog.vub.ac.be/ Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 B-1050 Brussel, Belgium

Abstract: Patterns have been proved useful in many problem domains. In the domain of software evolution, only behaviour-preserving patterns (e.g. refactorings) have ever been proposed. This paper proposes to broaden the scope of change patterns by means of a reification of any evolution efforts into styles. We define an evolution style as a first-class entity which is specified once and can be applied many times. Evolution styles allow the specification of (non) behaviour-preserving change patterns. We exemplify the use of the evolution style concept by means of two applications which evolve in a style-based way. Keywords: Evolution styles, Change patterns

1 Introduction

It was Christopher Alexander, who first introduced the idea of capturing design ideas as patterns [AIS77]. Being an architect, he was constantly confronted with similar problems concerning the design of buildings and cities. For not having to re-solve similar problems over and over again, he came up with patterns, which recorded the design decisions taken by many builders in many places over many years in order to resolve a particular problem. In the late eighties, patterns were introduced in the field of software design [BC87]. Design patterns for example, gained popularity in computer science after the book Design Patterns: Elements of Reusable Object- Oriented Software was published in 1994 by Gamma et al [GHJV94]. They defined a design pattern as a general repeatable solution to a commonly occurring problem in software design. Two decades ago, Opdyke introduced patterns in the domain of software evolution [Opd92]. A few years later, Fowler took up on that track and defined a “pattern” as an idea that has been useful in one practical context and will probably be useful in others [Fow97]. Two years later, Fowler presented a catalog of refactorings, which are patterns of change to a computer program which improve its readability or simplifies its structure without changing its results [Fow99]. Changing requirements (e.g. the need to introduce secure transactions) make the evolution of

1 / 10 Volume X (2007) Evolution styles: change patterns for Software Evolution computer programs inevitable. It has early been stressed that programs continuously need to change to remain useful [LB85]. Some types of changes often show up in software engineering: introducing privacy, transactions, security, logging, etc. [CHK+01]. Just like Alexander, Gamma and Fowler, we think that those recurring problems can be solved by a dedicated solution. We deﬁne a change pattern as a general repeatable solution to a commonly occurring problem in software evolution. Change patterns are more general than refactorings, as they also allow expressing changes which alter the outcome of an application. As such, refactorings are change patterns, while change patterns are not refactorings. The rest of this paper is structured as follows. Section2 illustrates how two very different application architectures are facing changing requirements which impose similar changes on the architectures. Section3 presents the evolution style concept as a mean to specify those changes as change patterns. In Section4 we show that those evolution styles can be applied on different applications to cope with their changing requirements. Finally, we stipulate the concluding remarks and the tracks of future work in Section6.

2 Problem statement

This section ﬁrst introduces a banking application in Java with changing requirements. We specify an evolution scenario which is applied on the banking application to cope with its new requirements. We then introduce another application – a chat room – which is developed in Smalltalk, and which is also a subject of changing requirements. We show that, while both applications are very different, the changes they are undergoing are very related. This illustrates the need for change patterns, which are speciﬁed only once and can be applied many times.

2.1 Banking application and its evolution Assume the information system which manages the services of a bank depicted in Figure1. This application is implemented in Java. The Cashier is an employee of a Bank who performs a Cashier Transaction. He can transfer, deposit and withdraw money from the Account of the Customer.

Cashier acc Transaction Cashier Account Customer date_time: Date Id: int Bank Id: int name: String amount: Float name: String balance: Float address: String name: String accounts customer acc: Account employs creditLimit: Float get:from:(m: String, s: User) commit() transaction deposit(a: Float) register(u: User) balance = balance + a withdrawy(a: Float) unregister(u: User) transfer(acc: Acount a: Float) balance = balance - a this.withdraw(a); Deposit Withdraw Transfer acc.deposit(a); acc.transfer(acc, a); commit() commit() commit() acc.withdraw(amount);

acc.deposit(amount);

Figure 1: A Java banking architecture

The banking application of Figure1 only includes one kind of account. Changing demands on the market, however, impose the banking system to model different kinds of accounts. Saving

Proc. Software Evolution 2007 2 / 10 ECEASST accounts get a higher interest rate, but are limited in the transactions they allow. Deposit accounts allow all kinds of transactions, but provide less interest. Next to that, money transfers can be sent over a network while the privacy of the users must still be guaranteed. To cope with the ﬁrst requirement, we introduce different kinds of accounts by subclassing the Account class with a SavingAccount class and a DepositAccount class. Next, the transferMoney method is pushed down to the DepositAccounts class, so that it cannot be called from a SavingAccount. These changes are annotated in red in Figure2. To ensure the customer’s privacy, the amounts sent over the network are encrypted. This is done by adding an encrypt method to the CashierTransaction class and by invoking it when committing the transaction (in the commit method). When the message is received by the transfer method from the Account class, it needs to be decrypted by calling the decrypt method, which was added to that class. These changes are annotated in green in Figure2.

balance = balance - a

Deposit Withdraw Transfer DepositAccount SavingAccount acc.transfer(acc, encrypt(a)); commit() commit() commit() transfer(acc: Acount a: Float) encrypt() return f (a); decrypt:(m: String) this.withdraw(decrypt(a)); acc.withdraw(amount); acc.deposit(decrypt(a)); return f −1 (m) acc.deposit(amount);

Figure 2: The banking architecture after evolution

2.2 Chat application and its evolution Consider the chat application depicted in Figure3. This application is designed conform to the class-based objected-oriented meta-architecture of Smalltalk. It originally consists of two classes, User and Chatroom, which respectively maintain a reference cr and users to one another. A user can subscribe to a chatroom using the register method and exchange text messages with the rest of users of the chatroom using the send and receive methods. Text messages sent to the chatroom are propagated to all the registered users.

cr get: m from: self User Chatroom username users Transcript show: send:(m: String) get:from:(m: String, s: User) (s name + ': ' + m) receive:from:(m: String, s: User) register(u: User) name() cr unregister(u: User) ∀ u ∈ users: ^ username u receive: m from: s

Figure 3: A Smalltalk chat architecture

Assume now we need to differentiate between registered and guest users. For doing so, we

3 / 10 Volume X (2007) Evolution styles: change patterns for Software Evolution add two subclasses of User to the application program, RegisteredUser and Guest.The difference between the two types of users is that the registered users can be identiﬁed by their name in the chat room whereas the guests cannot: Accordingly, the username attribute of User class is pushed down to the RegisteredUser class. Figure4 shows this ﬁrst feature added to the application (in red).

cr get: m from: self User users Chatroom ∀ u ∈ users: send:(m: String) get:from:(m: String, s: User) Transcript show: m u receive: m from: s receive:from:(m: String, s: User) cr register(u: User) unregister(u: User) cr get: (self encrypt: ^ username ^ 'guest' cr get: (self encrypt: m) from: self m) from: self RegisteredUser Guest Transcript show: username Transcript show: (s name + ": " + name() name() (s name + ": " + s decrypt: m) send:(m: String) send:(m: String) s decrypt: m) receive:from:(m: String, s: User) receive:from:(m: String, s: User) encrypt:(m: String) encrypt:(m: String)

^ f (m) decrypt:(m: String) decrypt:(m: String) ^ m

^ f −1 (m) ^ m

Figure 4: The chat architecture after evolution

The second change incorporates to ensure the privacy of the users, which in this case corresponds to encrypting and decrypting the messages when they are sent and received respectively. In order to match these requirements, the architect needs to adds two methods to the User class, encrypt and decrypt, which are called from within the send and receive methods respectively. Figure4 shows this second feature added to the application (in green).

2.3 The need for evolution reuse

Both applications are different: They are used in different areas (banking and communication) and are even implemented in different programming languages (Java and Smalltalk). Despite of their different nature, both the banking and the chat applications have been evolving in the same way. First, two subclasses were introduced. Second, a method is pushed down to one subclass. Third, a complex pattern for introducing encryption and decryption is applied to each application. The empirical observation of recurring change patterns shows the possibility to capture those patterns as evolution practices. Refactorings were already proposed as best practices for improving the structure of applications [Fow99]. Refactorings, however, are not general enough, as they only cover change patterns which do not change the observable behaviour of the software system [Opd92]. Behaviour-changing change patterns (e.g. introducing encryption) are not covered by refactorings. That is why we propose to generalize the idea of change patterns for Software Evolution in evolution styles, which is elaborated on in the following section.

Proc. Software Evolution 2007 4 / 10 ECEASST

3 Evolution styles

The evolution style concept is a domain-specific specification of a solution for a recurring problem in software evolution. Styles specify a solution which can be applied over and over again and enhance the understandability of the software evolution by raising the level of abstraction of undertaken changes. This section briefly describes the specification format of an evolution style. For a more detailed explanation, we refer the reader to [SOTG06].

3.1 Specification An evolution style is a first-class entity that can be referenced, queried and passed along. The core of the meta-model of the evolution-styles is shown in Figure5. Every evolution style class possesses a name (allowing a communication about the different styles at a more abstract level) and a goal (providing a textual explanation of the purpose of the evolution style). The Domain of an evolution style corresponds to the meta-architecture on which that evolution style is expressed. Its Header is a set of input/output parameters which are expressed on the building blocks of the domain or the application. They can be specified as pre- and postconditions of the evolution style. A Competence represents the sequence of changes that must be applied when the evolution style is invoked. These changes are expressed on the building blocks of the domain or the application.

Figure 5: Core meta-model of the Evolution Style

Developers can specialize and compose evolution styles. Specialization supports a white-box reuse of existing specification, allowing a sub-style to supplement or redefine informations of a super-style. Composition supports a black-box reuse, allowing a complex style to delegate changes to other styles, until basic styles. The next section provides three examples of evolution styles which are specified in the a domain based on the [DTS99] meta-model.

3.2 Examples Every evolution style is speciﬁed in a certain domain. We use Famix as the common domain for the three evolution style examples which are about to follow. Famix provides a language- independent model for class-based object-oriented source code. Both Smalltalk and Java programming languages adhere to Famix, whose core is depicted in Figure6.

5 / 10 Volume X (2007) Evolution styles: change patterns for Software Evolution

Figure 6: The FAMIX core [Based on [DTS99]]

Introducing a subclass – The basic AddSubClass evolution style captures the simple change pattern for introducing a subclass of a class. It is speciﬁed as follows:

Name AddSubClass Goal Add a new class as a specialization of an existing superclass. Domain Famix Header Parameters {Class super, String name} Constraints { pre: not existsClass(c, name, ?superClass) pre: existsClass(super, ?name, ?superClass) post: existsClass(c, name, super) } Competence c := Class new: name c superclass: super

The parameters of this style are typed with building-blocks of the Famix meta-model. The constraints are specified in a logic programming style. The precondition not existsClass(c, name, ?superClass) is a clause which verifies that there does not exist any class c with the name name with any superclass in the system. The postcondition existsClass(c, name, super) states that after applying the evolution style, the system contains a class c named name with a superclass super. A logic engine can be used to unify those variables to the values of the styles’ parameters. Note that the competence of the pattern is specified in Smalltalk, but only uses concepts of the Famix domain. It sends a new: message to the class class in order to create a new class with name as its name. Afterwards, it sets the superclass of the new class to super.

Shifting down a method – In order to specify a reusable evolution style, we propose a three- step speciﬁcation for this change pattern. First, we specify general two basic evolution styles intended to add (or delete) a method m to a class target. The following code snippet show the style for adding a method to a class. The equivalent style RemoveMethod which removes a method from a class is omitted for the sake of brevity.

Name AddMethod Goal Add a method to a class Domain Famix Header Parameters {Method m, Class target} Constraints { pre: existsClass(target, ?name, ?superClass) pre: not existsMethod(m, target) post: existsMethod(m, target) } Competence target addMethod: m

Proc. Software Evolution 2007 6 / 10 ECEASST

Secondly, we specify a TransferMethod style as a composition of the RemoveMethod and the AddMethod styles. A TransferMethod veriﬁes that all classes exist and that m is a method of class source. The competence of this style applies the RemoveMethod style to remove the method from source and applies the AddMethod style for every class in the target enumeration to add m to each one of them. The following snippet shows the speciﬁcation of the style:

Name TransferMethod Goal Cut/paste a method from a class to some other classes Domain Famix Header Parameters {Method m, Class source, Class[] targets} Constraints { pre: existsClass(source, ?name, source) pre: existsClass(tar, ?name, source), member(tar, targets) pre: existsMethod(m, source) } Competence RemoveMethod(m, source) apply target do[:c ! AddMethod(m, c) apply]

Thirdly, we specialize the TransferMethod style to capture the push down method refac- toring1. The PushDownMethod style supplements the inherited speciﬁcation of its super-style with an extra precondition to ensure that the target classes are subclasses of the source class, and redeﬁnes the goal for a more precise semantics. Its competence consists of just invoking the competence of its super-style.

Name PushDownMethod Goal Push down a method from a superclass to some of its subclasses Header Constraints { pre: forall elementOf(c, enumeration), existsClass(c, ?name, source) } Competence super apply

Introducing Privacy – Finally, we propose a complex evolution style which encapsulates the pattern that introduces privacy in an application adhering to the Famix meta-model. This style adds an encryption method encM to a class senderC which is able to encrypt a parameter. It then surrounds the invocation of a method receiverM in the senderM with an invocation of the added encM method. On the receiver class receiverC it adds a decM method which is able to decrypt a parameter and adds an invocation to it inside the receiverM method. The IntroduceMessagePrivacy style is composed of three styles: the AddMethod style, the EncapsulateInvocation style and the EncapsulateParamater style.

Name IntroduceMessagePrivacy Goal Ensure privacy of exchanged messages between a sender and a receiver Domain Famix Header Parameters {Class senderC, Class receiverC, Method senderM, Method receiverM, FormalParameter par} Constraints { pre: existsClass(senderC, ?name, ?superClass) pre: existsClass(receiverC, ?name, ?superClass) pre: existsMethod(senderM, senderC) pre: existsMethod(receiverM, receiverC) pre: existsInvocation(senderM, receiverM, par) post: existsMethod(encM, senderC) post: existsMethod(decM, receiverC) post: existsInvocation(senderM, encM, par) post: existsInvocation(receiverM, decM, par) } Competence Method encM := Method new: "encrypt:" parameter: "m" body: "f(m)" AddMethod(encM, senderC) apply Method decM := Method new: "decrypt:" parameter: "m" body: "f-1(m)"; AddMethod(decM, receiverC) apply EncapsulateInvocation: par of: receiverM with: encM in: senderM EncapsulateParamater: par with: decM in: receiverM

1 http://www.refactoring.com/catalog/pushDownMethod.html

7 / 10 Volume X (2007) Evolution styles: change patterns for Software Evolution

4 Validation

In this section, we validate the claim that evolution styles encapsulate change patterns which are specified once and which can be applied many times. In order to do that, we go back to the banking and chat applications which were explained in Section2 and show that the three evolution styles which were specified in Section3 can be applied on both applications in order to obtain the required application design. Applying an evolution style consists in parameterizing it with the actual building blocks of the considered architecture, verifying the header’s preconditions and executing the competence. In case the preconditions cannot be verified, the style cannot be applied. The following sections respectively describe how the evolution styles are applied on the banking and chat applications.

4.1 Style-based evolution of the banking application Reconsider the banking application from Section 2.1. We now evolve that application by means of evolution styles. The following code speciﬁes the style-based evolution steps of the evolving banking application. The evolution styles are invoked (like functions) with their parameters being the building blocks of the banking architecture. Applying this change sequence on the application, makes it end up in the architecture which is depicted in Figure2. AddSubClass(Account, "DepositAccount") apply AddSubClass(Account, "SavingAccount") apply PushDownMethod(transfer, Account, {DepositAccount}) apply IntroduceMessagePrivacy(Transfer, commit, DepositAccount, transfer) apply

4.2 Style-based evolution of the chat application Reconsider the Chat application depicted in Figure3. The following code snippet shows the evolution of that system, speciﬁed in an evolution style way. In comparison with the banking case there is an additional invocation of a ModifyMethod style, which alters the deﬁnition of the name method of the Guest class to make it return a ’guest’ string whenever invoked. AddSubClass(User, "RegisteredUser") apply AddSubClass(User, "Guest") apply PushDownMethod(name, User, {RegisteredUser, Guest}) apply ModifyMethod(name, Guest, "ˆ ’guest’") apply IntroduceMessagePrivacy(User, send, User, receive) apply

4.3 Evaluation Evolution styles specify a pattern of changes which can be applied to solve a recurring problem in software evolution. Defining the styles is the subject of a difficult paradox. On the one hand, the evolution style must be specific enough to encapsulate a solution for a well-defined problem. On the other hand, the style must be as general as possible so it can be applied in many different situations. This puts a burdan on the person who defines evolution styles. Evolution style specifications include pre- and postconditions. While the preconditions help to verify that the current application is in the right state to apply the evolution style, the postconditions provide information on what the state of the application will be after applying the style. This information can be used to support the definition of valid sequences of evolution style

Proc. Software Evolution 2007 8 / 10 ECEASST invocations [KK04]. As such, evolution styles contribute to ensure application and evolution consistency.

5 Related work

We distinguish between related work on patterns of evolution, and patterns for evolution. The ﬁrst kind attempts to extract commonalities in software evolution activities in order to improve the understanding of evolution. In [NYN+02], the authors outlined recurring working force schemas and recurring steps that are followed in the development of open-source systems. An- other interesting work to that regard is [BKS03], in which the authors consider changes as a phenomenon. They deﬁne life-cycle volatility vectors which allow to classify software applications based on the patterns in the changes which they undergo. The second kind of work tends to help developers by providing recurring practices for various purposes. Refactorings [Fow99] gained popularity and are now embedded in more and more tools. The next step is to integrate patterns for evolution as a natural part in the way software is developed. In order to do that, change classes [Dep07] and change boxes [Zum07] were presented.

6 Conclusion and future work

Patterns are used to specify a solution for recurring problems in their domain and have been proven useful in many different domains such as civil architecture, software design and software evolution. In the software evolution domain, however, only limited use has been made of the pattern principle as only behaviour-preserving patterns (e.g. refactorings) have been asserted. Consequently, developers and architects have been forced to resolve the recurring problems concerning behavioural change. This paper shows that even very different applications (specified in different programming languages and in different problem domains) can be the subject of similar change scenario’s which require a similar adaptation of the application behaviour. We define an evolution style as a domain-specific specification of a solution for a recurring problem in software evolution. An evolution style has a name, a goal and consist of three major parts: (1) the domain – denoting the meta-architecture, (2) the header – describing the style’s interface and (3) the competence – specifying the actions which have to be applied in order to reach the style’s goal. A catalog of different evolution styles should be defined in order to grasp the recurring problems in software evolution. Providing styles for all problems, however, is not possible. Conse- quently, our major track of future work consists in the development of an extensible catalog of evolution styles, which can be queried for patterns.

Acknowledgements: We thank the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT Vlaanderen) for providing Peter Ebraert with a doctoral scholarship to ﬁnance this research. We acknowledge Dalila Tamzalit, Ellen Van Paesschen, Pascal Costanza, Djamel Seriai, Theo D’Hondt and Mourad Oussalah for reviewing, commenting and supporting this research.

9 / 10 Volume X (2007) Evolution styles: change patterns for Software Evolution

Bibliography

[AIS77] C. Alexander, S. Ishikawa, M. Silverstein. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977. [BC87] K. Beck, W. Cunningham. Using pattern languages for object-oriented programs. Technical report CR-87-43, Tektronix Inc., September 1987. [BKS03] E. J. Barry, C. F. Kemerer, S. A. Slaughter. On the uniformity of software evolution patterns. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering. Pp. 106–113. IEEE Computer Society, Washington, DC, USA, 2003. [CHK+01] N. Chapin, J. E. Hale, K. M. Kham, J. F. Ramil, W.-G. Tan. Types of software evolution and software maintenance. Journal of Software Maintenance 13(1):3–30, 2001. [Dep07] B. Depoortere. Reasoning about ﬁrst-class changes for support in software evolution. Master’s thesis, Vrije University, 2007. [DTS99] S. Demeyer, S. Tichelaar, P. Steyaert. FAMIX 2.0 - The FAMOOS Information Ex- change Model. Technical report, University of Berne, 1999. [Fow97] M. Fowler. Analysis Patterns – Reusable Object Models. Addison Wesley, 1997. [Fow99] M. Fowler. Refactoring. Improving the Design of Existing Code. Martin Folwer, 1999. [GHJV94] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994. [KK04] G. Kniesel, H. Koch. Static composition of refactorings. Sci. Comput. Program. 52(1-3):9–51, 2004. [LB85] M. M. Lehman, L. A. Belady (eds.). Program evolution: processes of software change. Academic Press Professional, Inc., San Diego, CA, USA, 1985. [NYN+02] K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida, Y. Ye. Evolution patterns of open-source software systems and communities. In IWPSE ’02: Proceedings of the International Workshop on Principles of Software Evolution. Pp. 76–85. ACM Press, New York, NY, USA, 2002. [Opd92] W. F. Opdyke. Refactoring Object-Oriented Frameworks. Phd thesis, University of Illinois at Urbana Champaign, 1992. [SOTG06] A. Seriai, M. C. Oussalah, D. Tamzalit, O. L. Goaer. A reuse-driven approach to update component-based software architectures. In IEEE IRI: Information Reuse and Integration. Pp. 313–318. 2006. [Zum07] P. Zumkehr. Changeboxes — Modeling Change as a First-Class Entity. Master’s thesis, University of Bern, 2007.

Proc. Software Evolution 2007 10 / 10

ECEASST

Semantic Web Services, a reverse engineering approach for WSMO specification

Houda EL BOUHISSI 1, Mimoun MALKI 2 and Djelloul BOUCHIHA 3

1EEDIS Laboratory, University of Sidi Bel Abbes 22000, Algeria [email protected] 2EEDIS Laboratory, University of Sidi Bel Abbes 22000, Algeria [email protected] 3EEDIS Laboratory, University of Sidi Bel Abbes 22000, Algeria [email protected]

Abstract: Semantic web services are at the convergence of two research fields related to Internet technologies, namely semantic Web and Web services. Several solutions were proposed for the specification of the semantic web services such as OWL-S (Ontology Web Language for services) and WSMO (Web Service Modelling Ontology. However, these technologies require a human user. We propose an approach to create service ontology with specifications WSMO starting from WSDL (Web Service Language Description), SOAP (Simple Object Access Protocol) and UDDI (Universal Description, Discovery and Integration) by using the reverse engineering techniques. Reverse engineering aims to extract several types of information of existing software and to employ this information for comprehension and the renovation as well as the maintenance of the system.

Keywords : Ontology, Semantic Web, Semantic Web Services, Web Services, WSDL, SOAP, UDDI, Reverse engineering.

1 Introduction In recent years, distributed programming paradigms have emerged, that allow generic software components to be developed and shared. Whilst early versions were little more than shared libraries of functions with little user documentation and unpredictable side effects, it wasn’t until the advent of object-oriented programming and architectures such as CORBA, that self contained components could be reliably defined, documented and shared within a distributed environment. Although ideal for some enterprise integration and eCommerce, it has only been with the adoption of XML as common data syntax that the underlying principals have gained wide scale adoption, through the definition of Web Service standards. Web services are well defined, reusable, software components that perform specific, encapsulated tasks via standardized Web-oriented mechanisms. They can be discovered, invoked, and the composition of several services can be choreographed, using well defined workflow modelling frameworks.

Whilst promising to revolutionize eCommerce and enterprise-wide integration, current standard technologies for Web services provide only syntactic- level descriptions of their functionalities, without any formal definition to what the syntactic definitions might mean. In

2 / 12 Volume X (2007) A new approach to specify WSMO

many cases, Web services offer little more than a formally defined invocation interface, with some human oriented metadata that describes what the service does, and which organization developed it. Applications may invoke Web services using a common, extendable communication framework. However, the lack of machine readable semantics necessitates human intervention for automated service discovery and composition within open systems, thus hampering their usage in complex business contexts. Semantic Web Services (SWS) relax this restriction by augmenting Web services with rich formal descriptions of their capabilities, thus facilitating automated composition, discovery, dynamic binding, and invocation of services within an open environment A prerequisite to this, however, is the emergence and evolution of the Semantic Web, which provides the infrastructure for the semantic interoperability of Web Services. Web Services will be augmented with rich formal descriptions of their capabilities, such that they can be utilized by applications or other services without human assistance or highly constrained agreements on interfaces or protocols. Thus, Semantic Web Services have the potential to change the way knowledge and business services are consumed and provided on the Web.

In this paper we survey the state of the art of current enabling technologies for Semantic Web Services. Further, we propose a new approach to specify WSMO from WSDL, SOAP and UDDI using the reverse engineering techniques. Reverse engineering is the process of analyzing a subject system to (1) identify the system’s components and their interrelationships and (2) create representations of the system in another form or at a higher level of abstraction [Chi90].

The rest of the paper is structured as follows: in section 2 we provide a general overview of Web services; in section 3 we provide an overview of the Semantic Web, in section 4, we present the ontology and in section 5 we describe Semantic Web Services. Sections 6 reviews related work according to SWS and section 7 provides a discussion of the main approaches according to SWW. Section 8 presents the main topic of the paper. Finally section 9 presents a conclusion.

2 Web Services Besides its spectacular growth, the Web becomes more dynamic with the advent of the Web service technology. A Web service (WS) is a (self-contained) software component that allows access to its functionality via a Web interface. WSs communicate by employing established protocols for message transport and encoding. Indeed, the W3C Web Services Architecture Working Group defines a Web service as: "A software application identified by an URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML- based messages exchanged via Internet-based protocols” [W3C02] .To define the infrastructure of the Service Web, a stack of interrelated standards, such as SOAP, UDDI and, WSDL are presented. Such standards are denoted in XML and they can be transported via the HTTP over the existing Web infrastructure. The Figure below (FIG.1) shows the main Web service technology standards, an overview of these technologies is provided below.

Proc. Software Evolution 2007 3 / 12

ECEASST

Figure 1: Main components of a Web service 2.1 SOAP The Simple Object Access Protocol (SOAP 1) is a specification for interactions among Web Services across the Internet. SOAP uses XML to exchange structured and typed information.

2.2 WSDL WSDL 2 (Web Service Description Language) is an XML-based language for describing Web services and how to access them. WSDL is also used to locate Web services

2.3 UDDI As services become available, they may be registered with a UDDI 3 registry (Universal Description, Discovery and Integration) which can subsequently be browsed and queried by other users, services and applications.

3 Semantic Web The goal of the Semantic Web is to solve the current limitations of the Web by augmenting Web information with a formal (i.e., machine processable) representation of its meaning. A direct benefit of this machine processable semantics would be the enhancement and automation of several information management tasks, such as search or data integration.

There have been several different approaches to realizing the Semantic Web. These approaches can be distinguished by the type of data sources that they consider for semantic description as well as the richness of the semantic annotation based on ontology.

1 http://www.w3.org/TR/soap12 2 http://www/w3.org/TR/wsdl 3 http://www.uddi.org

4 / 12 Volume X (2007) A new approach to specify WSMO

4 Ontology The term ontology, originating from Philosophy as detailed in [Kiv02] and [Smi01], was adopted by AI researchers to describe formal domain models. Several ontology definitions were provided in the last decades. The most frequently cited definition is that given by Gruber in 1993 [Gru93] according to which an ontology is ”an explicit specification of a conceptualization”.

In other words, an ontology is a domain model (conceptualization) which is explicitly described (specified). Later, in 1997 Borst defines an ontology as a “formal specification of a shared conceptualization” [Bor97]. This definition requires, in addition to Gruber’s definition, that the conceptualization should express a shared view between several parties, a consensus rather than an individual view. Also, this conceptualization should be expressed in a machine readable format (formal). In 1998, [Stu98] merge these two definitions stating that: “An ontology is a formal, explicit specification of a shared conceptualization”. As consensual domain models, the primary role of ontologies is to enhance communication between humans (e.g., establishing a shared vocabulary, explaining the meaning of the shared terms to reach consensus).

The major characteristic of ontology is the level of generality of the specified conceptualization, we adopt three intuitive classes of generality [Gua97]:

1. Foundational (or top-level) ontologies are conceptualizations that contain specifications of domain and problem independent concepts and relations (such as space, time, and matter) based on formal principles derived from linguistics, philosophy, and mathematics.

2. Generic ontologies contain generic knowledge about a certain domain such as medicine, biology, mathematics or Web services.

3. Domain ontologies have the lowest reusability and are specific to a particular domain.

Ontologies serve as metadata schemas, providing a controlled vocabulary of concepts, each with explicitly defined and machine-processable semantics. By defining shared and common domain theories, ontologies help people and machines to communicate concisely— supporting semantics exchange, not just syntax. Hence, the Semantic Web’s success and proliferation depends on quickly and cheaply constructing domain-specific ontologies.

5 Semantic Web Services Current technologies allow usage of Web Services but only syntactical information descriptions, therefore, only provide a set of rigid services that cannot adapt to a changing environment without human intervention. A possible solution to all these problems is likely to be provided by converting Web services to Semantic Web Services, which are semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven semi-automatic way.

Proc. Software Evolution 2007 5 / 12

ECEASST

Semantic Web Service infrastructures can be characterized along three orthogonal dimensions: usage activities, architecture and service ontology [Cab04].

From the usage activities perspective, SWS are seen as objects within a business application execution scenario. The activities required for running an application using SWS include: publishing, discovery, selection, composition, invocation, deployment and ontology management, as described next. From the architecture perspective, SWS are defined by a set of components which realize different activities such publication, discovery, selection, composition, deployment and ontology management, with underlying security and trust mechanisms. The service ontology essentially integrates at the knowledge-level the information which has been defined by Web services standards, such as UDDI and WSDL with related domain knowledge.

Several approaches have been driving the development of Semantic Web Service frameworks: such as: OWL-S [OWL-S03], WSMO [WSMO04], IRSIII [Dom04], WSDL-S [Akk05] and SWSF [Bat05].The following sections describe these approaches in more detail.

6 Approaches to Semantic Web Services

6.1 OWL-S OWL-S is a SWS description language that enriches web service descriptions with semantic information from OWL ontologies [Owl03].The Figure below (FIG.2) shows the three basic elements of a web service defined by OWL-S:

Figure 2: The basic elements of the OWL-S

1. A service profile that describes the capabilities of the service along with additional features that help to define the service ; 2. A Service model that provides a description of the activities of the service and the requester provider interaction protocols; 3. A Service Grounding that is a description of how abstract information exchanges described in the Process Model are mapped to onto actual messages that the provider and the requester exchange.

6 / 12 Volume X (2007) A new approach to specify WSMO

6.2 WSMO Based on the Web Service Modelling Framework (WSMF) [Fen02], but refines this framework and develops a formal ontology and a formal language, the Web Service Modelling Ontology (WSMO) [WSMO04], is a formal ontology and language that consists of four different main elements for describing semantic web services:

1. Ontologies that provide the terminology used by other elements; 2. Goals that state the intentions that should be solved by web services; 3. Web Services descriptions which describe various aspects of a service; 4. Mediators : to resolve interoperability problems.

Each of these WSMO Top Level Elements can be described with non-functional properties like creator, creation date, format, language, owner, rights, source, type, etc. WSMO comes along with a modelling language (WSML 4), a reference implementation (WSMX 5).

6.3 IRS-III IRS-III (Internet Reasoning Service) [Dom04] is a framework and implemented infrastructure which supports the creation of semantic web services according to the WSMO ontology. IRS-III has four main classes of features which distinguish it from other work on semantic web services. Firstly, it supports one-click publishing of ”standard” programming code. In other words, it automatically transforms programming code (currently it supports java and lisp environments) into a web service, by automatically creating the appropriate wrapper. Hence, it is very easy to make existing standalone software available on the net, as web services.

Secondly, by extending the WSMO goal and web service concepts users of IRS-III directly invoke web service via goals i.e. IRS-III supports capability driven service execution. Thirdly, IRS-III is programmable. IRS-III users can substitute their own semantic web services for some of the main IRS-III components. Finally IRS-III services are web service compatible standard web services can be trivially published through the IRS-III and any IRS-III service automatically appears as a standard web service to other web service infrastructures.

6.4 WSDL-S An interesting approach for semi-automatic adding the Data Semantics to WSDL descriptions is proposed in [Akk05] based on the ongoing METEOR-S (Managing End-To-End OpeRations for Semantic Web Services) project [Pat04] of the LSDIS-lab, University of Georgia, collaborating with IBM. METEOR-S focuses on the creation, management and execution of Semantic Web services. This approach adds semantics to the WSDL specification. It involves three steps:

4 http://www.wsmo.org/wsml/ 5 http://www.wsmx.org/

Proc. Software Evolution 2007 7 / 12

ECEASST

1. Annotation of XML Schema with domain ontology; 2. Pre-conditions and effects for WSDL operations; 3. Web Service categorization by ontology-based keywords;

6.5 SWSF Another W3C submission beside OWL-S and WSMO is the Semantic Web Services Framework (SWSF) [Bat05] which represents an attempt to extend the work of OWL-S and consists of two major parts: the Semantic Web Service Language SWSL 6 and the ontology SWSO 7. Both were developed on basis of two different logics: the first-order logic within FLOWS (First-order Logic Ontology for Web Services) and based on logic programming the Rules Ontology for Web Services (ROWS).

7 Discussion We have described the current main approaches to Semantic Web Services. This comparison discusses the delivered results of IRS-III, OWL-S, WSMO, SWSF and WSDL-S (SWWS) as they represent the main approaches driving the implementation of Semantic Web Service components, each of which has gained some momentum and addresses some pragmatic aspects.

These approaches are complementary in many ways and can be compared according to different dimensions of SWS. Each initiative can be characterized in terms of (1) a conceptual model describing the underlying principles and assumptions; and (2) a language or a set of languages that provide the means to realize the model.

The WSDL-S approach is a more technology centered strategy, where rather than providing a conceptual model for the description of Web services and their related aspects, it takes a bottom-up approach by annotating existing standards with metadata. WSDL-S can actually be used to represent a grounding mechanism for WSMO. IRS-III approach is integrated with the WSMO approach in the sense that IRS-III uses WSMO as its underlying epistemological framework. However, these technologies require a human user in the loop for selecting services available in registries. We propose an approach for WSMO specification from WSDL, SOAP and UDDI using reverse engineering techniques.

8 Our Contribution Our contribution consists to describe and implement WS2WSMO (Web Service to Web Service Modelling Language), a semi automatic system for the translation of the WSDL, SOAP and UDDI in partial specifications WSMO. WS2WSMO is roughly based on the following observations:

6 http://www.w3.org/Submission/SWSF-SWSL/ 7 http://www.w3.org/Submission/SWSF-SWSO/

8 / 12 Volume X (2007) A new approach to specify WSMO

_ Since one is in the context Web application, the customers generally request the services through forms where they introduce their data and wish results. What thus brings back to us to saying that the objectives of the customers coincide with the structure of the different service but they in the introduced data and the provided or awaited results. _ WSDL File expresses the inputs and outputs with Tags “part” introduced into tags “message”, the first tag “part” represents the inputs which are classified by order and the second tag “part” represents the outputs, therefore the elements of these tags are represented like main information which will be translated to concepts with domain ontologies.

_ SOAP Protocol constitutes a mean of communication between the customer and the service provider, therefore the values introduced by the customers appear in requests SOAP, with the result that these values represent the instances of the concepts found previously.

_ Web service application contains a whole of information expressed in a certain manner which is not necessarily accepted, however, the importation of external domain ontologies is a need to solve the problem of semantic interoperability between the other elements of the WSMO.

_ The data model UDDI is defined in the form of diagram XML, the "businessEntities" are to some extent the white pages of a directory UDDI and they describe the organizations having published services in the repertory. One will find there in particular the name of the organization, his addresses (physical and Web), of the elements of classification, a list of contacts... Each “businessEntity” is identified by a "businessKey", these informations will represent the non functional properties embedded in each to element of WSMO.

WS2WSMO is a semi automatic system implemented with the eclipse platform with the Java language and contains a whole of modules as presented in figure 3:

Proc. Software Evolution 2007 9 / 12

ECEASST

Figure 3: WS2WSMO System Architecture

_ WSDL Extractor: This module extracts the terms from the tags “Part” from the WSDL file ; _ SOAP Extractor: This module extracts the values given by the user (instances) from file SOAP ; _ Analyzer: This module analyzes the found terms in WSDL, then upper load a domain ontology , calculates the semantic distance between the concepts of ontology and those found (from WSDL) by defining a threshold of confidence in order to add the concepts of the ontology and the other elements like axioms, the properties, relations,…etc. _ WSML Converter: This module writes the goals, the Web services and ontologies according to the syntax of the WSML;

As a result, we obtain a partial specification of the WSMO, which will reduce the load to the originator for the manual definition of the specifications of the WSMO.

10 / 12 Volume X (2007) A new approach to specify WSMO

9 Conclusion Summarizing, Semantic Web Services are an emerging area of research and currently all the supporting technologies are still far from the final product. There are technologies available for creating distributed applications which rely on the execution of Web services deployed on the WWW; however, these technologies require a human user in the loop for selecting services available in registries.

We have described the current main approaches of Semantic Web Services: such as OWL-S, IRS-III, WSMO, SWSF and WSDL-S and we have proposed a new approach, reverse engineering based to specify WSMO from WSDL, SOAP and UDDI. Nevertheless, there are still a number of issues concerning Semantic Web Services being investigated in a number of initiatives. These issues will have the attention of industry and academia for the next few years.

Bibliography

[Akk05] Akkiraju, R., Farrell, J., Miller, J., Nagarajan, M., Schmidt, M., Sheth, A., & Verma, K. (2005), Web Service Semantics - WSDL-S, W3C Member Submission 7 November 2005, Retrieved April 4, 2006, from http://www.w3.org/Submission/2005/SUBM -WSDL-S- 20051107/

[Bat05] Battle, S. et al.: “Semantic Web Services Framework (SWSF) Overview”, September 2005, W3C Member Submission.

[Bor97] Borst, W. (1997). Construction of Engineering Ontologies. PhD thesis, University of Tweente, Enschede, NL–Centre for Telematica and Information Technology.

[Cab04] Cabral, L., Domingue, J., Motta, E., Payne, T., and Hakimpour, F. (2004). Approaches to Semantic Web Services: An Overview and Comparisons. In (Bussler et al., 2004), pages 225 – 239.

[Chi90] Chikofsky E.J., Cross II J.H.: Reverse engineering and design recovery: A taxonomy . IEEE Software , 13, 1990.

[Dom04] Domingue, J.; Cabral, L.; Hakimpour, F.; Sell D.; Motta, E. (2004). IRS III: A Platform and Infrastructure for Creating WSMO-based Semantic Web Services. Proceedings of the Workshop on WSMO Implementations (WIW 2004) Frankfurt, Germany, September 29-30, 2004, CEUR Workshop Proceedings, ISSN 1613- 0073.Available from http://sunsite.informatik.rwth- aachen.de/Publications/CEURWS// Vol-113/paper3.pdf.

[Fen02] Fensel, D., Bussler, C. The Web Service Modeling Framework WSMF. Eletronic Commerce: Research and Applications. Vol. 1. (2002). 113-137.

[Gua97] Guarino, N. (1997). Semantic Matching: Formal Ontological Distinctions for

Proc. Software Evolution 2007 11 / 12

ECEASST

Information Organization, Extraction, and Integration. In Pazienza, M., editor, Information Extraction: A Multidisciplinary Approach to an Emerging Information technology, volume 1299 of LNCS, pages 139 – 170. Springer- Verlag.

[Gru93] Gruber, T. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2):199 – 220.

[Kiv02] Kivela, A. and Hyvonen, E. (2002). Ontological Theories for the Semantic Web. In (Hyvonen, 2002).

[OWL-S03] OWL Services Coalition, OWL-S: Semantic Markup for Web Services, Dec 2003, http://www.daml.org/services/owls/1.0/owl-s.html.

[Pat04] Patil, A. A., Oundhakar, S. A., Sheth, A. P., and Verma, Kunal (2004), METEOR-S Web Service Annotation Framework, WWW 2004, ACM Press, 553-562

[Smi01] Smith, B. and Welty, C. (2001). FOIS introduction: Ontology—towards a new synthesis. In Proceedings of the International Conference on Formal Ontology in Information Systems, pages 3 – 9, Ogunquit, Maine, USA. ACM Press.

[Stu98] Studer, R., Benjamins, V., and Fensel, D. (1998). Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering, 25(1-2):161 – 197.

[W3C02] Web services architecture requirements, W3C Web Services Architecture Working Draft, Available online at: http://www.w3.org/TR/2002/ WD-wsa-reqs- 20021114.

[WSMO04] WSMO Working Group. Web Service Modelling Ontology Project. DERI Working Drafts. http://www.nextwebgeneration.org/projects/wsmo/ (2004).

12 / 12 Volume X (2007) ECEASST

CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution

Christopher Ackermann1, Nico Zazworka2

[email protected] Fraunhofer Center Maryland

[email protected] University of Maryland

Abstract: Experimental studies have been used extensively to gather data about software evolution with the goal to optimize development processes and provide tool support. Often times a large amount of data is collected but there is no strategy in place to analyze this information and extract valuable observations. At the same time the area of information visualization has been steadily growing as analysts start recognizing the power of appropriate visualization. We propose a solution to visualize software evolutionary data in a way that allows analysts to quickly capture interesting patterns and use interactive features to gain further insight to ultimately derive valuable information. Addressing the issues researchers of the High Productivity Computing Systems (HPCS) project were facing when analyzing source code ﬁles, we developed a visualization tool called Code- Vizard to support the analysis of software evolutionary data. CodeVizard provides both high level information as well as details about the system and its modiﬁcations and features to quickly explore a large amount of data. Keywords: Software Evolution, Software Visualization, Software Maintenance

1 Introduction

Researchers and practitioners have been struggling to comprehend the characteristics of software evolution. The reasons are, first, that every software product is unique and it is difficult to establish generalizable rules that pertain to all software systems [ME98]. Secondly, it is not clear what measures can be used to evaluate a software product and the changes that are applied to it. There has been extensive research in finding software metrics that can be used to describe interesting software properties, such as size measures and design complexity measures [MD01]. However, it is difficult to reason about software solely based on metrics as there are numerous factors that need to be taken into account. It is, therefore, necessary to include low level information into the analysis process that can help to understand the metric values at a certain point and also to support or refute claims made based on an evaluation of metrics. We propose an approach to combine high level data with more detailed information to allow for analyzing a large amount of software evolutionary data on any level of detail. We imple-

1 / 10 Volume X (2007) CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution mented this approach in a visualization tool called CodeVizard. It illustrates high level information in a special kind of bar graph and reveals details of software system and maintenance characteristics using a zoomable source code panel.

2 Objective

While the general goal of this research was to develop a technique that facilitates understanding of the process of software evolution, it was motivated by concrete needs of researchers facing the issues many encounter when attempting to analyze software development data.

2.1 HPCS The issues we are addressing emerged during work done by researchers of the Development Time Working Group as part of the High Productivity Computing Systems (HPCS) project. Aiming to analyze the productivity of programmers that are new to High Performance Computing (HPC), the researchers captured data from over 20 HPC classes at several universities [Nak04]. Various measurements such as effort data, defect rates, background information and work ﬂow data were recorded to evaluate how student programmers work and learn. The results should allow the researchers to give advice to vendors, create tools to improve productivity and to establish new learning concepts for HPC.

2.1.1 Analysis goals In order to approach the analysis of HPC development, the researchers created a list of more concrete analysis targets: Domain-specific obstacles: Since High Performance Computing distinguishes itself from other programming approaches in several ways, the researchers were particularly interested in the obstacles the subjects experiences that were specific to HPC. Defect Types: As there are domain-specific obstacles in HPC, the type of defects found in systems developed with this approach are also specific. The goal is to identify the types of defects introduced due to domain-specific obstacles and the circumstances that led to them. Debugging: Closely related to the previous point, this addresses the question as to how the subjects went about fixing the defects. Development phases: One of the main objectives was the identification of so called development phases in the recorded student programs. The goal was to establish knowledge about what kind of development phases and the characteristics thereof. One approach divides the development process into phases of work and rework. “Work” being the implementation of new features and “rework” being structural or functional modifications to existing features.

2.1.2 Analysis Issues The data analysis was conducted in collaboration among several researchers over an extended period of time. This was done with use of basic information retrieval and analysis tools, such as spread sheets and line graphs. Despite the high level of experience with the domain, the

Proc. Software Evolution 2007 2 / 10 ECEASST researchers reportedly struggled with the analysis. This was due to the amount and detail of information that was captured and also due to general issues of software evolutionary analysis as stated above. In particular, four main issues were disclosed: Analyzing progress over time. In order to detect interesting characteristics of a software evolutionary process, it is necessary not to merely analyze a single version (e.g. the final version) of a file, but to consider a number of code versions over time. The researchers could not find appropriate tool support for this type of analysis task. Information overload. Due to the fact that detailed data from many studies were collected, the researchers had a large amount of data available. This prevented the researchers from getting an overview of the information, which they expressed to be a necessity. Information delocalized. The different pieces of information that were gathered during the class studies were not accessible at one location, but stored at different places and formats. Implicit Information. Another challenge in understanding the development process was the high amount of implicit data. For instance, the total number of lines of code of a version or the amount of code added in between two versions are important properties. However, they are not directly accessible as they are only implicitly contained in the source code.

3 CodeVizard - Background

The goal of this research was to build a tool to support the aforementioned analysis goals and resolve the above issues with which the HPCS researchers were struggling. We used techniques from the information visualization domain to approach this challenge and developed a tool called CodeVizard. We will ﬁrst explain the underlying idea of CodeVizard and will then elaborate on its different components and, in particular, the graphical user interface.

3.1 Visualization Concepts The key difference between analyses of single system states and software evolutionary processes is the time factor. Since software evolution describes how a software system evolves over time, it is often necessary to consider a large number of system versions, which also means an enormous amount of data as mentioned by the researchers of HPC. The requirement of handling this data in a space and time efficient manner adds to the challenge of every software tool that aims to support software evolutionary analysis. CodeVizard is implemented in a way that analysis can be conducted quickly despite the amount of data displayed. Since the analysis done by the researchers of the Time Development Working Group focused on single files from individual subjects, we decided to set the same scope for CodeVizard. We recognize that the analysis of single files limits the applicability of CodeVizard but we believe that it best addresses the issues stated by the HPC researchers. Extending the tool to handle multiple files is one of the future goals. The underlying approach of CodeVizard for analyzing software evolutionary processes is the combination of abstraction and detail. Abstraction. Meta data such as metrics can be used to visualize software evolution on a high level of abstraction; the advantage being that many versions of a source code file can be analyzed

3 / 10 Volume X (2007) CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution at once. A plethora of metrics exists to measure various characteristics of software and can be used to describe the properties of a system that are of interest. Abstract visualization, therefore, supports the analyst in quickly detecting interesting patterns and anomalies of certain software characteristics. Detail. While abstract information is useful to derive a high level picture, it fails to take into account details that are crucial for drawing conclusions pertaining to the development behavior. For instance, when only considering the amount of lines added to a system, one could argue that major code additions illustrate the addition of new features. However, the lines could simply be comments. We see that to be able to draw deﬁnite conclusions, one must support high level observations with more detailed information. A second main goal was therefore to also provide detailed information about the recorded software evolutionary process. CodeVizard is composed of three main modules: the data reader, the computation module, and the graphical interface. It is currently possible to read source code and meta information from databases and Subversion repositories. The computation component can automatically compute several metrics (LOC added, modiﬁed, deleted) and could be extended. The core part of CodeVizard is the graphical user interface with the metric view and the code view (Figure1), both of which will be explained in the next sections.

Figure 1: An overview of CodeVizard. The top is the metric view and the bottom is the code view.

4 CodeVizard - Metric View

The analysis of software is often guided by software metrics that describe different characteristics, such as change proneness and coupling. The purpose of the metric view is to visualize these code metrics. Software metrics are measures of properties of pieces of software or its spec- iﬁcations. They provide a quantitative basis for the development and validation of models of the software development process [Mil88]. Researchers have used software metrics to analyze software evolution in various ways and from different angles. A thorough analysis requires considering not only one but multiple metrics at once. We used advanced visualization concepts to display up to four different metrics using a special kind of bar graph where each bar represents one code version that was captured during software development. The following four bar attributes are used to display the different dimensions:

Proc. Software Evolution 2007 4 / 10 ECEASST

Width. The x-axis of the metric view represents a time line of the software development process. The width of the bar indicates how much time passed between capturing two versions. The corresponding code version for a bar is the one that was captured at the end of the bar. For instance, if the bar expresses that a high number of lines were added over 20 min, that means that the version that was captured after this 20 minutes had a large number of additional source code lines. This will become clearer when describing different analysis scenarios in the succeeding chapter. Position on the y-axis. The position of each bar on the y-axis corresponds to a metric value. The bars that are aligned on the bottom of the graph intuitively have low values and the bars on the top have high values. Thickness. Another dimension is expressed by the thickness of the bars. A thin bar indicates that the version has a low value for the respective metric. A thick bar signals high values. Color. The use of color can guide analysts in their work by highlighting important information [Mac99], which are often times extreme values. In order to express a fourth dimension we used color coding. Low values are represented a light green color and high values are indicated by a dark red color. The closer a metric value is to the medium the more subtle the color is. In order to avoid an information overload and make the display less densely populated, the range of input values for each metric is discretized by mapping the real input values to a limited and variable number of discrete values. While the discretization provides a clearer picture it preserves enough detail to make qualitative judgements and ﬁnd interesting patterns. Using novel visualization concepts, the metric view can display up to 4 different software metrics at any time and yet does not overwhelm the analyst with information.

5 CodeVizard - Code View

The second component of CodeVizard is its code view. The purpose of the code view is to allow the user to explore further details of the change and the file versions. A typical scenario would be that an analyst identifies a change in which many lines of code were added in the metric view. The analyst can then use the code view to zoom in on the change up to the actual source code. This enables the analyst to find out whether or not the change was mainly comments, the name of a method if a new method was added or, other information. The code view basically shows the source code of all file versions lined up horizontally. Tran- sitions between the versions illustrate the kind of change every source code line experienced (line added, modified, or deleted) or indicates when a line remained unaltered. The software visualization tool Seesoft illustrates source code versions in a similiar way but is limited to display only a single version of a system [ESE92]. The code view is not static but allows the user to zoom in and out of the code view and get a different perspective of the source code from an abstract overview to a detailed illustration of a few versions. While the zooming is continuous, the code view adjusts the amount of semantic information based on the zoom factor (semantic zooming). When zooming out, the source code details are hidden to allow for better zooming performance and to provide the analyst only with the information that can be captured on that level of abstraction. Likewise, zooming into the code view reveals more details up to a point where the actual source code is displayed.

5 / 10 Volume X (2007) CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution

Figure 2: Code view: The three levels of the semantic zoom.

We distinguish 3 semantic zooming levels that are different in the kind of semantic information they show. Code Block Level. At the lowest zooming level the code versions are visualized as blocks (solidly colored rectangles), where the height of the block represents the length of the source code, i.e. the total number of lines of code. Since only little information for each version is displayed, all version fit on the screen and the view reveals how the size of the file changed over time. Furthermore, the analyst can spot change patterns, such as certain source code regions that were frequently modified. Also, anomalies such as the deletion or modification of a larger set of lines become visible immediately. Even more specific questions, such as how stable a newly added set of source code lines was in subsequent versions can be answered readily. Code Representative Level. By zooming further into the view, the code blocks turn into a code representative level in which the outline of single source code lines are shown. Dark lines indicate the outline of the source code, which reveals details such as the line indention and length. Also, the shapes that indicate the maintenance activities show single lines. Presuming that code was formatted by the programmer (e.g. code indent, empty lines between logical modules) the analyst can derive more insight into which part of the code (method, class, loop construct) was affected by the maintenance activities. Code Text Level. On the most detailed level, the actual source code is displayed so that the analyst can explore more details about the source code versions and the maintenance activities they experienced. For instance, it is possible to see the name of a variable that was modified, the name of the method deleted, etc.

5.1 Transitions As mentioned above, the maintenance activities that were applied to the different versions of the source code file are illustrated as transitions between the blocks representing the versions. The source code line of one version is connected with the corresponding source code line of the preceding and succeeding versions. In places were the file experienced change, the maintenance activity is indicated using objects of different shapes and colors. A dark blue line indicates that the source code line was modified in between the two versions. For lines that only exist in the predecessor code - in that case lines were deleted - a red triangle is drawn. Lines just existent in

Proc. Software Evolution 2007 6 / 10 ECEASST

Figure 3: Objects of different shape and color indicate the different maintenance activities. the successor - newly added lines - are represented by green triangles (see Figure3). Other information visualization tools that focus on software evolutionary data also use novel visualization techniques for illustrating metric values[VT06]. The approach of combining this rather abstract information with the details contained in the code view, however, is to our knowledge new and unique.

6 Analysis Scenarios

CodeVizard was developed with certain analysis scenarios in mind, i.e. an idea of how the tool could be used to conduct the analysis tasks. For the following scenarios we will use a dataset that was recorded during a student’s implementation of “Game of life”, which is a small scale program with a total of 220 number of lines of code. A version of the source code was captured at every compile. The dataset consisted of 160 versions that were developed over a total of 36 hours. The metrics we will use for scenarios are entirely computed by CodeVizard and include for each version:

• Total LOC. The total number of source code lines.

• LOC added / modiﬁed / deleted. The number of source code lines that were added, modi- ﬁed, and deleted to reach the version.

• Change Amount. A variable describing the total maintenance effort that was applied to reach the current version. It is computed as follows: ChangeAmount = LOCadded + LOCmodi fied + LOCdeleted.

When the data is initially loaded into CodeVizard, the three dimensions–y-position, color, and thickness–that are encoded in the bars are set to the same metric: total LOC.

6.1 Scenario I One question asked in the case study was to identify the phases of work and rework. We loosely deﬁned “work” as addition of new features and “rework” as structural or functional changes. More speciﬁcally, we asked the subjects to roughly divide the entire development process into these two phases. CodeVizard offers two possibilities to conduct such an analysis, either by using the metric view or the code view. We will now explain both approaches.

7 / 10 Volume X (2007) CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution

Figure 4: Phases of work and rework identified using the code view. The transitions that are predominantly green signal a high amount of change and can be identified as work phases. The transitions with blue and red lines represent code modification and deletions, respectively. They show rework phases.

Metric view. The basic idea of identifying the implementation of new features is to identify the versions in the code that experienced a lot of additions. Modifications and deletions will be considered as rework activities. Of course, these conventions are not exact but sufficient to illustrate the concepts. A more accurate and detailed analysis can be conducted by using both the metric and the code view. In order to identify the versions with the “work” characteristics, we highlighted the version with many code additions by simply setting the y-axis to represent the LOC added. The color and the height of the bars are set to represent the LOC modified and LOC deleted, respectively. The work phases are now illustrated by the bars that are positioned higher up on the y-axis. The light color bars indicate low change amount and the thinner bar represents few LOC deleted. Figure4 shows the setup of the metric view that reveals the information described. Code view. The code view illustrates the maintenance activities (LOC added, modified, and deleted) through color coding as mentioned above. To identify work phases, one can simply look for versions whose transitions leading up to them have “a lot of green,” i.e. major code additions. Blue and red marks illustrate rework phases as they express code modifications and deletions.

6.2 Scenario II

As the motto of information visualization is “Discovering the unexpected,” it is not surprising that we found several interesting patterns and anomalies in the datasets we analyzed. We ﬁrst used the metric view to look for versions which had extreme change amount values, i.e. exceptionally low or high. We discovered that the subject had applied an exceptionally high amount of change to a number of consecutive versions (see Figure5). After taking a closer look at the source code, we discovered that the added code section remained unchanged for the rest of the development process. This is especially interesting since the programmer seemed to have struggled when adding rather small functionality at the beginning of the program development. The reason could be that the student copied the new functionality from his classmate. This is just one example of the patterns we found when applying CodeVizard to the given dataset, but it already shows what interesting patterns a quick analysis can reveal. While Code- Vizard does not provide ﬁnal answers, it offers strong support reasoning and other sense-making processes.

Proc. Software Evolution 2007 8 / 10 ECEASST

Figure 5: Scenario II - The metric view clearly shows the two versions that experienced major additions. Analyzing the code on a high level of abstraction reveals that the added code sections remained unchanged.

7 Case Study

In order to evaluate the efﬁciency of CodeVizard we conducted several case studies. The general goal of the studies was to determine whether CodeVizard can support analysts in ﬁnding the patterns of interest and quickly retrieve valuable information from the available data. The case studies were conducted with six participants, three of which were senior scientists and three of which were experienced graduate students. None of the participants took part in the tool development or was familiar with CodeVizard. The participants received a brief introduction into the features of the tool, a list of tasks, and a questionnaire to capture their perception of CodeVizard. After the participants executed some simple tasks to get used to the tool, they went on to identify complex patterns in the software evolutionary process. For instance, one of the questions asked the participants to identify the phases of work and rework.

7.1 Results The case studies showed that the participants were not only able to conduct the simple introductory tasks but could also quickly divide the evolutionary process in work and rework phases. The evaluation of the debrieﬁng questionnaires revealed that the overall impression of Code- Vizard was very positive. Among the features that the participants liked most were the ability of the tool to combine high level metrics with source code details and the easy handling. Since the researchers of HPC had conducted the tasks of identifying work and rework phases without the support of CodeVizard, we know that it is normally cumbersome and time consuming. Using our tool, however, the participants were able to reason about the development phases and conduct the same task in a fraction of the time. We can, therefore, say that CodeVizard successfully addressed the issues that motivated this work.

9 / 10 Volume X (2007) CodeVizard: Combining Abstraction and Detail for Reasoning About Software Evolution

8 Conclusion and Future Work

The work described in this paper aimed to tackle some of the concrete issues researchers encountered when analyzing software evolutionary data by using techniques from the field of information visualization as a means of presenting the right amount of data, at the right amount of detail at a right point in the analysis process. At the beginning of this endavour, we interviewed the researchers of HPC and listed the analysis goals and the issues the reasearchers encountered during their analyses. Each issue was taken into account and addressed with the features of CodeVizard. The positive feedback that we received when we conducted a number of case studies indicates that we achieved our goal of making the task of analyzing software evolutionary data less cumbersome and more time efficient. The case studies also produced useful critique how CodeVizard could be improved. Requested functionality include the ability to handle multiple files rather than a single one, a comparison functionality for multiple code files, and an annotation feature that could be used to capture findings and mark detected patterns. Our goal for future work is to continue improving CodeVizard based on these points.

Bibliography

[ESE92] S. G. Eick, J. L. Steffen, J. Eric E. Sumner. Seesoft-A Tool for Visualizing Line Ori- ented Software Statistics. IEEE Trans. Softw. Eng. 18(11):957–968, 1992.

[Mac99] L. W. MacDonald. Tutorial: Using Color Effectively in Computer Graphics. IEEE Comput. Graph. Appl. 19(4):20–35, 1999.

[MD01] T. Mens, S. Demeyer. Future trends in software evolution metrics. In IWPSE ’01: Proceedings of the 4th International Workshop on Principles of Software Evolution. Pp. 83–86. ACM Press, New York, NY, USA, 2001.

[ME98] J. C. Munson, S. G. Elbaum. Code Churn: A Measure for Estimating the Impact of Code Change. In ICSM ’98: Proceedings of the International Conference on Software Maintenance. P. 24. IEEE Computer Society, Washington, DC, USA, 1998.

[Mil88] E. E. Mills. Software Metrics. Technical report, Seattle University, 1988.

[Nak04] T. Nakamura. Challenges in Measuring HPCS Learner Productivity in an Age of Ubiq- uitous Computing: The HPCS Program. In Proceedings of the ﬁrst International Work- shop on Software Engineering for High Performance Computing System Applications. Pp. 27–31. 2004.

[VT06] L. Voinea, A. Telea. Multiscale and multivariate visualizations of software evolution. In SoftVis ’06: Proceedings of the 2006 ACM symposium on Software visualization. Pp. 115–124. ACM Press, New York, NY, USA, 2006.

Proc. Software Evolution 2007 10 / 10 ECEASST

dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

Bart Elen, Nico Janssens, Wouter Joosen, Pierre Verbaeten

[email protected] IBBT-DistriNet, Department of Computer Science, K.U.Leuven Celestijnenlaan 200A, B-3001 Leuven, Belgium

Abstract: Distributed applications in evolving environments are typically difﬁcult to maintain. An example of such an application is the advertisement application for the public transportation buses of ’De Lijn’ in the IBBT-SPAMM project. The advertisement application is here executed on a back-end server as well as on public transportation buses with wireless network connectivity and an onboard advertisement display. The distributed environment of this application will ’evolve’ in different ways during the following years: 1) Devices (buses) will be added to and removed from the distributed environment. Some of the new devices (new buses) may differ signiﬁ- cantly from the currently used ones causing heterogeneity in the distributed environment. 2) Peripheral devices (e.g. advertisement displays) will be added, removed and replaced. Currently, human intervention is needed to maintain the application and adapt it to its changed environment. We need to: deploy application software on the added devices (buses), replace application software on the changed devices (e.g. to support the new advertisement display), and remove application software when no longer useful (e.g. because it requires an advertisement display which is removed). When the distributed environment becomes too large, or changes too often, manual software maintenance is no longer a feasible option. Automation is required. This paper reports on our ongoing work on dEVOLVe, a new OSGi based middleware platform which will automate some software maintenance tasks in ’distributed evolving environments’. dEVOLVe will detect changes in the distributed environment and will adapt the application accordingly. This way, the user is free from software maintenance tasks caused by the environment evolution. Keywords: Software maintenance, distributed evolving environment, middleware

1 Introduction

A large amount of devices with computing power (cars, VCR’s, cell phones, ...) have been introduced on the market during the last decades. A new trend is that those devices are being equipped with network connectivity. Those newly formed distributed environments provide a promising platform for new distributed applications. An example of such an application is the advertisement application of the IBBT-SPAMM project [IBB]. In this project, public transportation buses

1 / 11 Volume X (2007) dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

of ’De Lijn’ [del] are equipped with an onboard computer, a wireless network connection and an advertisement display. The advertisement client application is executed on the company back- end application server. With this client, advertisements are sent to the advertisement server applications, running on the different buses, which will show them on the advertisement displays of the buses. Figure 1 gives an overview of the distributed environment of the advertisement application.

Figure 1: Distributed evolving environment of advertisement application

We can distinguish 3 types of evolution in this distributed environment:

1. Devices (buses) will be added to and removed from the distributed application. The added devices (buses) can differ from the previously used ones in system software (e.g. new Java Virtual Machine (JVM)) and/or hardware (e.g. new type of advertisement displays), introducing heterogeneity in the distributed environment.

2. The employed devices will change over time when peripherals are added to or removed from the devices. For instance, busses which are upgraded after some years of service with new types of advertisement displays.

3. The application software itself will evolve: new features will be added, bugs will be ﬁxed, ... .

We focus in this paper on middleware support for the ﬁrst two types of evolution. Software evolution and application life cycle management in distributed environments are currently not fully covered in our research. Changes in the distributed environment may require an adaptation of the application software: 1) When a device (bus) is added to the distributed environment, the appropriate application software must be deployed on it. 2) When a device changes (e.g. a peripheral device is added), it may be required to replace the application software (e.g. to support the new advertisement display). 3) Application software can become useless after a change in the distributed environment (e.g. because it requires an advertisement display which is removed). This application software should be stopped or removed to free resources.

Proc. Software Evolution 2007 2 / 11 ECEASST

The adaptation of the application software is made harder by the heterogeneity in the distributed environments. Application software imposes requirements to its execution environment. It typically requires a certain JVM, the presence of certain devices or peripherals (e.g. an advertisement display), ... . Hence, in a heterogeneous environment, different application software is needed on different devices for the same task. Human intervention is currently needed to maintain applications in distributed evolving environments; to detect the changes in the distributed environment, to determine the best fitted application software for this environment, and to deploy the selected software on the correct devices. In large distributed environments that change a lot over time, software maintenance is complex, time consuming and error-prone. Therefore, middleware support is needed to automate the software maintenance tasks caused by the evolution of the distributed environment. The main contribution of this paper is an OSGi [osg] based middleware platform, called dE- VOLVe, which automates software maintenance tasks in ’distributed evolving environments’. The middleware will adapt distributed applications towards their changing environment by ful- filling the following tasks: 1) Determining the properties of the distributed environment. 2) Detecting the addition and removal of devices in the distributed environment. 3) Detecting when the peripherals of the devices change. 4) Selecting the application software, best fitted for the execution environment. 5) Automatically deploying the selected software on the correct devices. 6) Detecting the presence of software that is no longer needed and removing it from the application. The remainder of this paper is structured as follows. In section 2, we present the requirements for software maintenance middleware for distributed evolving environments. Section 3 demonstrates how an important part of our middleware requirements can be realized with existing OSGi technology. Section 4 enumerates the major functionalities with which dEVOLVe extends the OSGi service platform. In section 5, we compare our middleware platform with some state-of-the-art middleware platforms for software maintenance in distributed evolving environments. Section 6 concludes this paper and describes future directions.

2 Middleware requirements

In this section, we identify the main requirements for software maintenance middleware for distributed evolving environments. First, we explain why we see a component based application architecture with service dependencies as a pre-requisite. Second, we describe a use case of the advertisement application to identify the middleware requirements.

2.1 Pre-requisite As a pre-requisite, we require for all applications a component based architecture and the usage of service dependencies [BC02]. The component based architecture limits the amount of application software that has to be replaced when the execution environment changes. An example is given in Figure 2. When a large advertisement display is added to the execution environment, the monolithic application architecture requires the replacement of the complete application. In case of a component based architecture however, only the adaptation of a part of the application is required. The usage of service bindings between the components allows the application to be

3 / 11 Volume X (2007) dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

rewired at-runtime.

Figure 2: A monolithic (a) and a component based (b) application architecture in an evolving environment

2.2 Advertisement application use case We identify the middleware requirements with a use case of the ’De Lijn’ advertisement application. Figure 3 gives a simpliﬁed representation of the component based application composition at two moments in time. The left part of Figure 3 shows the advertisement application running on two identical busses and on the back-end server. The right part of the ﬁgure shows how the execution environment may become over time. The advertisement display of one bus (a) is replaced by a large one, and a new model bus (b) is added with future system software (Java Standard Edi- tion 8) and two large advertisement displays. To support this evolution, the middleware platform must be able to:

• Detect the replacement of the advertisement display on the second bus by a new model with different possibilities: Environment evolution, determining local environment properties • Select the application software best ﬁtted for the large advertisement display. Automati- cally deploy the selected application software on the second bus. Rewire the application software to replace the old ’Small display advertisement policy’-component by the new ’Large display advertisement policy’-component: Local automatic application composition, Automatic software deployment

Proc. Software Evolution 2007 4 / 11 ECEASST

Figure 3: Advertisement application in distributed evolving environment

• Detect the adding of a new bus to the execution environment: Environment evolution, group discovery • Detect the difference in system software (JVM) and peripheral devices between the new bus and the other busses: Determining local environment properties • Select the best ﬁtted application software for this bus, install it on the bus and wire it in the distributed application: Local automatic application composition, automatic software deployment Further, there are two additional requirements: • The application software on the back-end server requires a ’busAdvertisementService’ from the buses (not represented in ﬁgure). The middleware platform must be able to resolve remote dependencies. Remote dependencies • The remote dependencies (between software components on back-end server and bus) must also be resolved during the automatic wiring of distributed applications: Distributed automatic application composition

3 OSGi service platform

The OSGi [osg] service platform has support for component based architectures, service dependencies and application life cycle management. In this section, we describe how the OSGi service platform can be used to fulﬁll a subset of the middleware requirements identiﬁed in section 2. First, we demonstrate how local environment properties can be determined with OSGi. Second, we show how OSGi can be used to compose an application composition, adapted to the local execution environment.

5 / 11 Volume X (2007) dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

3.1 Determining local environment properties The OSGi service platform is able to determine different kinds of environment properties. It identiﬁes the underlying JVM and checks the JVM requirements of each application component before deployment. Further, OSGi can be used to detect the presence of peripheral devices (displays, sensors, actuators, ...) and to identify their offered functionality by using peripheral devices which are able to register themselves with the OSGi platform as services [KBY+06, RHKB05].

3.2 Local automatic application composition The middleware platform must be able to automatically compose new application compositions, adapted to the local environment. To make this possible, we equip each application with an application-root component. This component describes which critical functionality must be offered by the application during its complete lifespan. It distinguishes itself from the other components in two ways. First, this is the only component of the application for which we don’t allow the middleware to replace it automatically. We made this choice to guarantee that the critical functionality of the application is maintained. The second difference is that this is the only application component which does not have to offer any services to other application components. This is because we start the application composition from this component. The middleware platform automatically composes the application by resolving the service requirements of the application-root component with application components best fitted for the local environment. The root component in the ’De Lijn’ advertisement application (Figure 3), is the ’Management GUI’-component. When the local environment properties are determined, the middleware has to adapt the application composition accordingly. First, the middleware has to determine the best fitted application composition for this environment by resolving the service requirements of the application-root component. If not locally available yet, the middleware has to download and install the application components of the selected application composition. Once all needed application components are installed on the local platform, the middleware needs to wire them in the distributed application. We are currently working on an implementation of our middleware platform. In this implementation, we are using the OSGi Bundle Repository Service or OBR [OBR] for the selection of the best fitted application composition, the downloading and the installation of the needed application components. For the automatic application composition on each device, we use the OSGi Declarative Service (DS) service [ds].

4 dEVOLVe

Figure 4 presents an overview of the middleware requirements identiﬁed in section 2. For each requirement, the middleware components used to meet the requirement are marked with a rectangle. As mentioned in the previous section, a large part of the required functionality is covered by existing OSGi technology. However, middleware support is missing for: remote dependencies, group discovery, distributed automatic application composition, and environment evolution.

Proc. Software Evolution 2007 6 / 11 ECEASST

Figure 4: overview of the functionality offered by the middleware platform components

We are currently working on a OSGi component, called dEVOLVe, which contains the missing middleware support. In this section, we describe how dEVOLVe realizes the needed functionality. Figure 5 gives an overview of our middleware platform for software maintenance in distributed evolving environments. Both the dEVOLVe, OBR, DS and application components run on top of the OSGi base framework. OSGi allows direct access to both the JVM and the OS.

Figure 5: Middleware platform for software maintenance in distributed evolving environments

4.1 Remote dependencies The OSGi service platform has support for the description and wiring of service, package and bundle1 dependencies within a single VM. However, dependencies with remote devices are not supported. Therefore, we added a remote service, package and bundle dependency header (Figure 6) to the component manifest ﬁle as remote variants on the existing OSGi dependency headers. The ’group’ argument of those manifest headers will be discussed in the next subsection.

Figure 6: Remote dependency manifest headers

1 Components are called bundles in the OSGi community.

7 / 11 Volume X (2007) dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

The dEVOLVe component parses the manifest ﬁles of the used application components and tries to resolve their remote dependencies. OBR [OBR] is used to deploy the needed application components on the remote devices.

4.2 Group discovery The devices in an evolving environment will change over time. Because of this, application developers can not describe the devices themselves in the remote dependencies. To deal with this problem, we introduce weak couplings with remote devices by adopting the role concept from the sensor network community [MLM+05]. The developers can describe dependencies with groups of remote devices fulﬁlling certain roles. They do not need to know which devices will fulﬁll these roles, and devices can be added and removed at runtime to each role. The assignment of roles to the devices is considered a task of the local network manager who may choose to automate this task with a role assignment algorithm [FR05].

4.3 Distributed automatic application composition Automatic wiring is not possible with remote package and bundle dependencies. Remote service dependencies can be wired automatically with DS when the remote services are registered as local services. To realize this, dEVOLVe generates a proxy object for each remote service and registers it as a local service. This is similar to the approach of R-OSGi [RA07] to make remote services accessible. A simple remote method invocation mechanism is used to handle the remote service calls.

4.4 Environment evolution The middleware platform must be able to deal with changes in the execution environment. A very robust, but not necessary the best, technique to deal with changes in the execution environment is a periodical recomposition of the complete distributed application. We realize this with an application heartbeat: a periodic signal which starts from the application-root component and travels through the complete distributed application by following the service bindings between the application components. On each device where this heartbeat passes by, we react on this signal by checking if the current application composition is still the optimal one to satisfy the service requirements. When a better ﬁtted application composition is discovered, the application will be adapted. Some installed application components may no longer be used after an application recomposition. For instance, because a new component has been installed to deliver the required service, or because a broken network connection is making it impossible to deliver the remote service. In case of local service dependencies, DS will be able to react by stopping the currently unused components. However, this is not possible for the remote service dependencies. The heartbeat signal, which travels periodically through the complete distributed application, allows us to identify the components which are no longer part of the current application composition. Those components will no longer receive the heartbeat signal and can be removed or deactivated since they are no longer useful in the application.

Proc. Software Evolution 2007 8 / 11 ECEASST

5 Related work

Existing, state-of-the-art middlewares are able to adapt software towards its changing distributed environment. However, they all have limitations, making them less ﬁtted for software maintenance in distributed evolving environments.

5.1 Impala Impala [LM03] is a middleware platform for distributed sensor networks, able to adapt the distributed application on-the-ﬂy towards the evolving execution environment. Impala determines on each device some properties of the local execution environment such as the battery level and number of direct neighbors. The user is able to describe switching rules which determine how the application has to be adapted when the environment properties change. Impala is also able to check the peripheral requirements of the application software. This avoids the execution of application software with unmet hardware dependencies. However, Impala only supports monolithic applications. This makes it impossible to adapt parts of the application. Further, Impala does not support the assignment of roles to devices. Therefore, only distributed applications which require the execution of the same task on each device are supported. Impala also is not able to check remote dependencies. Because of this, all application software on the network must offer and require the same remote services.

5.2 TinyCubus The TinyCubus [MLM+05] middleware supports component based application architectures with service dependencies between the application components. It is able to detect changes in the environment, to selects the best ﬁtted application components and to wire them together. The selection of the application components is done based on 1) the device environment (e.g. network density), 2) the application requirements (e.g. reliability requirements), and 3) the optimization parameters (e.g. minimal resource usage). However, TinyCubus does not allow to describe remote dependencies. This makes it difﬁ- cult to guarantee cooperation between the application software running on the different devices. Further, TinyCubus is only able to select components installed on the device. The automatic deployment of components on the devices is currently an un-solved problem. TinyCubus also is not able to rewire service dependencies at-runtime.

5.3 Gridkit Gridkit [GCB+06] is a middleware framework able to adapt itself to changes in the environment. A component based architecture with service bindings is used to allow dynamic adaptation. In contrast to the previously discussed middlewares, Gridkit uses a centralized approach. A con- ﬁgurator collects information about the composition of the complete distributed framework and receives events about changing environmental conditions. With this information, the conﬁgu- rator determines when and how to change the framework by inserting, deleting, disconnection, connecting and replacing middleware components on the different devices. However, although

9 / 11 Volume X (2007) dEVOLVe: Middleware Support for software maintenance in Distributed, EVOLVing Environments

Gridkit is able to adapt the middleware support towards the applications, it is not able to adapt the distributed applications themselves.

6 Conclusion and future work

In this paper, we have identiﬁed the middleware requirements for software maintenance in distributed evolving environments. We illustrated this with a use case of an advertisement application for public transportation. We have demonstrated how existing OSGi technology can be used to realize an important part of the middleware requirements. We have presented an OSGi based middleware platform, called dEVOLVe, which adds the missing middleware support for: Remote dependencies: Remote service, package and bundle dependencies can be described and are automatically resolved. Group discovery: Application developers can describe remote dependencies with an unknown group of devices fulﬁlling a certain role. Distributed automatic application composition: Remote services are made available as local services to allow automatic wiring of service dependencies. Environment evolution: Changes in the distributed execution environment are detected by the middleware and the application is adapted accordingly.

Application developers who are familiar with OSGi and DS can start writing applications for dEVOLVe without much additional effort. They only have to learn to use three new manifest headers for the description of remote dependencies. dEVOLVe does not require the implementation of additional methods, or the inheritance of dEVOLVe classes. Even existing OSGi components can be used without any adaptation. dEVOLVe is work in progress. In the near future, we want to add some optimizations to allow dEVOLVe to react faster to changes in the environment. We also are going to evaluate the proposed solutions and enhance them where possible. Further, we want to investigate how dEVOLVe can be extended to support life cycle management (including software evolution) in distributed evolving environments. Our current middleware platform already contains some life cycle management support; the OSGi service platform has support for software life cycle management on a single device, and dEVOLVe extends this life cycle management support to distributed applications. However, we believe that the current life cycle management support for distributed applications is too difﬁcult to use. Research of additional middleware support is required.

Acknowledgements: The authors like to thank Sam Michiels for valuable comments and stimulating discussions. This work is part of the SPAMM project, funded by the IBBT (Interdis- ciplinary institute for BroadBand Technology).

Bibliography

[BC02] G. Bieber, J. Carpenter. Introduction to Service-Oriented Programming. 2002.

Proc. Software Evolution 2007 10 / 11 ECEASST

[del] De Lijn. http://www.delijn.be

[ds] Declarative Services, OSGI Service Platform Service Compendium, Release 4, OSGI Alliance.

[FR05] C. Frank, K. Romer.¨ Algorithms for generic role assignment in wireless sensor networks. In SenSys ’05: Proceedings of the 3rd international conference on Embed- ded networked sensor systems. Pp. 230–242. ACM Press, New York, NY, USA, 2005.

[GCB+06] P. Grace, G. Coulson, G. Blair, B. Porter, D. Hughes. Dynamic reconﬁguration in sensor middleware. In MidSens ’06: Proceedings of the international workshop on Middleware for sensor networks. Pp. 1–6. ACM Press, New York, NY, USA, 2006.

[IBB] The IBBT-SPAMM project: Solutions Platform for Advanced Mobile Mesh. https://projects.ibbt.be/spamm/

[KBY+06] J. King, R. Bose, H.-I. Yang, S. Pickles, A. Helal. Atlas: A Service-Oriented Sensor Platform. In SenseApp ’06: Proceedings of the ﬁrst IEEE International Workshop on Practical Issues in Building Sensor Network Applications. November 2006.

[LM03] T. Liu, M. Martonosi. Impala: a middleware system for managing autonomic, parallel sensor systems. In PPoPP ’03: Proceedings of the ninth ACM SIGPLAN symposium on Principles and practice of parallel programming. Pp. 107–118. ACM Press, New York, NY, USA, 2003.

[MLM+05] P. J. Marron,´ A. Lachenmann, D. Minder, J. Hahner,¨ R. Sauter, K. Rothermel. TinyCubus: A Flexible and Adaptive Framework for Sensor Networks. In EWSN ’05: Proceedings of the Second European Workshop on Wireless Sensor Networks. Pp. 278–289. January 2005.

[OBR] OSGI Alliance RFC-0112, OSGI Bundle Repository, http://www2.osgi.org/div/rfc- 0112 BundleRepository.pdf.

[osg] Open Services Gateway Initiative. http://www.osgi.org

[RA07] Services Everywhere: OSGi in Distributed Environments. 2007.

[RHKB05] J. Russo, A. Helal, J. King, R. Bose. Self-describing sensor networks using a surro- gate architecture. Technical report, University of Florida, June 2005. http://www.harris.cise.uﬂ.edu/projects/publications/Sensor-platform-paper2.pdf

11 / 11 Volume X (2007) Tool Demonstrations

2007

ECEASST

Maintaining Design Regularities in Evolving Software Systems using Template Queries in IntensiVE

- demo proposal -

Johan Brichau, Kim Mens Université catholique de Louvain

Coen De Roover, Andy Kellens Vrije Universiteit Brussel

1 Abstract Design regularities are an apparent aspect of today’s software implementations. Coding conventions, design patterns, programming idioms and architectural designs are only some examples of design regularities that govern the development of large and complex software systems. Maintaining these regularities in the source code of an evolving software system requires adequate documentation that is continuously monitored and verified for consistency with the source code. Intensional views, and their supporting tool-suite IntensiVE, permit to document and verify these regularities by means of program queries that group source code entities into views, and that impose constraints over these views. By checking the validity of the views and constraints with respect to the source-code, the tool-suite provides fine-grained feedback concerning inconsistencies between the documentation and the source code.

Program queries are the heart of the IntensiVE tool-suite. Although such queries can be specified using a variety of different programming languages, the logic program query language SOUL provides developers with an expressive and declarative means to express patterns and idioms of interest. However, it can be observed that the accurate specification of such a program query can often become complex. At the core of this problem lies the observation that developers specify views based on a concrete set of source-code entities they wish to document in the system. In other words, software developers tend to understand these views not directly through its specification but through its extension, containing tangible source code entities. This dichotomy requires that developers convey their example-driven knowledge into operational queries to effectively describe a view. This is often further complicated with the fact that the specification of the view may need diverse structural and behavioral representations of the program.

To reconcile the example-driven knowledge of developers with the expressive power of program queries, SOUL was recently extended with ‘template queries’. Such queries are actual concrete source code templates, embedded in the logic query

2 / 4 Volume X (2007)

Short Article Title language. These templates describe intensional views merely through a specification of a prototypical example implementation of the regularity to search for. Furthermore, the query resolution strategy employs an automatic translation of the template to queries that act upon diverse structural and behavioral representations of the program. In particular, these queries are matched against a combination of call-graphs, points-to analysis results and abstract syntax trees.

2 Intensional Views Intensional Views is a technique for describing a conceptual model of a program’s design regularities and verifying consistency of that model with respect to the program. Views describe concepts of interest to a programmer by grouping program entities (classes, methods, . . . ) that share some structural property. These sets of program entities are specified intensionally, using the logic metaprogramming language Soul. (The intension — with an ‘s’ — of a set is its description or defining properties, i.e., what is true about the members of the set. The extension of a set is its members or contents.)

For example, to model the concept of “all getter methods” in a specific implementation, we specify an intensional view using the following query that groups all methods that contain a statement returning an instance variable: getterMethod(?class, ?method, ?field) if isMethodInClass(?method, ?class), fieldInClassChain(?field, ?class), fieldName(?field, ?fname), methodStatements(?method, ?slist), ?slist =

Without explaining all details of the Soul syntax and semantics, upon evaluation the above query accumulates all solutions for the logic variables ?class, ?method and ?field, such that ?method is a method implemented in class ?class and contains a return statement returning the field ?field. This query is the intension of the view.

3 Template Queries Although the query shown in the previous section is relatively small and merely employs a single structural representation of the program, it already illustrates how easily such queries can become very complex. To cope with this burden, SOUL has been extended with the concept of template queries. Using this new technique, we can express the “getter methods” view as follows:

Proc. Software Evolution 2007 3 / 4

ECEASST jtClassDeclaration(?c){ class ?c { private ?type ?field; public ?type ?name() { return ?field; } } }

This query shows a template of a class declaration containing a field and method declaration. The method’s body contains a single statement returning the field. Upon evaluation, the logic variables in the template are bound to actual values identifying the method we are searching for.

The most interesting part of these template queries is that their evaluation does not merely perform a structural matching over a structural representation of the program. Instead, it performs a behavioural matching over semantic representations of the program, including call-graphs and points-to sets that are derived using static analysis techniques. This ultimately means that template queries can detect many implementation variants of the same pattern that is expressed in the template. In other words, the template behaves as an example and prototypical implementation of a pattern and the matching process looks for similar patterns in the code, using logic inference as the main resolution strategy. The above template will, for example, detect all instances of the getter method regularity below: public Integer gethour() public Integer gethourlazy() { public Integer getBuffer() { if(hour==null) { return hour; hour = this.currentHour(); Integer temp; } return this.hour; temp = buffer; } buffer = null; return temp; }

4 Demo Description In this demonstration, we will show how to employ the IntensiVE tool-suite to document design regularities in a Java program by means of views and constraints. We will demonstrate and contrast program queries in traditional Soul and by means of template queries. We will subsequently evolve the documented program and illustrate how the combined power of IntensiVE and template queries allows to maintain design regularities in the source code of the evolving program.

4 / 4 Volume X (2007)

ECEASST

FDdoc: Software Evolution Support Through Feature Model Based Documentation

Ilja Heitlager, Joost Visser

Software Improvement Group

Abstract: As software systems evolve, the need for tools to support the impact analysis process for software evolution increase. We present a tool based on feature modelling as general software documentation to support the evolution process. Feature modelling has found wide application in the elicitation of variation in software with the emphasis on reuse. An extension of the technique, which we call attributed feature modelling, to an overall documentation tool is described. We explain the functionality of the tool.

Keywords: Feature Modelling, Software Evolution

1 Introduction One of the challenges in software evolution is to keep track of the location of functionality in the source code. Features are not always easily traceable to one distinct spot in the source code, which makes it difficult to predict the impact of changes. The success of changes depends on the mental map developers have of the code, which becomes increasingly problematic with the growth of the system. A second challenge arises from the addition of new developers or software immigrants [1]. For newcomers to become productive they require to build their own mental map of the software. Documentation may help to find one’s way in the system. Documentation techniques range from high level design artefacts like UML models to source code documentation generated by tools like DocGen or javadoc [2][3]. The first category often evolves out of sync with the actual source code. The second category is limited to providing documentation at the solution level only. We have developed a documentation technique with the following characteristics: • provide a problem level view of the system and the source code • traceability between code and documentation artefacts • non-intrusive in the day to day operations of software engineers • generic for different source languages, and documentation artefacts Our technique is an extension to feature modelling [4]. Feature modelling has found wide spread use in the analysis of variability in software systems, particularly for software product lines [5][6]. As observed by Riebisch et al., feature modelling can be seen as an intermediary step between requirements, high level design artefacts and source code, where requirements relate to source through features in an m-to-n relationship [7] Starting from this observation, we have taken feature modelling one step further and created a generic HTML-based documentation tool that connects software and higher level design artefacts. Our tool provides a simple language for the definition of feature models [8] and adds a facility to attribute the features. Those attributes include descriptions, dates and version numbers. Most importantly the attributes of the features provide hyperlinks to source

2 / 5 Volume X (2007)

Short Article Title code, analysis and design documents, as well as other systems used in the software process like issue trackers, see Figure 1. The tool provides a problem-level index into all relevant artefacts created and maintained in the software process. The feature model is maintained together with the source code and thus constitutes a simple and lightweight documentation artefact which can easily be kept in sync with the source code. FDdoc supports coupled evolution of source code and high-level documentation. It provides a simple and effective way for software immigrants to acquire a mental map of the system, and for maintainers to perform change impact analysis.

2 Tool functionality

Figure 1, FDdoc is html based and generated from a FDL script. It links features with source, source documentation and other development tools and artefacts.

FDdoc is a command line tool used standalone or as part of a build system. The tool takes a feature model as input and generated HTML pages, one per feature. The input language is based on the Feature Description Language (FDL) of van Deursen et al. [8], but extended with attributes. Each generated feature page contains the description of the feature and a sub diagram of the connections to its nearest neighbours. The page further contains some attributes like date of introduction, version, status of the code (e.g. experimental) and links to the source and other design documents if available. Indexes are generated over each attribute for easy reference of the model. The FDL language distinguishes terminal and non-terminal features. Non-terminal features can be decomposed into sub features, using various construction operators, including

Proc. Software Evolution 2007 3 / 5

ECEASST all, one-of, and more-of. Features can require other features (requires) or can exclude other features (excluded-by). Abstract features, whose actual implementation is done by some solution level feature are denoted by the implemented-by operator. We extended the FDL language such that each feature (both terminal and non-terminal) can have multiple references to documents and to source code using the .doc and .source attributes. In addition, each feature can have attributes such as a description, rationale (why this feature exists), since_version (since which version does this feature exist), customer customer (if this system is used in a multiple customer environment), and since_date (date of introduction).. As stated, a feature can reference many sources, but also a source can be connected to many features, it is a many to many connection. The many-to-many connectivity allows feature delocalization. The mapping of the source can be applied in two forms: 1. Direct in the source model using an attribute. 2. Using an external map. The feature model is maintained in the model file, but an external feature to source map is maintained separately. The tool merges these two files and generates a simple overview. This technique originates from the Reflexion approach of Murpy [9]. The external map technique also allows for traceability using source annotation. Again the feature model is maintained separately. In a preliminary run the source is scanned and stripped from source to feature links. After merging, the system generates one overview.

3 Tool implementation

Figure 2, FDdoc tool architecture. FDdoc has been implemented in Python. The core of the system is a directed graph library. Feature modelling has been implemented as an extension of the directed graph by defining the specific vertex and edge types. Various forms of output exist: XML based, FDL language, HTML and graphviz dot, which are implemented by means of visitors on top of the feature model graph. The language is implemented using the pyparsing LL parser library. Metrics and indices are implemented directly over the graphs. For graphical output the graphviz tool is used.

4 / 5 Volume X (2007)

Short Article Title

Availability The tool is proprietary technology, however can be made available for evaluation. Interested readers are invited to contact the authors.

Acknowledgements We thank Remko Helms of the University of Utrecht, Machiel van der Bijl and Menno Jonkers of Axini for the fruitful discussions during construction of the prototype. We thank Yohyon van Zantwijk of VivaCadena for providing the environment to test the tool in practise. References [1] S.E. Sim and R.C. Holt, “The ramp-up problem in software projects: A case study of how software immigrants naturalize”, 20th Int. Conf. on Software Engineering; ICSE, pp. 361-370, 1997. [2] M. Fowler and K.Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Addison-Wesley Professional, 2003. [3] A. van Deursen, T. Kuipers, L.M.F. Moonen, Legacy to the Extreme, Center for Mathematics and Computer Science (CWI), SEN-R0018, 2000. [4] K. Kang e.a., Feature-Oriented Domain Analysis (FODA) Feasibility Study. SEI, Carnegie-Mellon University, Pittsburgh, PA, CMU/SEI-90-TR-21, 1990. [5] K. Czarnecki e.a., “Staged configuration through specialization and multi-level configuration of feature models“, Software Process Improvement and Practice, vol. 10, no. 2, pp. 143-169, 2005. [6] K.Czarnecki e.a. “fmp and fmp2rsm: eclipse plug-ins for modeling features using model templates”, Conference on Object Oriented Programming Systems Languages and Applications, ACM Press New York, NY, USA, pp 200-201, 2005. [7] M.Riebisch, “Supporting evolutionary development by feature models and traceability links”, , 2004. Proc. of the 11th IEEE Int. Conf. and Workshop on the Engineering of Computer-Based Systems , pp. 370-377, 2004. [8] A. van Deursen and P.Klint, “Domain-Specific Language Design Requires Feature Descriptions”, Journal of Computing and Information Technology, vol 10. No. 1, pp. 1-17, 2002. [9] G.C. Murphy e.a. “Software reflexion models: bridging the gap between source and high- level models“, Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software engineering, ACM Press New York, NY, USA, pp 18-28, 1995.

Proc. Software Evolution 2007 5 / 5