The paper declares a novel approach for the process enhancing of managing Variability - the ability of a software system or artefact in Software Product Line (PL) to be extended, changed, customized or configured for use in a specific context - with the proper quality characteristics to mitigate its current limitations. New Variability Model and Management Functions to process its element are proposed as this process Core. The model consistently represents variabilities both in PL structure and artefacts across all PL development stages and stakeholders' viewpoints along with the dedicated assessment submodel. The functions compose separate actions as to variability into the single cycle like Doeming Plan-Do-Check-Act one where decisions should be rational. Presented successful Case Study purposes at the Core proposed testing along with the dedicated Configurator implemented in instrumental and technological complex just developed in the Institute of Software Systems of NAS.
Effective and efficient large, complex and multi-purposed software systems
composition from more simple reusable assets was one of the challenges being
addressed in the research project named “Theoretical Fundament of Generative
Programming and Means of its Support”(2007-2011, № 0107U002205) [
But it was at once well-recognized that the key success factor in PL Engineering is
а proper management of both the two kinds of variability disambiguated by Metzger
et al. [
However, just now researchers’ efforts concentrate foremost on variability
modeling [
The paper pursues the same goal but for both the above kinds of variability. It proposes dedicated Variability model and Management Functions based on its estimates as the Core of an empirical approach for PL Variability Management process defining that is enhanced with appropriate quality characteristics. The Core is tested with the dedicated Configurator elaborated within the research project above. 2
Variability items to be managed. Let fix, to use hereafter, the definitions of basic
Variability items that have to be manage over PL development and therefore need to
be explicitly modeled, following up the origins [
The first such item is a variation point. It is an abstraction that identifies location in
software system or artifact at which a choice can be made between values or variants.
As Deelstra et al. [
A variant is thus the second Variability item answering the question, how does
vary the variation point it is associated with [
The third one is dependency [
Consistency means that Variability should be handled the same way at all above levels of abstraction and across all PL development phases to reduce the ambiguities that might occur when using different methods for managing variability at different abstraction levels. Scalability prescribes that the methods used should be easily applicable for both the single component and a large complex system. In turn, traceability requires that Variability items at different levels of abstraction and across development phases should be explicitly linked both upwards and downwards to simplify PL evolution and maintenance. Lastly, visibility presupposes understandable representations of all Variability items in appropriate and intellectual user interface. 3
An approach proposed is simply to define a Core of Enhanced (i.e. possessing the above target characteristics) Variability Management process, then continuously test it under various stressing conditions and refine accordingly to the lessons learnt.
The Core is formally a tetrad of a sets open for expanding
C AS; FN;ENV;DM ; ENV VM ;RP;VP;CP , (1) where AS denotes a priori assumptions as to PL development organizing; FN is the set of Generic Functions for PL Variability Management Process; ENV is the environment for FN operation including dedicated Variability Model ( VM ) described hereafter, PL core assets Repository ( RP ) and profiles both for PL variability with VM ( VP ) and for core assets reuse over PL development ( CP ); DM is the set of Demands the Functions should meet to enable the target quality characteristics be really attained.
Initially AS in (1) assumes PL development to be the series of unified production rounds interchanging with the rounds of PL environment actualization.
In the FN set, four target Variability Management functions are elicited as generic
through comparative study of popular Variability Management process templates
[
The DM set from (1) composes consistency, scalability, traceability and visibility demands being inspired the title target characteristics and also the additional demand of rationality for all decisions being made under the functions FN processing. To meet this demand is the main purpose of VM and both the above variability kinds assessment method with it that enables VP and, particularly, CP . 4
Let’s particularize the above target characteristics and demands DM from (1) to fix
inspired demands the dedicated VM should meet to pursue its purpose in (1):
─ uniform, consistent and traceable representation for all the variety of variability
items and their interrelations over all the stages both for PL Domain and
Application Engineering processes [
Relevant Variability Model is defined [
VM SV ; AV ;EV , where: submodels SV and AV represent variability in PL structure and its artifact; EV is an integrated submodel for informed and consistent variability assessment.
The first submodel SV in (2) gives the formal representations of all the features
from PL scope, both commonalities and variabilities, artifacts to implement them and
their links on the base of feature modeling approaches [
1 where: Gt Ft , LFt is the graph where unique identifiers of t-typed PL artefacts (i. e. features, requirements, architecture modules, database tables, software components and tests) are nodes sets ( Ft ) linked through obligatory and variant binding ( LFt ); TRt is bilateral traceability links between the nodes of Gt 1 and Gt graphs; CN and DP are the predicates on t 1,...,5 Ft representing PL constraints and dependencies.
In turn, the second submodel AV in (2) provides unified formal representations for all PL software products currently located in repository, being developed or might be developed eventually within current PL scope together with their development products (requirements etc.). To explicit reflecting the elements of SV (2) model in PL software products, any t -typed artefact is formally seen as cross-cutting “fragment” of SV . It is bounded with continuous upwards – downwards traceability links TRt from (3), which interrelates this artifact with the features it should implement and the final software product. The model AV is a structured tuple AV (idt ) g1; gu , tru ,u 2,..., t ; pu , tru ,u t 1,...,5 ;cn;dp;s , where: idt is the modeled artefact’s unique identifier; gu and pu are subgrafs of Gu from (3) representing the artefacts that are implemented with idt and, respectively, implement it over PL development; tru TRu are subsets of traceability links between the nodes of gu1 and g u ; cn and dp are the limitations of CN and DP on Cartesian product of gu ; and pu nodes sets and s is the artefact’s current state (e.g. “core asset” etc.).
Note that each of the five "horizontal" planes, implicitly defined with formulas (3), (4), reflects the viewpoints both at PL and artefact variability by specific PL Stakeholders group being represented over PL development with the proper-typed artifacts – from the customers’ features at the first level ( G1, g1 ) downwards to the programmers’ and testers software and tests at the fifth one ( G5 , g5 ).
The third submodel of SV model expands Metzger’s Orthogonal Variability
Model [
Here the probe implementation of PL artefact variability model AV (4) is considered
for simple domain of quadratic equations solving. While classical feature diagram [
Let’s explain how such variability might be visualized and on-line managed with that WWF diagram. Note that the letter A at the Fig. 1 connected with the “plus” pictograms denotes the variation points that might be filled with the reusable assets as their variants while the letter B denotes possible variants. In the case at hand the "Discriminant" component contains simple code to find discriminant ( Db b 4 a c ), implemented by the developer responsible for producing PL core assets. Depending on its operating outcome, there are three scenarios (use case): D 0; D0; D 0 and three corresponding assets for them: “TwoRoots”, “ExactlyOneRoot”, “NoRoots“.
When using WWF, Visual Studio environment don’t prohibit the developer from binding any reusable assets and variation points. In other words, we need a dedicated software tool that should support both the VM proposed (2)-(5) forming and actualizing and application configurations changing based on VM and reusable assets.
Trial prototype of such a tool, named Configurator, has been implemented within
instrumental and technological complex just developed in the Institute of Software
Systems of NAS [
<SequentialWorkflowActivity> <CodeActivity x:Name="Start" ExecuteCode="codeActivity1_ExecuteCode" /> <CodeActivity x:Name="Discriminant" ExecuteCode="codeActivity1_ExecuteCode_1" /> <IfElseActivity x:Name="ifElseActivity1"> <IfElseBranchActivity x:Name="D_more_0"> <IfElseBranchActivity.Condition>
<CodeCondition Condition="WorkMeth1" /> </IfElseBranchActivity.Condition> <CodeActivity x:Name="TwoRoots" ExecuteCode="codeActivity1_ExecuteCode_2" /> </IfElseBranchActivity> <IfElseBranchActivity x:Name="D_equal_0"> <IfElseBranchActivity.Condition>
<CodeCondition Condition="WorkMeth2" /> </IfElseBranchActivity.Condition> <CodeActivity x:Name="ExactlyOneRoot" ExecuteCode="codeActivity2_ExecuteCode" /> </IfElseBranchActivity> <IfElseBranchActivity x:Name="D_less_0"> <IfElseBranchActivity.Condition>
<CodeCondition Condition="WorkMeth3" /> </IfElseBranchActivity.Condition> <CodeActivity x:Name="NoRoots" ExecuteCode="codeActivity3_ExecuteCode" />
</IfElseBranchActivity> </IfElseActivity> <DelayActivity TimeoutDuration="00:00:05" x:Name="delayActivity1" /> </SequentialWorkflowActivity>
The configuration process producing this XML file is initiated through the special chart processing with WWF tool in Visual Studio environment (see Fig. 2).
Note that the application created is variable i.e. enables square equation solving under various conditions prescribed.
A novel Variability Model and generic Functions are elaborated for its enhanced (i.e. informed, consistent, scalable, traceable and capable to visualize the variability) support whole over PL development. The Model uniformly and consistently represents all Variability items across all the relevant stakeholders’ viewpoints and over all abstraction levels both in PL structure and artifacts. It also includes dedicated submodel for informed and consistent variability assessment. In turn, the Functions – Variability Planning, Implementing in PL artifacts, all-aspect Controlling and Evolving up to assessment results are serviced with Initiation one to initially create the above Model.
An approach is declared to construct Variability Management process being enhanced in the above sense. It prescribes to couple the Model and the Functions as a priori process Core, then continuously test and refine it up to the lessons learnt.
To attempt such a testing, trial Workflow-based Configurator is implemented within the instrumental and technological complex just developed in the Institute of Software Systems of NAS to effectively produce complex systems from the assets. Based on successful Case Study of sample product variant deriving, the authors now update their approach to support all the Functions and fulfil an industrial Case Study.