Identification Of Variation Points Using Dynamic Analysis Bas Cornelissen Bas Graaf Leon Moonen Delft University of Technology Delft University of Technology Delft University of Technology and CWI The Netherlands The Netherlands The Netherlands s.g.m.cornelissen@ewi.tudelft.nl b.s.graaf@ewi.tudelft.nl Leon.Moonen@computer.org Abstract In this position paper we investigate the use of dynamic analysis to determine commonalities and variation points as a first step to the migration of similar but separate ver- sions of a software system into an integrated product line. The approach detects forks and merges in different execu- tion traces as an indication of variation points. It is illus- trated by a simple implementation, which is applied to an academic example. Finally we formulate a number of re- search issues that need to be investigated further. 1. Introduction Already many successes have been reported with respect to the use of product line approaches in software develop- ment organizations [1]. A company that migrates to a prod- uct line approach must define a product line architecture that incorporates the design decisions common to all prod- uct line members. Additionally, the variability between the different product line members is to be made as explicit as possible. In practice, the idea of following a product line approach can be applied in various levels of detail. For example, one can define a reference architecture which specifies all com- monalities between products but does not make the varia- tion points explicit. As such, we can distinguish between various maturity levels in a product line deployment [2]. This is also illustrated in an industrial example discussed by Graaf et al. [3]. A typical situation in which the adoption of more prod- uct line concepts, and thereby raising the maturity level, is beneficial, is when a company has developed several ver- sions of a product for different customers. All these ver- sions are extended in one or more ways with respect to some original system that was initially developed. At some point a customer comes along that requires some of the extensions that were already implemented, but for differ- ent versions of the product, and thus their implementations reside in different development branches. As more ver- sions are being developed, such a situation becomes more and more likely. At that point these extensions should be reengineered into clearly defined, configurable features by making variation points explicit, ideally enabling late bind- ing. Domain and application engineering methods have been proposed to solve this problem. Typically these approaches are applied in a context where a product line is developed from scratch, and do not take existing source code into ac- count. However, new product lines are typically not de- veloped from scratch, but evolve from a set of similar, tra- ditionally developed products. Furthermore, often many design decisions are only explicit in the source code. In this paper we consider the problem of detecting forks and merges in the execution traces generated by different versions of a system so as to identify its variation points. The remainder of this paper is organized as follows. Section 2 discusses some related work. In Section 3 the basic idea of how execution traces can help in identifying variation points is presented. Section 4 explains a simple implementation of this idea that detects forks and merges in execution traces. This implementation is applied to a simple example in Section 5. The paper is concluded with some discussions and directions for future work in Sec- tion 6. 2. Related Work Van Gurp et al. [4] provide an excellent introduction to the concepts of variability in software product lines and discuss how variability can be documented using feature graphs. However, they do not discuss in much detail how commonalities and variation points can be discovered. Approaches for domain engineering aim at identifying commonalities and variabilities for the definition of prod- uct line architectures. Scope, variability, and common- ality (SCV) analysis discussed by Coplien et al. [5] pro- vides a systematic way of thinking about commonality and variability. The same work also introduces FAST, an ap- proach for domain engineering based on SCV-thinking. Other domain engineering approaches are FODA [6] and