Keywords

1 Introduction

Software product lines engineering develops and maintains families of products keeping track of their common aspects and predicted variabilities [1]. It focuses on reusability [2]. It is structured into two main processes: domain engineering (also called engineering for reuse) and application engineering (engineering with reuse) [3]. Features are structures that extend and modify the structure of a given program in order to meet the user requirement. Feature models introduced by Kang are used to represent the features available in a product line. They portray all the configurations a product line can possibly have [4]. The concept of feature is useful for description of commonalities and variabilities not only in the analysis and design but also implementation phase of software product lines [5]. There exists a significant relationship between classes and features, but no significant work is done in reference to the complexity that exists across the feature–class relationship. A feature in a feature model is supported by class(s) in a class diagram. Software product line paradigm aims reuse; and like features, classes are also reused. Therefore, the relationship between feature model and class diagrams needs to be studied. The core focus of this paper is to investigate the usability of classes. We have proposed a metric to measure degree of usability of classes. Collaboration diagrams are used to check the result generated by the metrics. The proposed metric is beneficial from the point of view wherein we are able to detect the origin point of most vital classes in the feature model, and also detect the most vital features and the least vital features possibly turning dead in the future. Other possible benefits seen behind the research are planned usage of classes in the system, their better development followed by improved maintenance. The rest of the paper is organized as follows: Section 2 contains introduction of feature-oriented programming. Section 3 introduces Eclipse FeatureIDE. Section 4 contains the proposed metrics and its implementation. Section 5 contains the result, analysis and conclusion.

2 Feature-Oriented Programming

Feature-oriented programming paradigm allows decomposition of a program into its constituent features. It was designed for software product line paradigm that allows significant code reuse and the generation of many similar but functionally different programs from the same set of features simply through selection of desired features [6]. The stepwise refinement leads to a layered stack of features. This helps in constructing well-structured software that can be tailored to the specific needs of the user and the application scenario [7, 8].

3 FeatureIDE: Eclipse Plug-in

FeatureIDE is an eclipse-based integrated development environment (IDE). It provides tool support for the feature-oriented design process and implementation of software product lines [9]. Eclipse FeatureIDE provides the most powerful and commercially successful open-source enhanced IDE support for feature-oriented programming implementations [10]. Domain analysis and feature modeling are supported with graphical feature model editor. Feature implementation is supported by variety of composers like AHEAD, FeatureC++, FeatureHouse, AspectJ, DeltaJ, Munge and Antenna building program families. Out of these we have used FeatureHouse which is language independent.

4 Experimental Setup

4.1 Implementation of the Proposed Metrics

In our Previous paper we have proposed metric for degree of usability [11] let us assume an anonymous feature model and implement the proposed metrics over it. Figure 1 contains this feature model, where F1 is the root node. It has three children: F2 (mandatory), F3 (mandatory) and F4 (optional). The parent node F4 has two child features: F5 and F6. Parent nodes F2 and F3 have one mandatory child each F7 and F8, respectively. There are following dummy classes, C1, C2, C3, C4 and C5, used to implement this feature model. The usage of these classes by the features is shown in Table 1.

Fig. 1
figure 1

Anonymous feature model developed using eclipse

Full size image
Table 1 Calculated values: degree of usability
Full size table

The degree of usability can be defined as the number of times a class is used in different features present in a feature model across the tree. It is obvious that at the root node degree of all the classes will be zero, i.e. at the origin of the class its degree of usability will always be zero. Irrespective of the traversal method the final value of degree of usability of any class will always remain same. Table 1 displays the individual class usage scenario across the feature model. It also shows the calculated value of degree of usability following both methods of traversal, i.e. breath first and depth first.

On the basis of the calculations in the above table we can conclude that classes 1 and 3 have the highest usability. They are used maximum number of times, in comparison to the other classes. The value obtained by this metric is of great worth because it is an indicator of their usage highlighting their importance and subsequent use. Degree of usability can also be derived by classifying abstract and concrete classes. The collaboration diagram generated for this feature model also reflects the same value of usability of each class across each feature. Figure 2 proves our metric, wherein it can be clearly seen that classes 1 and 3 have the maximum reusability.

Fig. 2
figure 2

Collaboration diagram for anonymous feature mode

Full size image

4.2 Implementation of the Proposed Metric

For implementing the proposed metric, we take the example of the Direct-to-home (DTH) systems. To implement our metric we are taking the broader aspect of DTH. We are focusing on its limited functionality and services. This television service is the reception of satellite programs with a personal dish installed individually at home. Its network consists of modulators, broadcasting center, encoders, satellites, multiplexers and DTH receivers. Here service provider leases Ku-band transponders from the satellite. The audio, video and data signals are converted into the digital format and the multiplexer mixes these signals. At the users end, there is a small dish antenna installed and set-top boxes to decode it and viewing of numerous channels. The smallest receiving dish can be 45 cm in diameter. This transmission travels directly to the consumer through a satellite. DTH also offers stereophonic sound effects. Its advantage is that it can also reach remote areas where terrestrial transmission and cable TV cannot penetrate. Along with enhanced picture quality, other benefits are that it allows interactive TV services such as movie-on-demand, internet access, video conferencing and e-mail also. Figure 3 shows the DTH feature model.

Fig. 3
figure 3

Contains the feature model

Full size image

Here DTHBase (root feature) has InformationZone (mandatory), CustomerZone (mandatory) and CarrierZone (optional) features. InformationZone has two mandatory features and two optional features, out of which DTHPackages feature has Basic (mandatory) and two features Regional (optional) and Extra (optional) features. Feature Extra has Kids (optional), Sports (optional) and Movies (optional) features. In total this feature model can have 144 valid configurations.

The basic (dummy) classes in this software include CostInfo, CustInfo, LocalDealerInfo and PackageInfo. The java files which use these dummy classes are jak files (extended files of java), also called FeatureIDE files. In later stages, as per need these classes will be refined in order to add new features in the software. These classes are dummy by nature. Implementation needs more effort on the programmer’s part.

Using the depth first traversal method, the degree of usability of dummy class CostInfo is as follows:

  • At Feature InformationZone, d (CostInfo) = 1, (assuming the degree of Class CostInfo1 at DTHBase is 0)

  • At Feature Set_TopBoxInfo, d (CostInfo) = 2,

  • At Feature DTHPackages, d (CostInfo) = 3,

  • At Feature Basic, d (CostInfo) = 4,

  • At Feature CustomerQuery, d (CostInfo) = 5.

Using the breath first traversal method, the degree of usability of dummy class CostInfo is as follows:

  • At Feature InformationZone, d (CostInfo) = 1, (the degree of Class CostInfo1 at feature DTHBase is 0)

  • At Feature Set_TopBoxInfo, d (CostInfo) = 2,

  • At Feature DTHPackages, d (CostInfo) = 3,

  • At Feature CustomerQuery, d (CostInfo) = 4,

  • At Feature Basic, d (CostInfo) = 5.

Thus we can conclude that the degree of usability of dummy class CostInfo, irrespective of the traversal method, is 5 and is the highest. To check whether the metric is returning the correct value, we refer to the collaboration diagram generated by Eclipse FeatureIDE. Once we define the FeatureIDE files, FeatureIDE generates a collaboration diagram which shows the collaboration of all classes with feature. Figure 4 contains the collaboration diagram for this example. The columns in the diagram contain the classes and rows contain the features which are using these classes. It clearly depicts that class CostInfo is the most referred class. Out of the four dummy classes it is the most frequently used one. Through the diagram also we come to the conclusion that the degree of usability of dummy class CostInfo is 5.

Fig. 4
figure 4

Collaboration diagram of DTH service feature model

Full size image

5 Analysis and Conclusion

A significant relationship is seen between features and classes. The strong association between these two leads us to relate the core focus of SPL in both the respects, i.e. to discuss usability of features and classes as well. The available measures in literature limit the complexity within the features. The complexity across the classes and features relationship remains untouched. Available metrics do not suffice in controlling the usability of the whole system. The metric proposed in our paper is generating the degree of usability of various classes used in the example of DTH services. The collaboration diagram of the example also proves that the metrics are returning values which are true from the practical point of view. The classes which have highest usability theoretically have the same usability practically also. The calculated value thus obtained by our metric will help us check the usage of each class. This will ultimately benefit the programmers, practitioners and researchers in better understanding of classes. It will also help in improved control and development of the product line. It will help determine the best ways for the maintenance of classes which are an integral part of the whole process. Our current work is generalized by nature and is in its initial stages. Our proposal still needs validation. We are currently working upon the theoretical and empirical validations by studying variety of feature models and the classes used for implementing them [12]. We will also apply the metric over more examples to calculate accurate results. Further experimentation will validate our work and help us draw the final conclusions.