Then, the SCG corresponding to \(P_{1}\) only contains two clone relations, namely \((C_{1,1},C_{1,4})\) and \((C_{1,3},C_{1,5})\) which are indicated by dashed edges; the SCG corresponding to \(P_{2}\) only contains one clone relation, namely \((C_{2,1},C_{2,4})\) which is indicated by a solid edge. The SCG corresponding to \((P_{1},P_{2})\) would capture all the clone relations as shown in Figure 2 but _cannot_ distinguish the dashed edges from the solid edges, whereas the TCG representation distinguishes the two kinds of clone relations. As we will see, this distinction allows us to capture the evolution of clones associated with a sequence of versions of a program. Given the clone relations, it is straightforward to generate SCG and TCG, by simply following their definitions. Having obtained SCG and TCG, we can use them to formalize the intuitive notion of the clone landscape as follows. **Definition 4** (clone landscape). : _Given a set of programs \(P_{1},\ldots,P_{n}\), the clone landscape is defined as:_  
* _The_ SCG _that is derived from these programs when no temporal information about the programs is provided (i.e., the programs are for different applications/purposes or provided by different vendors)._
* _The_ TCG _that is derived from these programs when temporal information about the programs is provided (e.g., some or all of the programs are different versions of the programs)._  
Figure 2: Illustration of TCG of two versions of a program, denoted by \(P_{1}\) and \(P_{2}\). The boxes represent code fragments, the dashed edges represent the clone relations between code fragments in a single version of the program (i.e., \(P_{1}\) or \(P_{2}\)), and the solid edges represent the clone relations between code fragments in different versions of the program (i.e., between \(P_{1}\) and \(P_{2}\)). _In order to unify representation, we use the clone landscape to indicate either SCG or TCG, which should be clear from the context._  
In order to characterize clone landscapes and their evolution, we propose defining the following metrics to characterize the dynamic situation of clones via the landscape. Let \(|P_{i}|\) denote the number of LoCs of program \(P_{i}\). Recall that \(V_{T}^{(i)}\) is the set of code fragments belonging to program \(P_{i}\), including the code fragments that are cloned in \(P_{i}\) and the code fragments that are cloned in \(P_{j}\) where \(j\
eq i\). For a code fragment \(v\), let \(|v|\) denote its number of LoCs. * **Clone surface**: This metric measures the fraction of code in a program that is cloned, either from another program or by another program. Specifically, for a program \(P_{i}\), this metric describes the percentage of cloned LoCs in \(P_{i}\), namely \(\frac{\sum_{v\in V_{T}^{(i)}}|v|}{|P_{i}|}\). * **Clone prevalence**: This metric measures how prevalent clones are in a set of programs. Specifically, for a given code fragment \(C\), this metric is defined as the number of clones of \(C\) in programs \(P_{1},\ldots,P_{n}\). * **Clone lifetime**: This metric measures the lifecycle from a cloned code fragment. Suppose a given code fragment \(C\) appears in the given set of programs \(P_{1},\ldots,P_{2}\) at time \(t_{1}\) at the earliest and at time \(t_{2}\) at the latest. Then, the lifetime of \(C\) with respect to \(P_{1},\ldots,P_{n}\) is defined as \(t_{2}-t_{1}\). Note that the _clone lifetime_ metric is only applicable to TCG-based clone landscapes.