Designing variability models for software, operating systems and their families 1

. The complexity of existing Legacy systems and the difficulty of amending it led to the development of the new concept of variability of systems specified by a model of the characteristics of FM (Feature Model). In the paper, we discuss the approaches to formal definition of FM and creating on its basis variants of program systems (PS), operating systems (OS) and families of program systems (FPS) for PS and OS. We give methods of manufacturing of PS in the Product Family/Product Lines, the conveyor of K.Czarnecki for assembling of artifacts in the space of problems and solutions, logical-mathematical modeling of PS from the functional and interface objects by Object-Components Method (OCM), extraction of the functional elements from OS kernel to FM for the generation of new variants of the OS. We discuss approaches for formalization of variability of legacy and new PS and their FPS. The new concept of management of variability systems with help OCM is defined. The approach to verify models of the FM, PS, FPS and OS and to configuration of functional and interface objects for obtaining the variants of the resulting product are proposed. We elaborate the characteristics for the testing process of variants of the PS, OS and FPS.


Introduction
In the recent years, new modeling methods of the program systems (PS) and families (FPS) appeared in software engineering.The methods are aiming to ensure the variability of software systems, both legacy and newly produced ones.One of the first Feature Models (FM) called Product Line/Product Family was developed at the Software Engineering Institute (sei.cmu.edu) for manufacturing software products and their families basing on the assets by customers requests.Product line is group of products or services sharing a common managed set of features that satisfy specific needs of a selected market or mission.K.Czarnecki proposed a concept of generation of PS and FPS based on FM from reuses and artifacts.Object-Component Method (OCM) enables modeling of functional elements with support for variability [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15].
In the paper, we introduce new models with functional and interface elements and FM from these elements for generation of variants of PS and their families.

The Basic Foundation of the Variability of Systems and Families
The FM for software products was first proposed by K. Pohl [1,2] as a basis for creating variants of software and OS [3][4][5][6][7][8][9]: 1) requirements for software are specified by means of the languages -FODA, RSEB, Forfamel, RequiLine, CBFM , Use Case precedents UML etc.; 2) tools -ConIPF, CONSUL/Pure::Variants, GEARS are used for integrating the variability of artifacts with special languages, like Koala, xADL, OVM, VSL etc.; 3) OS mechanisms and functions (e.g.Unix, Linux, etc.), which can be generated in LEADS, OCM [16][17][18][19][20][21][22][23][24][25][26][27] with the languages (VSL, ConIPF, CBFM, Koalish, Pure::Variant, COVAMOF and others) establishing relationships between characteristics of FM and the variants of PS.This paper sets out the basic principles of simulation of variability of PS and FPS in existing approaches of K.Pohl, K.Czarnecki, etc. and proposes the Object Component Method of presenting FM on four-level design using a functional and interface objects.We also define configuration management process in accordance with the Deming cycle [22] to obtain variants of the PS and FPS.

Variability of Products and Systems
K.Pohl introduced the concept of variability in FM out of existing artifacts, reuses, etc. Variability is a property of a product (system) for expanding, changing, adaptation, or configuration for use in a particular context and to ensure its subsequent evolution [1,2].The FM model includes common functional and nonfunctional characteristics of items that can be used by members of the family of FPS for creating different variants of the PS configured at variation points .The variation point is a place in the Legacy-system, which are used for production variant of the big systems.FM defines the process of creating a product from existing software elements, which are called Ready to Use Component (RUC) [11], which includesreuses, assets, applications, etc.The FM in Software Product Line Engineering (SPLE) is based on two processes: engineering of domain and application engineering.The main aspects of variability of products and systems are:  model characteristics of the FM with variation points for functional elements;  variability of the system architecture with variation points;  managing variability of RUC.

Variability in the Space of Problems and Solutions
K. Czarnecki [3,6] provides a modeling of the architecture of the PS and FPS in the problem space and problem solution similar to SPLE approach.The basis of the approach is the characteristics of RUC that appear in FM implementing requirements to PS or FPS.Between characteristics (n) and requirements (m) there may be n  m relations.Each PS is defined by selecting a group of characteristics.
FM consists of the functions that are available to the user of the system and can be in the spaces of problems and solutions, and describes the domain model by means of DSL (Domain Specific Language) with a means for increasing the level of abstraction of FPS.

Variability of the Functional and Interface Elements in OCM
The Object-component method OCM proposes a four-level design of object model (OM) of PS and FPS [21].After design of the OM, we obtain the graph G, which has the form: ), where G t1objects at the synthesis level (t = 1); G t2 -FM at the characteristics level (t = 2); G t3functions at the structural level (t = 3); G t4interfaces relationships at the behavioral level (t = 4).
Fig. 1 shows the elements of processing on the levels of design and structure of OСM objects, their structure, characteristic functions F o =(f o1 ,…,f on ) and interface elements of them I o = (i o1 ,…,i om ) [4,13,21].These features of functional and interface object of OM are located in the PS and FPS.
A functional object f o specifies a formal description of application functions PS, which ensure the solution of problems of a particular domain.This object is given by a triple: the name, data types and their values.

Fig. 1. OM of graph G with functional and interface objects
Axiom.For each functional object, the FPS has at least one characteristic (internal or external) that defines semantics and a unique identification it in the set of F o and interfaces I o .
Features allow to establish the truth of the matching types with Con i = (P i1 , …, P ik ) where P ik is a condition predicate on F oi .Four-level mathematical design FPS of functional and interface objects is defined by the graph: G = (F o , I o , R), where F othe set of functional objects, I othe set of interface objects, Rthe set of relations between these objects [13].
Graph G includes a front-end objects I o (Fig. 2), which call the other object and pass appropriate data with the required type and size.

Fig. 2. The graph G on the set of functional and interface objects
Nodes of G represent functional elementsf o1 , f o2 , f o3 , f o4 , f o5, f o6 , f o7, f o8 and interface elementsi o5 , i o6, i o7, i o8 , and edges correspond to relations R between all types of objects.
Elements f o1f o8 are described in any programming language, and front-end objects i o5 -i o8 are described in IDL.The parameters of the external characteristics of the interface objects are passed between objects through interfaces, and are marked as In (input), Out (output) and Inout (input and output).
The relationship between the functional objects f ok , f ol is provided by interface objects, i.e.
Theorem.The functional interaction between two functional objects is correct, if the first object fully matches functions and data that are required by another object: . With graph G it is possible to construct individual programs P 0 -P 3 using mathematical operation  and corresponding link operation: ); Below we consider the design of models of systems and their variability models.

The definition of models of the PS, OS and their variability
This section discusses models of PS, FPS, OS and their variability.Model of variability PS -M var = (SV, AV) [14,15], where SVsubmodel of variable architecture PS; AVsubmodel of variability of artifacts FPS or RUC.M var enables variability of products and reduces development costs with the help of RUC.The submodel AV determines the structure of the PS from RUC, which are stored in the repository.This submodel displays the characteristics of FPS, as well as aspects of the relationship (through the interfaces) between different levels of the OM.Variation points are handled by the configurator and replaced by some other RUC (correct ones or new).The submodel SV = G t , tr t , Con, Deр, where G t = F t , LF t )is a graph of artifacts on level t; tr tconnection between artifacts on level t; Con, Depthe predicates of the sets of artifacts that define the constraints and dependencies among the functional elements and their indicators of quality.

Model of PS
The concept of a family of programs introduced Dijkstra (1970), which is based on "family" which can be derived from different versions of programs, and can be adjusted and replaced according to requirements [11][12][13][14][15][16][17][18][19][20][21][22][23][24].Family of program systems -FPS is a set of systems with a common set of concepts, specific data, and functional and interface characteristics that are inherent to every member of the family.VRmodel for estimating the level of variability in the FPS, taking into account the requirements, the architecture, artifacts, and data.

Model of FPS family
VPthe sets of variation points in the FPS structure that specify individual characteristics of the PS, including the constraints Сon and Dep dependencies; The OVM model defines two types of assessments of the FPS variabilitylevel and relevance to the consumer needs.The assessment of the level of variability and the degree to which it meets the needs is carried out using the value tree and the parameters VL and VR, which take into account the costs and the frequency of producing new variants for the customer.

Model of operating system kernel and its variability
Model of OS kernel is a collection of individual program fragments implementing the functions of the OS, e.g.Linux [3,23,25,26].Model of OS kernel is a set of artifacts and interfaces between them: , where S ka set of fragments of OS code; M fa set of features; M oa set of dependencies between features, M ia set of interface features (subset of M f ).

The variability model of the OS is identical to the PS model [25].
The OS defines a set of functions and their features.To generate some variant of OS we define the required set of functions and specify the set of interface features.

Managing variability of systems
Variability of systems depends on requirements, FM, architecture, documentation, tests, etc.In general, the variability can be implemented in both PS and FPS.In the case of PS variability includes documentation, functions and elements of any type.In FPS, the variability includes the sets of individual products.The variability of the FPS is managed with: -variation points; -versions of the artifacts; -predicate constraints for variation points.The variability is managed by method of E.Deming, determined by the functions F1 -F4 (Fig. 3) of the development of FPS [22][23][24][25][26][27]: Managing variability of FPS in accordance with the requirements R is performed by: 1) justification of the solution F1 (requirement R1); 2) agreement on the implementation approach (requirement R2); 3) validating the correctness implementation (requirement R3); 4) tracking relationships between system characteristics at all development stages (requirement R4).

Verification of the model variability
The object of verification is a model of the characteristics of the FM and requirements for the development of a new system.Properties of objects, subject to verification of FM are described by means of Linear Temporal Logic (LTL) or a Computational Tree Logic (CTL).Main approaches to formal verification of object are based on deductive verification and model checking [22][23][24][25][26][27][28][29].
Model checking is only applicable to models with a finite number of states and consists in checking that the model conforms to its formal specifications.The specifications are described using the language of temporal logic and assertions.If there is a mismatch between the model and specifications then the counterexample is produced.
The model checking involves execution of the following actions: 1) Build a model of the functional and interface objects, which must have a small number of states.
2) The specification of the requirements in terms of temporal logic.
3) Verification of the model.

Assembling artifacts and RUC in FPS
The assembly of artifacts includes steps F1-F4 using the RUC, and storing them in the repository according to requirements and predicates for RUC [13][14][15].The configuration management of the PS in the FPS includes:  identification of configuration items and data;  managing the process of changes of artifacts and products;  changing the models of variability under the new requirements;  assessment of the variability of the PS and the FPS.
For managing artifacts and their variability in the PS and FPS, so-called model configuration environment is created, which includes: -building process of RUC and artifacts of the system; -schema description of artifacts and database of requirements; -architecture, a set of basic RUC and PS in repository.
-Configurator, combining the artifacts in PS and FPS Managing of configuration environment includes collecting data for such standard operations like reporting and audit.
Reporting configurationcollecting and reporting all necessary information about the state of the development process of the PS.
Audit configurationguarantee that the PS contains the functionality planned in accordance with the specifications including requirements, architecture and user documentation.
In the development of PS the term "assembly" refers to the process of source code transformation from artifacts or RUC, which can be done on a computer and converted into code to run.One of the steps of Configurator is compilation of the source code into intermediate code or into the machine code.Then the linking process replaces the addresses of functions by real addresses used in the program at run time.
Configuration build is based on (Fig. 4): -the engineering model for the development of elements, components, assemblies, reuses, assets, services, product, FPS, and development management to plan and coordinate this activity [25]; -the process model under development "to ensure re-use" (for reuse) and develop "the use of RUC" (with reuse); the model for controlling variability in the process of configuring the product from RUC.

Testing of FPS products
The structure of FPS includes RUC and test products (plans, test suite, test data, etc.) [25][26][27][28].Test code is generated for testing individual PS and form a set of tests for the FPS.Testing method of FPS is based on requirementsbased testing.It specifies the actions to manage testing on the basis of "requirements" with the help of tests to verify functional and interface objects.It determines the control degree of test objects and interfaces, and also the evaluation criterion for the quality of the FPS for the variants of the PS family of FPS.The scheme of testing of the FPS is given in Table 1.Family products Thus, this technique of testing of FPS [28] consists of three steps: 1) Testing artifacts, applications, PS, RUC and reducing the defects in the FPS.
2) Testing of FPS by means of tests.
3) Checking the degree of testing functional and interface objects of the FPS.The test used offline and is common to test individual elements of the FPS.In the last step the degree is defined by the quality of testing metric KT: KT = 1, if tested operations are independent from each another; KT = 0, if tested operations depend on the execution path and interoperability.KT belongs to the segment [0; 1] and is calculated according to the following formula: The final value KT of the FPS specifies the level of examination: KT = 1 if all objects are controlled and KT = 0 if not all objects are controlled and 0<KT < 1 means that the objects of FPS partially controlled.The metrics of the control interface CI i is calculated according to the formula: Where CI ithe degree of correctness of data type conversion in the i-th interface object.If CI i = 1, the interface is fully controlled, CI i = 0, the interface is not completely controlled; CI i = (0, 1)the interface is partially controlled.The metric value of CI means: 1control of CI i interface is complete; 0otherwise.The test used offline and is common to test elements of the FPS.
testing for compliance with specified requirements to individual family members PS and the entire family FPS checks the degree of product testing.If this degree is high, then the manufactured product is delivered to the customer.

Conclusion
The basic fundamental concepts of modeling variability of PS and FPS are given in the original methods of K.Pohl according to FM in Product Family, K.Czarnecki in the space of problems and solutions with ready resources (reuses, assets, artifacts, RUC, etc.) and logic-algebraic approach OCM for modeling the FPS from functional and interface elements.We developed the theory of model definition of FPS from the ready resources for software for FM.The proposed variability model of FPS is based on the specified requirements of the FPS for solving optimization problems of planning of development processes and for evaluation of variability model.Methods for verification, testing, and executing of variants of PS and FPS were proposed.

Fig. 3 .
Fig. 3. Functions in the Deming cycle F1operations and actions for preparation of artifacts (Act) [23]; F2planning of system construction from the artifacts (Plan at the levels of domain engineering and application engineering); F3testing and verification of changes (Check); F4update system FPS (Do).

Fig. 4 .
Fig. 4. General model of configurator in .Net Organization of the development of the PS and FPS is based on the following axioms.Axiom 1.The technology defines a cyclic sequence of software development processes and updating FPS.Axiom 2. Each terminal characterization of OM is implemented by one and only one RUC.

iom io I. Resumptive level Definition of functional (fo) and interface (io ) objects TDn TDi TD1 … … … io 1 fo1 fo0i fo0n fo0 i fo0 fo1 fo1i … foi fon … … fon foni … … io 1 io 1i io i io iu io m io mv
f or )functional objects; M s = (Ms in , Ms out , Ms inout } is the set of servicesinput Ms in , output Ms out and server Ms inout ; M iis a set of interfaces in IDL; M ddata of the PS [9, 13-22].

Table 1 .
Basic schema of testing PS families