SPL Profile
5. Difference Analysis
5.1. Specific Requirements of Copy Consolidation Scenarios
The following eight requirements have been derived from the overarching consolidation processes and industrial consolidation scenarios in the KoPL research project [107]. We do not claim for completeness, but elaborate on the value of each requirement to support SPL Consolidation Developers.
R1: Support Independent and Derived Copies Copy-based customiz-ation in object-oriented systems occurs in two manners: Independent and Derived Copies. Independent Copies are created by a pure “copy” action as illustrated forMyClassandMyClassCustomin Figure 5.2. Both classes have no dependency on each other and the copy can be modified fully independ-ently at the cost of losing the original relation between them. Derived Copies are created by a copy action and by introducing an inheritance relationship between the copy and the original class. In Figure 5.2, this is shown for
BaseClassandBaseClassCustom. Here,method1()was copied to the sub class and modified to override the super class’s behavior. In such a case, the difference analysis must not reportmethod2()as deleted in class
Base-ClassCustom, as it is still accessible. In a similar way, fields and imports must not be reported as deleted if they are still accessible, respectively not being required by the deriving class. Derived Copies are often used when some but not all methods of a class must be customized, but the class neither provides sufficient extension capabilities (e.g., hook methods to override) nor the code design allows for a reuse-by-delegation approach. Derived Copies are not limited to classes. They can occur for any type of container with some kind of “use” relationship to other containers of a compatible type.
For example, a component is copied and a “requires”-dependency is created from the copied to the existing one. The copied component is able to access everything published by the original one. Hence, the copied component must not duplicate published parts that need no modification.
+method1() +method2() MyClass +doSth()
MyClass
+doSth() MyClassCustom
+method1() +newMethod() MyClassCustom copy &
inherit copy
Independent Copy Derived Copy
Figure 5.2.:Copy-based customization procedures in object-oriented technologies
Definition 8 (Independent Copy) AnIndependent Copy is a copied soft-ware element without any relationship to its origin and, thus, any kind of modification might have been performed on it.
Definition 9 (Derived Copy) A Derived Copy is a copied software element for which the following rules apply:
1. It is of a type supporting inheritance relationships to other elements of the same type.
2. An inheritance relationship was introduced to the copy, referencing the original element.
3. The original software element is still present in or accessible by the copy and, thus, a renaming or namespace change was applied to the copy.
R2: Consider Copy Renaming Conventions Many developers use a common renaming during copy-based customization, either intuitively or according to their coding guidelines. Typical renaming is done by pre- or suffixing of named code elements (e.g., classes) with a customer or customiz-ation identifying term (e.g., the term “Custom” in Figure 5.2). In languages supporting namespaces, those namespaces may also be enhanced with cus-tomization fragments. For example, a Java packageorg.company.product
may be renamed toorg.company.customer.product. If a convention for such a structured renaming is available, this can be considered by the differ-ence analysis to improve the matching between original and copied artifacts.
5.1. Specific Requirements of Copy Consolidation Scenarios
However, this is not about an algorithmic detection of renaming because the overall goal of a fully automated difference analysis must not be missed due to invalid or unclear renaming detections.
R3: Support Intended Variability Mechanisms A broad range of mech-anisms exists to implement variability on different levels of software element granularity (e.g., statements, classes, components) in SPLs [168, 7, 146].
According to the individual requirements for the targeted SPL, a reasonable set of mechanisms should be defined to prevent divergent implementations of the same type of variability. This set also specifies the “minimum granu-larity level” variability should be implemented at, which also determines the minimum granularity level differences must be identified for. For example, allowing preprocessor annotations, variability can be implemented even within expressions, but using conditional program execution, the minimum granularity to implement variability are statements. The difference analysis needs to take the minimum granularity level of the intended variability mech-anisms into account. Otherwise, many fine-grained differences are reported where fewer coarse grain ones are sufficient.
R4: Allow for Configuration of Analysis Scope A consolidation of customized copies typically does not affect all components of a software system. For example, only some of the customizations are intended to become part of the SPL. All other parts and also third party code can be excluded from the difference analysis. Hence, the required processing and the information presented to SPL Consolidation Developers can be reduced.
If a scope is defined (e.g., Java packages to exclude), this should be used to optimize the difference analysis. If it is not, the analysis must still return a valid result.
R5: Analyze Independent Source Directories Customized copies are often developed by different developers and cannot be assumed to be main-tained in a common code base, repository, or with a coupled change history.
Thus, the difference analysis must be able to handle complete and independ-ent source directories without any existing mapping between the contained compilation units.
R6: Favor False Positives over False Negatives Due to the possibly large amount of differences, developers should not be confronted with more information than necessary. However, it is important to not miss any dif-ferences in order to provide them with reliable input for the downstream consolidation process. Otherwise, this could lead to wrong variability design decisions, which is inferior to confronting developers with irrelevant dif-ferences they have to ignore. Thus, in the context of a consolidation, false positive differences must be favored over false negative ones.
R7: Provide Binary Decision Similar to providing all relevant differ-ences, software elements should be clearly classified as changed or not. All software elements not identified as similar must be reviewed by developers anyway. That means, even if a software element would be classified as
“maybe changed”, developers have to investigate this element. Thus, the differentiation between “changed” and “potentially changed” does not help but leads to additional confusion and therefore is omitted.
R8: Support Heterogeneous Software Artifacts Modifications between customized code copies can be performed on all types of artifacts in addition to their source code. For example, component descriptors or configuration files can be adapted. To allow for a comprehensive difference analysis, extensibility for additional artifacts is necessary.