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) [1,2] just accomplished in the Institute of Software Systems of NAS of Ukraine. Over the project Software Product Line (PL) Engineering [3] has proven to be the promising paradigm to produce a diversity of high-quality similar-but-different products with limited time and efforts.
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. [4]. The first, specific PL variability, describes properties and qualities that should vary between the systems of the PL and that should not. In return, the second one is single Software variability -i.e., the ability of a software system or artefact to be extended, changed, customized or configured for use in a specific context.
However, just now researchers' efforts concentrate foremost on variability modeling [4,5] and implementing [3], while challengeable problems of its planning and evolving less attention are paid. One of perspective frameworks to consistently cope with them is COVAMOF [6] determining whether, when and how software variability in PL should evolve with special meta-model and method for its assessment.
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.
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 [3,4,6].
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. [6] note, it is not by-product of design and implementation of variability, but answers the question, what does vary, being therefore identified as central element in managing variability. Each variation point is associated with a value, zero or more variants. Variation points are categorized to five basic types such as: optional (zero or one variant out of 1,…, m associated variants), alternative (1 out of 1,…, m ), optional variant (0,…, n out of 1,…, m ), variant (1,…, n out of 1,…, m ), and value (a value that can be chosen within a predefined range).
A variant is thus the second Variability item answering the question, how does vary the variation point it is associated with [4].
The third one is dependency [3,6]. It specifies a function of how the choices at the variation points in the PL influence a system property value, e.g. quality attribute, as well as the valid range for this value. The last one, namely constraint, is a predicate that defines possible interrelations between various variation points and variants. Variability Levels in PL development. Thorough study of PL Development process [2,3] experiences five possible types ( t ) of variation points and variants corresponding their Lyfe Cycle over PL Development: -Features, i.e. abstract concepts reflecting commonalities and variabilities of software products in PL relevant for some Stakeholder that might represent a technical function, a function group or a non-functional characteristics ( t = 1) -Requirements as to Software Products ( t = 2) -Аrchitecture сomponents ( t = 3) -Database tables ( t = 4) -Software artifacts ( t = 5).
Target characteristics for Variability Management enhancing. Based on the experience and ideas formed during the above Institute of Software Systems of NAS research project (№ 0107U002205) [1,2], four Berg et al. [5] essential quality characteristics are chosen to adopt as a target for the Variability Management process to be defined. These are consistency, scalability, traceability and visibility.
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.
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
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 [2][3][4]6] within the perspective of Doeming's PDCA Management Cycle [7]. These are informed and consistent Variability Planning, Implementing in PL artifacts, all-aspect Controlling and Evolving up to both retrospective and current elements of VP and CP . They serve due rationales for appropriate managerial decisions over FN processing. All necessary technological prerequisites as well as initial VM and RP are created with the fifth function of Variability Management Initiation.
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 .
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 [2][3][4][5][6]8] as well as for all functional segments from PL scope and also for all its stakeholders' viewpoints ─ traceable notations usage for PL artefacts modelling appropriate to their types ─ explicit identification of commonalities and variabilities across all PL development artefacts, stages and stakeholders' viewpoints ─ sound, informed and consistent PL variability profile assessment.
Relevant Variability Model is defined [8] to be a hybrid structured triple
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 [2][3][4]6] 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 t TR from (3), which interrelates this artifact with the features it should implement and the final software product. 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 ( 11 , g G ) downwards to the programmers' and testers software and tests at the fifth one ( 55 , g G
). The third submodel of SV model expands Metzger's Orthogonal Variability Model [4] with a novel dimension of sound quantitative variability estimates VP vp from (1). They quantify the level of PL variability adequacy within the perspectives of both PL customers' business needs in its products' functions and PL developers' requirements as to them. For the estimates' plausibility and consistency to increase, universal preferences model such as Bayesian Net, Analytical Hierarchy and Value Tree should be configured up to the assessment situation [9]. It is also a
where: VL and VR are subsubmodels both for integrated variability adequacy level in a whole and, respectively, for its sublevels corresponding the artifacts' types;
are the sets of variation points in SV (3) model;
are the sets of variants for these variation points.
Here the probe implementation of PL artefact variability model AV (4) is considered for simple domain of quadratic equations solving. While classical feature diagram [4,6] clearly demonstrates the variety of variability items at the feature level, it's quite difficult to implement it in specific application in PL repository. Instead MS Visual Studio Windows Workflow Foundation (WWF) enables more information about AV with appropriate diagram (see Fig. 1).
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 (
), implemented by the developer responsible for producing PL core assets. Depending on its operating outcome, there are three scenarios (use case):
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 [2,10]. It purposes at configuring a diversity of similar-but-different applications from reusable software components and also at expanding and modifying applications with variation points and variants [1,2,8] based on WWF [2,10,11]. An interim result of configuration process with the Configurator is XML file shown beneath. It is an instruction for executable file compiling to create the target application. <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.