Abstract: Background: Software Product Lines (SPLs) have been used successfully for building software systems families. One of techniques that are widely used to support SPL’s variability modelling is feature modelling. These methods have been used to recognize and manage commonalities and variability among products. But like anything in this world, software systems families are rapidly changing and demanding for more dynamic capabilities. Materials and Methods: One of the challenging problems of dynamic SPLs is that feature modelling techniques are unable to support dynamic capabilities and their formalization. In fact, feature modelling techniques support well elementary features, but the composed ones are not yet supported nor formalized. This study aims to deal with this challenge. It extends the conventional elementary feature modelling concepts, with composed feature and inherent relations concepts. According to bio-inspired approach, a software configuration comes up by composing its features from elementary or any other composed features. Then this configuration may evolve through its life cycle by metamorphosing, changing from a composed feature to another. Results: This software feature-based evolution variability modelling technique has led to an introduction of a new methodology producing an extended feature model by new meta features and relations. The combination of two formalisms in the specification of this methodology is more powerful than a unique one. Conclusion: The obtained results compared to the actual approaches seem to be promising. The bio-inspired software evolution has led to identify weaknesses of currents feature-based evolution approaches. The introduction of new powerful feature modelling concepts and supporting formal approach, inspired from nature is expected to promote the software evolution.
INTRODUCTION
Variability in Software Product Lines (SPLs) has been used successfully for building software systems families. Designing SPL is one of the most important processes that aim to increase reusability of the system by gathering products that have commonalities and shared features in the same set. Thus, the cost and effort of building product’s components will decrease. On the other hand, recognizing and managing variability among different products is one of the SPL’s purposes1. Different methods have been used to recognize and manage commonalities and variability among products. Feature modelling is one of the most used methods for modelling the variability of SPL2. Features, in feature models are used to represent commonalities and variability of the system. In addition, it is the property that is relevant to the requirements and stakeholders in the system. Many approaches dealt with the traditional SPLs. Younis3 and Younis and Ghoul4,5 have presented a new textual software product lines design model, mixing class and feature concepts. The methodology supports design and implementation of variability. In addition, it defined four meta-feature models to support feature modularization and to classify features based on their functionalities.
Now-a-days, everything is rapidly changing including software systems families that demands for more adaptation capabilities and evolving during the runtime mechanisms. Traditional SPL’s architectures are unable to provide such capabilities and mechanisms. Today, there are attempts to design dynamic SPL’s architectures that have more capabilities for adaptation, making decisions and evolve during the run time1. Recently, efforts for using dynamic SPLs are increasing. Alfereza et al.6 proposed a framework based on variability models to support run time adaptation capabilities for service compositions. Pascual et al.7 proposed a dynamic SPL approach for supporting reconfiguration at run time policies for mobile applications. Researchers could generate configurations from the feature model during the run time according to the conditions using multi objective evolutionary algorithms. There are many research works to represent SPLs in a formal way. Andres et al.8 presented a formal framework for software product line, by using algebra process (SPLA) to describe Feature-Oriented Domain Analysis (FODA) diagram9. A cost-related extension for algebra SPLA was presented by Camacho et al.10. This extension is supporting cost for software product lines and it is applicable in several decision making processes.
Software evolution is one of the challenging problems of bio-inspired system modeling11, a configuration of a system is able to automatically evolve (change its structure, functions and behaviour) into a different configuration during the run time according to an event. Software evolution is a demand for many systems and applications on which entities need to be adaptive or evolve dynamically at runtime. Several approaches dealt with evolution in different ways. Ghoul12 presented a bio-inspired objects evolution concept. This concept was based on the experimentation of Meslati and Ghoul13. Naffar14 and Naffar and Ghoul11 presented a bio-inspired objects evolution methodology approach. An object is able to evolve (change its structure, behaviour and functions) automatically during the run time, without changing its class membership.
In conclusion, all of the above features variability modelling approaches for SPLs, do not support the adaptation capabilities and the software evolution variability concepts and process. Besides, there is no suitable mapping between real world concepts and computing concepts. Although, the evolution concepts presented by Naffar and Ghoul11 could achieve the desired evolution for a software by reducing the gap between real world concepts and computing ones, but it is not based on variability standard notations and concepts like features modelling. Also the formalization aspect is still poor despite its importance.
Based on the above stated insufficiencies, this study proposes a formal methodology guiding the software features variability modelling process, which start from a software requirements features model and then, produces a formal feature-based software design model, supporting variability as well as evolution concepts via a real world closer way. This methodology extends the traditional feature model concepts with evolution concepts (a bio-inspired technique) adapted11. It builds an extended feature model from the traditional ones. The introduced evolution concepts, in features based modelling, mainly consists of composed feature (configuration) and related relations: Explicit select/reject, inferred select/reject, default select and at-age. These relations enrich the feature-based modelling process by allowing features grouping (configuration composing) and metamorphosing (configuration evolving through its life cycle).
Feature modling: As evidences of this motivation and contribution, the following paragraph presents, some significant recent closest works, based on features modelling and software evolution, with their insufficiency to what this study propose a solution.
Software evolution and features modeling current approaches: There are different approaches to deal with software evolution and features modeling. This study is limited to the ones that are most relevant to this study contribution.
Younis3 and Younis and Ghoul4,5 presented a formal methodology that support software variability design and implementation. It bridged between the product lines design model and the object oriented implementation model. In addition, a new briefed and rich textual notation for feature modelling and class modelling was provided. Besides, it defined four meta-feature models to support feature modularization and to classify features based on their functionalities. Some solutions with DSPL architectures start to appear. Alfereza et al.6 proposed a framework based on variability models to support run time adaptation capabilities for service compositions. The researchers formalized the service compositions into feature based variability model. Thus, they used the activation/deactivation of features concept to made changes in the functionality of service compositions according to conditions during the run time. Consequently, having the adaptation capabilities during the run time for both: Service compositions and traditional feature model. Pascual et al.7 proposed a DSPL approach for supporting reconfiguration at run time policies for mobile applications. Researchers used the feature models to abstract the variability of applications. They could generate configurations from the feature model during the run time according to the conditions using multi objective evolutionary algorithms. Mizouni et al.15 presented a framework for adaptation mechanisms in mobile applications based on the conditions changes. Researchers used the SPLs concepts to develop self-adaptive policies in mobile applications. They depended on three concepts of feature modelling to achieve the adaptation mechanism: Features priorities (Critical, important and useful), features availability (Activation/deactivation of features) and degradation of features (changing only behaviors for mandatory features). They used three separated feature models to define each type of features priorities. In conclusion, all features variability modelling approaches, of the above SPLs do not support the adaptation capabilities and the software evolution variability concepts and process.
Several approaches dealt with evolution in different ways. Naffar14 and Naffar and Ghoul11 presented a bio-inspired objects evolution methodology approach. An object is able to evolve (Change its structure, behaviour and functions) automatically during the run time, without changing its class’ membership. In addition, it has reduced the gap between real world concepts and computing ones. But it is not based on features variability modeling notations and concepts.
Actual insufficiencies and proposed solution: There have been different approaches to handle Software evolution with feature modeling. One of the challenging problems in dynamic SPLs is that feature modelling techniques are unable to support dynamic capabilities and their formalization. In fact, feature modelling techniques support well elementary features but the composed ones are not yet supported nor formalized. So, this study aims to deal with this challenge. It extends the conventional elementary feature modelling concepts, with formal composed feature concepts. According to a bio-inspired approach, a software configuration comes up by composing its features from elementary or others composed features. Then this configuration may evolve through its life cycle by metamorphosing from a composed feature to another. This software feature-based evolution variability modelling has led to an introduction of a new methodology producing an extended feature model by new meta features and relations.
MATERIALS AND METHODS
Introductory example: A common introductory example which will be used through the whole work will be presented. The introductory example is the list product.
List has several features, such as: Behaviours, structures, methods, etc. and each feature could be implemented in static or dynamic way. Thus, each feature should be defined in two feature variations: static and dynamic.
By using Feature Model (FM), list product can be modelled along with its two implementations families: Static and dynamic features as shown in Fig. 1.
List product has several variations, such as: Static queue, static stack, dynamic queue, dynamic stack, etc. According to evolution concepts, a list product should be able to evolve (Change its behaviour, structure and methods) during the run time. In other words, a list product configured as static queue is able to turn into dynamic queue according to occurrence of an event. Figure 1 formalism shows that a FM is able to model several variations of list and their implementations, but not able to model the evolution of these variations.
| Fig. 1: | Feature diagram of software list |
| Fig. 2: | A methodology for feature-based variability modelling in software evolution, using UML notation |
Methodology for variability modelling in software evolution: The proposed methodology for variability modelling in software evolution starts with user’s requirements, then, the elementary feature model (ElFM) will be produced and depending on the ElFM, the evolution feature model might be developed according to conditions. Finally, the extended feature model which is a software design model will be obtained (Fig. 2). Each methodology element will be presented.
Extended feature model (ExFM): The ExFM, produced by (output of) the methodology is composed of two sub models: Elementary feature model (ElFM) and evolution feature model (EvFM):
<ExFM> = (<ElFM> | <ElFM>, <EvFM>) [<ExFM>]
Elementary feature model (ElFM)
Definitions: The ElFM does not deal with the evolution aspect and it is limited to basic features:
| Fig. 3: | Elementary feature diagram of list |
The elementary feature model is composed of elementary features, defining every possible features of a software with their relations:
Where:
Attributes:Present user defined characteristics of a feature:
| <attributes> | = | "attributes" ((<Attr_name>) : <Attr_value> (","<Attr_value>)*)*; |
Relations:Define relations among features:
<relations> = "relations" (<decomposition> | <constraint>)*
The decomposition relations are defined by:
<decomposition> = "decomposition" <and> | <xor> | <or>
And the constraint relations are defined by:
<constraint> = "constraints" <imply> | <exclude>
A complete graphical example of elementary feature model: The following Fig. 3 shows a graphical elementary feature model of list given in Fig. 1. Where the ElFM is now a part of the extended feature model.
A complete example of formal specification of an elementary feature model: The following Fig. 4 shows an example of formal specification of an ElFM which is the textual representation of the ElFM of list given in Fig. 3.
Evolution feature model (EvFM)
Definitions: The EvFM deals with the evolution aspects. Evolution can take place in elementary feature (which is out of this study scope) as well as in composed one (termed as configuration) at run time according to an event, where event is predefined from the requirements. Evolution can occur to composed feature by:
| • | Adding composed feature/s: Besides, adding all needed relations among the new added composed feature/s and features of elementary feature model |
| • | Deleting composed feature/s: Consequently, deleting all features that exclusively owned by the deleted composed feature/s |
| • | Changing composed feature/s: Thus, a certain configuration is able to turn into different configuration (change its behavior, structure and methods). Age is defined11 as a milestone for a certain configuration to evolve at run time, where the initial age = 0 and the termination age = n. An evolution within a certain configuration would occur when 0<age<n and it could occur once or more, till it reach the termination age |
| Fig. 4: | A formal specification of an elementary feature model List_ADT (Fig. 3), using algebraic notation |
The evolution feature model is defined by:
The evolution feature model is composed of composed features and it defines software configurations composed by elementary or composed features with their relations:
Where:
Attributes: Present characteristics obtained from composing features:
| <attributes> | = | "attributes" (<Attr_name> : <Attr_value>)*; (*each attribute has single value obtained from composing features attributes values*) |
Relations:Define relations between a composed feature and its composing features:
| <attributes> | = | "relations" (<decomposition> | <constraint>)* |
The decomposition relations are defined by:
| <decomposition> | = | "decomposition" (select (<feature>)* | default (<feature>)*)* |
And the constraint relations are defined by:
Composed feature abstract data type: Figure 5 shows a formal specification of a configuration abstract data type, using algebraic notation.
Examples: In the following, examples illustrating the configuration operations effect on extended feature model are presented.
Add
Input: Extended feature model (Fig. 3) and a configuration (A definition example):
| configuration Stqueue |
| attributes variation: static list; |
| relations |
| decomposition Stqueue select List (variation = static list); |
| default static queue; |
| constraint Stqueue reject st-beh |
| end configuration static queue |
| Fig. 5: | A formal specification of configuration ADT using algebraic notation |
| Fig. 6: | An ExFM after a configuration add operation |
Output:
| • | Extended feature model (Fig. 6) |
| • | Configuration attributes: Generated automatically (Stqueue attributes example): |
| configuration Stqueue | |
| attributes | |
| category: software; | |
| variation: static list; | |
| structure: static structure; | |
| behavior: unknown; | |
| methods: sq-methods; |
Delete
Input:
| • | Extended feature model (Fig. 6) |
| • | Configuration name (Example configuration static queue) |
| Fig. 7: | An ExFM after a configuration delete operation |
| Fig. 8: | An ExFM before a configuration change operation |
| Fig. 9: | An ExFM after a configuration change operation |
Output: Extended feature model (Fig. 7)
Change
Input:
| • | Extended feature model (Fig. 8) |
| • | Configuration (Example stqueue) |
| • | At age: 10 |
Output:
| • | The extended feature model in Fig. 9 |
| • | Configuration (Example dyqueue) |
RESULTS AND DISCUSSION
The implementation environment of this methodology requires a strongly typed and an object-oriented programming language. Extensions that were presented earlier in Ghoul16 are building on. These extensions might be processed by any OOPL pre-processor. Configurations can evolve according to their Feature model.
This approach is recommended to be used in any feature modelling area like product family engineering, software product lines, system families that needs self-adaptive, runtime reconfigurable mechanisms and self-management.
| Table 1: | Comparisons with other works |
| ✓: Highly supported, ✕: Not supported, ✣: Low supported | |
Real examples: Wireless sensor networks, automated transportation systems and any systems that need runtime reconfigurable mechanisms and self-adaptive policies.
Based on study of feature modelling techniques and SPLs, comparing among these approaches can be done according to several criteria:
| • | Methodology supporting composed feature modelling: Does the work present a methodology for its composed feature modeling |
| • | Elementary feature supporting in feature modeling: Does the work support elementary feature in its feature model |
| • | Composed feature supporting in feature modeling: Does the work support composed feature in its feature model |
| • | Variety in selection relation supporting in feature model: Does the work support several kind of select relation (default and implied) in its feature model |
| • | Extension of conventional feature model: Does the work propose an extension to the conventional feature in its feature model |
| • | Structural formalization of feature model: Does the work use a formal specification for feature structure modeling |
| • | Behavioral formalization of feature model: Does the work use a formal specification for feature behavior modeling |
| • | Combination of formalization languages: Does the work use a combination of formal specifications for feature modeling |
Different approaches4,7,8,10,15 were used in the comparison with this study.
Table 1 shows a conclusion of the comparison in brief lines. The criteria that are used in this comparison are given numbers from 1-8. The ✓ symbol means highly supported. The ✣ symbol means low supporting and the ✕ symbol means not supporting.
CONCLUSION
According to this study about evolution concepts, feature modeling and software product lines engineering, the current traditional feature models are not able to effectively support the evolution process and concepts. In addition, the current traditional feature models are not formalized by using powerful notations that could serve our purpose for formalizing evolution concepts by using feature-based variability approach.
In this study, a feature-based variability approach for modelling software evolution was proposed for supporting variability and evolution concepts. This approach had extended the traditional feature model concepts with evolution ones by building an extended feature model from the traditional one. The evolution concepts are mainly a composed feature (configuration) with its related evolution relations (explicit select/reject, inferred select/reject, default select and at age). These relations empower the feature model to have feature grouping and metamorphosing.
The extended feature model is formalized by using a combination of two formalisms notations. The EBNF notations were used for defining the structure of the model whereas, the algebraic notations were used for defining its properties.
Several aspects are however identified to be valuable perspectives: Evolution of software by adding, removing and changing an elementary feature and the impact that it might have on feature-based modelling process. Also, this study deals only with feature-based variability modelling in software evolution engineering. What is about feature-based variability modelling in software evolution reverse engineering and Reengineering? The answers to these open questions will be real challenges in this domain.
ACKNOWLEDGMENT
This study is sponsored, from 12/12/2013 to 12/12/2016, by Philadelphia University, through the research project "Bio-inspired Systems Variability Modeling" at the Bio-inspired System Modeling Research Laboratory.