Refactoring Product Line Architectures Matt Critchlow, Kevin Dodd, Jessica Chou, and André van der Hoek Department of Informatics School of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425 USA {critchlm,kdodd,jychou,andre}@ics.uci.edu Abstract In this position paper we explore the application of re- factoring to product line architectures (PLAs). A PLA is a common architecture for a set of closely related products. As the set of products and their features changes, the PLA must evolve as well. A typical problem in managing such evolution is that the overall structure of the PLA slowly but surely degrades. This is caused by the fact that a set of individual, localized changes does not necessarily re- sult in the best structure for the overall PLA. We discuss our ongoing research in addressing this problem. In par- ticular, we present our metrics for diagnosing structural problems in a PLA, and introduce our set of architectural refactorings that can be used to resolve those problems— thereby improving the overall structure of the PLA. 1. Introduction Refactoring has established itself as an effective tech- nique for improving the structure of source code [4]. Its use, however, can be beneficial in other domains as well. In this paper, we explore and demonstrate the benefits of refactoring in one such domain: product line architectures. A product line architecture (PLA) specifies the archi- tecture for a set of closely related software products [1,2] in terms of components (responsible for all computational aspects), connectors (providing all communication among components), and configurations (specifying the particular topologies of individual products) [6]. The use of PLAs has been on the rise in the past few years [3,7,9,10], which can be attributed to their ability to promote reuse—not just of the individual components and connectors, but also of the overall architectures themselves. As such, a PLA is a critical asset to an organization, and its quality must be maintained over time. Unfortunately, doing so is difficult. A PLA is fluid, and must constantly be updated when new products are intro- duced, old products are retired, and existing products are modified. Of particular interest to this paper are the modi- fications that change the variation points of a PLA. Com- plementing the core components and connectors (i.e., the components and connectors that are present in all configu- rations of the PLA), variation points designate the compo- nents and connectors in the PLA along which individual configurations differ. These variation points are specified as either optional elements (i.e., components and connec- tors that may or may not be present in a particular con- figuration) or variant elements (i.e., components and con- nectors that always are present, but are selected to be one of multiple alternatives). Not surprisingly, a PLA can have many variation points. Isolated changes to one or more of these variation points may have structural implications for the remainder of a PLA. In fact, anecdotal evidence sug- gests that the combined result of multiple changes virtu- ally always leads to structural degradations in the PLA, irrespective of how well-defined the PLA was at its incep- tion. In this position paper, we present initial results of our research that is specifically aimed at addressing this prob- lem. In particular, we leverage the service utilization met- rics defined in our previous work [8] in building two new tools: ARCHMETRIC, which automatically calculates and presents the service utilization metrics as applied to a par- ticular PLA, and ARCHREFACTOR, which provides support for refactoring a PLA in response to problems identified by the metrics. Below, we first introduce an example PLA that we use throughout the remainder of the paper. We then briefly reiterate our metrics, introduce the two new tools, and conclude with an outlook at the work that re- mains to be done. 2. An Example PLA Figure 1 introduces an example PLA consisting of four components (for brevity, we omit any connectors from the ensuing discussion; they would be treated in similar fash-