SPL Profile
4. Consolidation Process
4.2. Process Activities
Accepted?
Variability Realization Decision SPL Profile
Definition
Process Configuration
Difference Analysis
Relationship Analysis
Variation Point Structure Design
Variation Point Characteristic Definition
Design Review
Consolidation Refactoring
SPL Export YES NO
VPM SPL
Profile
Confi-guration VPM
Recommen-dations
VPM
VPM SPL
VPM
SPL Management Tool Input
Figure 4.2.:Consolidation process activities with artifacts produced or modified
Next, the Variation Point Structure Design produces a VPM with an accepted Variation Point (VP) structure, which is further enhanced by the Variation Figure 4.2 provides an overview on the activities and the artifacts they either produce or update. The first two activities define the SPL Profile and the configuration for the overall consolidation process. The Difference Analysis produces the initial Variation Point Model (VPM). Afterwards, the Relationship Analysis produces recommendations for design improvements.
Point Characteristic Definition, deciding about the individual variability characteristics of the VPs. If the design represented in the VPM is accepted in the Design Review, the Variability Realization Decision further enhances
4.2. Process Activities
4.2.1. SPL Profile Definition ACTIVITY SPL Profile Definition
GOAL Defining guidelines for variability design and realization of future SPLs
ROLE Software Architect
INPUT /
OUTPUT SPL Profile
ACTIONS Configure or select SPL Profile SPLEVO
Support
Automated SPL Profile recommendations and validation (Section 3.3)
During the SPL Profile Definition activity at the beginning of the process, the Software Architect defines the guidelines how to implement the SPL.
Such guidelines might be reused between several consolidations within the same company or project. This initial preparing activity does not need any input. The output will be the configured SPL Profile to be used in the downstream consolidation according to the SPL Profile data model described in Section 3.3. The activity is supported in the SPLEVOapproach with an automation to recommend and validate settings of the SPL Profile as described in Section 3.3.
4.2.2. Process Configuration
In the Process Configuration activity, SPL Consolidation Developers provide configurations for the concrete copies to consolidate. On one side, the source projects to analyze are configured. On the other side, available expert knowledge about the copies, such as renaming conventions applied during customization, are captured in the configuration. The latter covers information to improve the downstream consolidation, such as restricting the VPM by assigning variability mechanisms to the VPs matching their variability characteristics and software elements. Finally, the Consolidation Refactoring produces the resulting SPL and a VPM describing the VPs of this SPL.
ACTIVITY Process Configuration
GOAL Consolidation-specific process configuration ROLE SPL Consolidation Developer
INPUT /
OUTPUT Process Configuration
ACTIONS Define copies to consolidate and capture export know-ledge
SPLEVO
Support
Configuration wizard as part of the prototype (Sec-tion 8.3)
4.2.3. Difference Analysis
ACTIVITY Difference Analysis
GOAL Detecting differences between product copies ROLE SPL Consolidation Developer
INPUT Copy implementations, process configuration, and SPL Profile
OUTPUT Fine-grained VPM initialized from differences ACTIONS Trigger automatic process
SPLEVO
Support
SPLEVODifference Analysis (Section 5)
the copies’ parts to consider or providing company-specific practices for copy-based customizations. Which expert knowledge can be considered, is described in detail in the appropriate sections (i.e., Sections 5, 6, and 7).
Similar to the first preparing activity, the Process Configuration does not expect any input and provides the configuration itself as output. To improve the configuration activity, the prototype implementation of the SPLEVO
approach provides a wizard to guide SPL Consolidation Developers as described in Section 8.3.
4.2. Process Activities
In the Difference Analysis activity, SPL Consolidation Developers identify the differences between the copies to consolidate. The result of the activity is a fine-grained VPM with each VP identifying a separate difference between the copies. To enable the VPM initialization, differences must identify changed software elements. As part of the Difference Analysis activity, the expert knowledge captured during the Process Configuration activity is used to improve the difference analysis. For example, naming conventions are used to better match software elements or reduce the amount of differences to be processed later on. Furthermore, each VP is initialized with the variability characteristics required by the SPL Type selected in the SPL Profile. The SPLEVOapproach provides a consolidation-specific difference analysis to fully automate this activity as described in Section 5.
4.2.4. Relationship Analysis
ACTIVITY Relationship Analysis
GOAL Identify VP relationships and reasonable aggregations ROLE SPL Consolidation Developer
INPUT SPL Profile and process configuration OUTPUT Refinement recommendations ACTIONS Choose and start the analysis SPLEVO
Support
SPLEVOVariability Analysis (Section 6)
During the Relationship Analysis activity, the SPL Consolidation Developers analyze the VPs in the current VPM to enable educated decisions on refining the VPs’ structure as part of the variability design. The activity’s output is a list of sets of related VPs representing candidates for being aggregated. While today developers analyze those relationships manually in an ad hoc manner and with a limited scope, one of the main contributions of the SPLEVO
approach is to automate them and allow to consider further relationship types across complete implementations. SPL Consolidation Developers start such an automated analysis to receive the aggregation candidates. Details about the analysis are documented in Section 6.
4.2.5. Variation Point Structure Design
ACTIVITY Variation Point Structure Design GOAL Shape variability coverage and localization ROLE SPL Consolidation Developer
INPUT VPM and VPM refinement recommendations
OUTPUT Refined VPM
ACTIONS Review recommendations and apply appropriate ones SPLEVO
Support
UI facilities in the prototype (Section 8.3)
In the Variation Point Structure Design activity, the SPL Consolidation De-velopers refine the VPM until all VPs contributing to the same feature from a technical perspective are connected to each other. To do this, they refine the current VPM by reviewing the candidates provided by the relationship analysis or manually editing the VPM. If they are satisfied with the VPM structure, they can continue with the Variation Point Characteristic Defini-tion. Otherwise, they can choose to perform another relationship analysis to receive further recommendations. To support the SPL Consolidation De-velopers in this activity, the User Interface (UI) provided with the SPLEVO
prototype allows for according tasks (Section 8.3).
4.2.6. Variation Point Characteristic Definition ACTIVITY Variation Point Characteristic Definition GOAL Define intended variability properties ROLE SPL Consolidation Developer
INPUT VPM with approved VP characteristics
OUTPUT VPM representing a technically satisfying design ACTIONS Change default characteristics where appropriate SPLEVO
Support
VP initializing & UI facilities in the prototype (Sec-tion 8.3)
At this point of the process, a variation point structure has been designed, rep-resenting an appropriate degree of variability for the future SPL by grouped
4.2. Process Activities
and merged VPs. During the Difference Analysis, each VP was initialized with the default variability characteristics derived from the SPL Profile. In the Variation Point Characteristic Definition activity, the SPL Consolidation Developers adapt them according to their technical requirements (e.g., when to choose a variant of a variation point). VPs located in and realized by the same type of software elements can be realized with different variability characteristics (e.g., being extensible for product-specific variants). This is a matter of individual variation point design and cannot be automated. The result of the activity is a VPM representing a variability design which is sat-isfying from the technical perspective of the SPL Consolidation Developers.
While this activity is about manual decisions only, the user interface of the SPLEVOapproach’s prototype provides utilities for accessing and configur-ing the VPs (Section 8.3).
4.2.7. Design Review
ACTIVITY Design Review
GOAL Considering product management perspective in the SPL design
ROLE SPL Manager
INPUT VPM representing a technically satisfying design OUTPUT Required VPM adaptations
ACTIONS Identify VPs to be restructured or reconfigured SPLEVO
Support
UI facilities in the prototype (Section 8.3)
During the Design Review activity, SPL Managers prove the variability design represented in the current VPM for possible improvements from a product management perspective. For example, the flexibility to de-rive products from the future SPL might be adapted to individual product strategies by requiring another binding time for variation points. The output of the activity are required adaptations of the VPM. If the VPM is accepted as it is, the process can continue with the Consolidation Refactoring phase.
If possible improvements, such as further aggregating variation points, were found, the required adaptations are communicated to the SPL Consolida-tion Developers. In this case, the process goes back to the VariaConsolida-tion Point
Structure Design activity, as SPL Consolidation Developers must decide if restructurings are necessary or defining other characteristics is sufficient.
The review activity is performed manually and guided by utilities in the UI of the SPLEVOprototype implementation (Section 8.3).
4.2.8. Variability Realization Decision
ACTIVITY Variability Realization Decision GOAL Decide how to implement VPs ROLE SPL Consolidation Developer
INPUT VPM with approved VP design and SPL Profile OUTPUT VPM with assigned variability mechanisms ACTIONS Choose variability mechanism per VP SPLEVO
Support
Variability mechanism recommender engine (Sec-tion 7.2.1)
In the Variability Realization Decision activity, SPL Consolidation De-velopers must decide how to reflect each VP’s implementation in the future SPL (e.g., by conditional statements or dynamically loaded components).
This is done by assigning a variability mechanism to each of them. Based on the SPL Profile and the contained prioritized set of variability mechanisms, SPL Consolidation Developers can choose the highest ranked mechanism providing the characteristics defined for a specific VP. Due to the imple-mentation guidelines, no additional interaction with other stakeholders for each of the VPs is necessary, except for the need to add new variability mechanisms to support not yet covered combinations of characteristics. The output of the activity is a VPM with a variability mechanism for each VP and forming a valid input for the downstream refactoring. The SPLEVO
approach provides a variability mechanism recommender engine to support this task as described in Section 7.2.1.
4.2.9. Consolidation Refactoring
During the Consolidation Refactoring activity, each VP is refactored accord-ing to its assigned variability mechanism. The implementations of each VP’s
4.2. Process Activities
ACTIVITY Consolidation Refactoring
GOAL Change implementation to a single code base SPL ROLE SPL Consolidation Developer
INPUT VPM with assigned variability mechanisms
OUTPUT Consolidated code and/or manual task list and according VPM
ACTIONS Apply refactorings to implement variability mechanisms and merge code basis
SPLEVO
Support
Refactoring specification and extensible infrastructure for automation (Section 7.3)
variants and the code for the assigned variability mechanism are combined and implemented in the product copy chosen as the leading one. How the refactoring is performed depends on the variability-mechanism-specific re-factoring’s degree of automation as described in Section 7.3. Depending on the degree of automation, the result of the activity is either a ready to use single code base SPL, a list of refactoring tasks, or a mix of both. In addition, an evolved VPM with updated VPs referencing the changed code base is produced. Beside a refactoring specification concept, the SPLEVOapproach defines an extensible infrastructure to automate refactorings as described in Section 7.3.
4.2.10. SPL Export
ACTIVITY SPL Export
GOAL Provide input for tools to manage the future SPL ROLE SPL Consolidation Developer
INPUT VPM linked with refactored code base OUTPUT Input for SPL management tool
ACTIONS Trigger export to send information to SPL management tool
SPLEVO
Support
Export interface and implementation for standardized feature model
For a continuous management of the created SPL, SPL Consolidation De-velopers export the results to an SPL management tool in the SPL Export activity. Such an export includes the implementation of the SPL as well as a model of the variability referencing the according variation points. The SPLEVOapproach defines an interface for implementing automated exports based on the VPM representing the single code base SPL as described in Section 7.4.