Modelling Variation in Quality Attributes Leire Etxeberria, Goiuria Sagardui, Lorea Belategi Computer Science Department University of Mondragon Loramendi 4, 20500, Mondragon, Spain {letxeberria, gsagardui}@eps.mondragon.edu,
[email protected]
Abstract In a software product line different products often require different levels of quality attributes. In several domains quality attribute variability gets even more importance that functional variability management. However, quality attribute variability in software product lines has not received much attention by researchers. This paper presents a survey of existing approaches for specifying variation in quality attributes.
1. Introduction “Software product line (SPL) is a set of softwareintensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way” [7]. Variability is a key aspect in software product lines but traditionally the main focus has been on functional variability. There are a lot of methods and notations to model functional variability in product lines, some of the most used are feature model based notations [8][17][18]. On the other hand, quality attribute variability in software product lines has not received so much attention by researchers. Software quality is the degree to which software possesses a desired combination of attributes [14]: Performance, security, availability, functionality, usability, modifiability, portability, reusability, integrability, testability [1]… In some domains the fulfilment of quality attributes is even more important that addressing functional requirements. For instance, in embedded systems time or safety issues may be of great importance and their modelling has even bigger complexity that functional requirements modelling.
In a product line different members of the line may require different levels of a quality attribute, for instance they could differ in terms of their availability, security, reliability… One product may require a very high reliability whereas in another reliability is not important. There may also be products that have the same functionality but differ in quality attribute levels. The idea of variations in quality is considered in different works [21][13][23] and there are also some approaches that address variability modelling taking into account quality attribute variability. However, “there is a lack of thorough understanding of existing approaches to be able to integrate quality attribute variability as a part of the systematic variability management of software product lines” as proposed by [21]. In this paper we survey several existing methods that address quality attribute variability and we define a set of requirements that those methods and approaches should have in our opinion to allow modelling different kinds of quality attribute variability. The rest of the paper is organized as follows. In Section 2 quality attribute variability modelling is discussed, section 3 addresses an overview of the compared methods, section 4 presents a set of requirements for modelling approaches and in section 5 an evaluation framework is proposed to compare different approaches and results of the comparison are presented. In section 6 related work is presented and finally section 7 draws conclusions.
2. Quality attribute variability modelling In a product line, there are often products with varying levels of quality attributes. This variability should be modelled and managed from the beginning of the product line development and taken into consideration for designing. Quality attribute
variability is much related to functional requirement variability because often quality attribute variability is achieved through varying functionality and this interrelation must be also represented. This information is very important when deriving because selecting one or another variant has different impact on quality. Many variants represent design decisions that can have a great impact on quality attributes. A model where quality attribute variability is modelled as well as the impacts of functional variants on quality attributes is indispensable to take the most adequate decisions during design and derivation and get the required quality levels. There are approaches for specifying quality attribute requirements that do not address variability explicitly. In a similar fashion, there are approaches for specifying varying requirements that do not address quality attributes [21]. One of the most used modelling techniques to specify varying requirements is the feature model. This model by definition may be used to specify both functional and quality characteristics but in fact quality attributes are difficult to capture in the model due to their ambiguous nature. Moreover, different types of quality variability can be identified. Niemelä [23] defines three types of quality attribute variability: o Variability among different quality attributes: For example, for one family member the reliability is important, but for other family members there are no reliability requirements. o Different priority levels in quality attributes: For example, for one family member the extensibility requirements are extremely high, whereas for others those requirements are at the lowest level. o Indirect variation: Functional variability can indirectly cause variation in the quality requirements
In this section, each of those methods is briefly explained.
3.1. Goal-based model This approach [11] proposes to use goal-oriented analysis in product lines. Goal-oriented requirements engineering is an approach that deals with quality attributes or non-functional requirements in singlesystems [5]. A goal-based model for representing requirements variants (different set of requirements for each product of a product family) is proposed and a visual variability analysis technique is provided. This model is a restricted version of the goal model of the NFR framework [22] and in goal reasoning framework (a probabilistic model) [10]. Two sub-models are proposed: A functional goal model and a softgoal model. The functional goal model represents goals and tasks (functions) and the softgoal model represents conditions or criteria that the system should meet (non-functional requirements or quality attributes). So quality attributes are represented as soft-goals and the operationalization of those quality attributes is encoded in the functional goal sub-model as tasks. Both sub-models are AND/OR trees. Priorities are given per each softgoal on a percentile scale to perform the analysis. And correlations are used to represent the links among functional and softgoals. Correlation links have different influence labels (--,-,?,+,++). Those qualitative labels are converted to quantitative values: one value for satisfiability and another for deniability.
3. Overview of quality attribute variability modelling approaches Six modelling methods that address varying quality attributes have been compared: o Goal-based model [11][12] o F-SIG (Feature-softgoal interdependency graph) [16] o COVAMOF [26] o Extended feature model [3][4] o Definition hierarchy [19] o Bayesian Belief Network [28]
Figure 1: Functional goal model, soft-goal model and correlations (figure taken from [11]) An extension of this approach proposes to use this approach in conjunction with the feature model and use cases [12].
3.2. F-SIG (Feature-softgoal interdependency graph) The main goal of this approach is to provide a framework to record design rationale in the form of interdependencies among variant features and quality attributes. For doing that a new graph is proposed: FSIG, a union of a feature model and a SIG. F-SIG is used. Feature-softgoal interdependency graph [16] is a extension of FORM [18] with concepts of goaloriented analysis [5]. FORM (Feature Oriented Reuse Method) is an extension of FODA (Feature Oriented Domain Analysis) [17], a very well known method to analyze and model a domain that uses a feature model to represent variability. And SIG (Softgoal interdependency graph) is the diagram proposed to model non-functional requirements using softgoals [5]. In F-SIG, explicit and implicit contributions from features to quality attributes are modeled. To express the degree of influence, correlations may also have a label (break:--, hurt:-, unkown: ?, Help: +, Make: ++).
3.3. COVAMOF COVAMOF (ConIPF Variability Modelling Framework) [26] is a framework for variability modelling in software product families. With this framework is possible to model the variability on all layers of abstraction of the product family (from features to code). This framework use the CVV (COVAMOF Variability View) which encompasses the variability of artefacts on all layer of abstraction of the product family. CVV has two views: Variation Point View and Dependency view. The CVV captures the variability in the product family in term of variation points and dependencies. Quality attributers can be modelled with dependencies [27], a dependency can specify a property that specifies the value of a quality attribute such as performance or memory usage. Association is used to associate variation points and dependencies. There are three association types: o Abstract association means that the variation point influences the dependency values but there is no information about how. o Directional association is used when the influence is not fully known and is not specified in a formal manner but there is some information on how the value depends on its binding.
o
Logical association is used when the influence is fully known and is specified as formal knowledge.
Figure 2: Some examples of dependencies and variation points (taken from [26])
3.4. Extended feature model Benavides et al [3][4] propose to extend feature model to deal with extra-functional features. They propose a notation extending feature models with attributes, characteristics of a feature that can be measured such as availability, cost, latency, bandwidth and relations among attributes. Every feature may have one or more attributes relations taking a range of values in both discrete or continuous domain. And it provides automatic reasoning on those extended feature models using CSP (Constraint Satisfaction Problems).
Figure 3: An example (taken from [3])
3.5. Definition hierarchy Kuusela and Savolainen [19] proposed a definition hierarchy method for requirement engineering in product families. The hierarchy is a logical AND tree and topmost nodes are design objectives: architectural drivers and other quality attributes that the system is supposed to fulfil. The other nodes are design decisions and when an edge is between a design objective and a design decision it shows that this requirement is (partially) satisfied by design decisions. Each node in the definition hierarchy gets a priority that reflects the importance of that node in supporting the intention of its parent.
Priorities are product specific; they are used as the mechanism to describe products in the definition hierarchy.
3.6. Bayesian Belief Network Zhang et al. [28] proposed a Bayesian Belief Network (BBN) based approach to quality prediction and assessment for a software product line. The BBN is used to explicitly model the impact of variants (especially design decisions) on system quality attributes. Feature model is used to capture functional requirements and BBN model to capture the impact of functional variants on quality attributes. Quality attributes are represented as nodes in the BBN model. And they are noted with definitions. For instance “High” or “Low”, and those definitions are specific for each domain. (In a specific domain “High” means response time is less or equal to 0.5 ms.) Directed edges are used to relate a design decision or variant to a quality attribute. Conditional probability is used to quantify the conceptual relationships. This probability number reflects domain expert’s belief in how much a given design decision influences quality attributes.
4. Requirements for a quality attribute variability modelling approach Below, we present several requirements that we consider important for modelling quality attribute variability: Modelling and automatic reasoning: To provide a way to represent quality attribute variability in order to analyze and reason about the model. Because if so interesting information is captured, it is very reasonable to use it when deriving or taking other type of decisions. Different reasoning tasks should be interesting: get an approximate value or level for several quality attribute starting from a set of functional requirements, detect impossible configurations starting from a set of functional and quality requirements, detect conflicts among qualities and provide help to performance a trade off analysis... Due to the complexity of this analysis and reasoning, it is very advisable to make it automatic. To achieve automatic reasoning artificial intelligence techniques are need. Three well known problems in the area of automated reasoning are Constraint Satisfaction Problems (CSP), Boolean Satisfiability Problems (SAT) and Binary Decision Diagrams (BDD) [4].
Quality Quality attribute characterization: attributes have vague definitions. In different domains, one quality attribute may not mean exactly the same or different names are used for the same concept. So it is necessary to concretize and make quality attributes more specific. A mechanism for describing and explaining a quality attribute adequately must be provided: A structure where a quality attribute may be explained through refinement among different levels. Optionality: In one product one attribute may be important and in another this attribute not be required. So this attribute is optional in the product line. This may happen at quality attribute level but also at lower level, in the refinements of this quality attribute. For instance, in a quality attribute (performance) that is decomposed into two concerns (“Data latency” and “Transaction throughput”). Those concerns can also be optional or variant. This variability must be represented and not only at product level. It is not enough with specifying this optionality when deriving products. Another example: economy may be optional, for some customers is something to consider but for others is not important. Levels: Different priority levels in quality attributes are need. For example, for one family member the extensibility requirements are extremely high, whereas for others those requirements are at the lowest level. However, quality attributes due to their nature are not easy to quantify, only more concrete concerns (refinement results) may be quantified. It is necessary to provide a way to define different levels (high, medium, low) at quality attribute high level and map those levels to more concrete concerns’ values. Following the previous example: some customers consider economy a high-priority issue whereas others consider it with different degree of importance: quite important, important… Quantitative and qualitative: Indirect variation must be represented with qualitative and quantitative impacts and means must be provided to quantify qualitative influences to be able to do an automatic analysis. Some examples of impacts: o To have different languages impacts positively on usability (qualitative). o To be local application impacts very positively on availability (qualitative). o All features impact on Application Price (quantitative). The price of each feature is known. Group impacts: There are some types of influential relationships that are not addressed in all approaches, for instance, the influence of a group of variants. The
impact of two variants together is not always the sum of the individual impacts of those two variants alone. For instance, in some applications the price of some packages that have several features or options together may be cheaper that buying all the features separately.
5. Comparison of methods An evaluation framework to compare variability modelling approaches that address quality attribute variability has been defined taking into account the quality attribute variability types and the requirements gathered in the previous section (see Table 1). General aspects of the methods are considered: goals, models which are based on, tool support, etc. Reasoning technique is also contemplated, modelling is important but to reason about a model starting from some conditions can be very useful. And of course, how they address variability modelling is also considered: quality attribute variability modelling and functional variability modelling. Table 1: Evaluation framework Element Specific goals Models Reasoning technique Case studies Tool support Variability representation Quality attribute variability Optionality
Levels
Impacts
Functional variability
Description Which are the goals of the approach? Which models or diagrams are used? Does the approach use any reasoning technique? Which one? Where has the approach been applied? Does the approach provide tool support? How does the approach propose to model variability? How does the approach represent quality attribute variability? How does the approach represent variability among quality attribute? How does the approach represent different priority in quality attributes? How does the approach represent indirect variation? Qualitatively or quantitatively? Does it allow representing group impacts? How does the approach represent functional variability?
A summary of the results of the comparison are shown in “Appendix: Comparison results”.
5.1. Goals Two main goals have been detected in the analyzed approaches: o Modelling or representation: To provide a way to capture and represent varying quality attributes and impacts of functional variants on those quality attributes. o Analysis or reasoning: To provide support for variability analysis and reasoning. Reasoning on variability in a product line requires previous quality attribute variability modelling. For that reason, all the methods surveyed that provide support for reasoning also provide a way to represent quality attribute variability. Although some of the methods are clearly oriented to reasoning, for instance [3]. On the other hand, there are methods that only support the representation of varying qualities but not the reasoning, for instance [16].
5.2. Models Variability representation requires the use of diagrams or models to capture all the information. In the most of the cases, existing models are extended or used in conjunction with other models. The most used model is the feature model. F-SIG, Extended goal-based model [12], Benavides et al’s extended feature model and BBN approach use it. “A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate among systems in a family” [8]. Quality attributes can also fit in the definition of feature. A feature is “a prominent or distinctive uservisible aspect, quality or characteristic of a software system or systems” [17]. However, specifying quality attributes as features is not advisable because quality attributes have vague definitions and feature models does not support the necessary characterization of attributes neither the way to represent the impact of functional variants on quality attributes. In the approaches, feature models are used for representing functional requirements; and they are extended or complemented with other models for representing quality. In order to represent quality, goal-oriented model seems to be appropriate (two of the approaches use it: Goal-based model and F-SIG). Goal-oriented requirements engineering is an approach that deals with quality attributes or non-functional requirements in single-systems [5]. It uses the concept of softgoal and qualitative reasoning to provide a way to
represent quality attributes more accurately taking into consideration the vague definitions and the soft nature of the quality attributes. Another existing model used by an approach is the Bayesian Belief Model (BBN). It is used to model the impacts of functional variant on quality attributes. New diagrams specially developed for variability representation are also proposed by surveyed approaches: COVAMOF framework and the definition hierarchy which model functional and quality variability.
5.3. Reasoning technique and tool support Most of the methods use a reasoning technique to make easier the derivation of products. They propose techniques from artificial intelligence: Probabilistic models, CSP-Constraint Satisfaction Problems, rules… The exception is the database and queries that Kuusela and Savolainen [19] propose for getting information and performing analysis. About the tools, most of the methods provide tools that have been developed specifically for those methods. The exception are BBN approach that use a commercial tool for Bayesian networks and F-SIG that uses MS Visio for drawing the models.
5.4. Case studies Most of the approaches apply their methods in theoretical and existing examples but a case study has not been performed. COVAMOF and Definition hierarchy’s approaches are the only ones that have applied their methods in a real product line case. Moreover, COVAMOF is based on more industrial case studies.
5.5. Quality representation
attribute
variability
Quality attributes usually have vague definitions and no clear-cut satisfaction criterion [16] so it is not easy to describe them. One requirement for surveyed approaches is to provide a way to define and characterize a quality attribute. The soft-goal approach is very useful for characterizing quality attributes and the definition hierarchy also but other approaches are not so adequate. They do not provide a structure for characterizing quality attributes: a unique element is used to represent a quality attribute or concern: a node in BBN, a dependency in COVAMOF, a feature attribute in Benavides et al’s approach. They work
with low level quality concepts but they do not provide a way to understand a higher level quality attribute and decompose it in related low-level attributes or concerns. Levels and optionality In general the representation of optionality or variability among different quality attributes and different priority levels in quality attributes is supported but only at product level. It is possible to specify that a product requires a determined level of a quality attribute or that does not require an attribute. Priorities, criterions… are used for defining the requirements of a product in order to derive. However, it is not possible to model this variability at product line level. It is not possible to specify that a quality attribute has different degrees in a product line or that some concerns are optional, quality attribute variability is only represented as an effect of functional variants’ influences. The exception may be the BBN method that allows defining levels with a related condition. However, in this approach it is not possible to characterize the attributes so it seems difficult to define these conditions. Impacts or Indirect variation Functional variability can indirectly cause variation in quality requirements. One variant may influence many quality attributes and one quality attribute may be influenced by many variants. All approaches allow that kind of impacts. But it could be useful to represent feature groups that impact on qualities because the impact of a feature group is not always the sum of the impact of each feature alone. Sometimes there are functional variants that potentialize other variants’ impact, for instance if “help” is optional in a product line, its impact on usability is not fix, it depends on the selection of other functional variants where “help” can be useful. Only two approaches take into account group impact (COVAMOF and BBN). The definition of impact can be quantitative or qualitative. Most of the methods that allow defining quantitative relations are useful for defining qualitative impacts because the values give an idea of the direction of the influence. The only one that is specific for quantitative impacts is Benavides et al. because this approach only is applicable for attributes that can be measured. Table 2 presents the surveyed approaches and how those methods fulfil the identified requirements.
Table 2: Surveyed approaches and how they address identified requirements Requirement Approach Goal-based model F-SIG COVAMOF Extended FM Definition Hierarchy BBN
Automatic reasoning Yes No Yes Yes No Yes
QA characterization Yes Yes No No Yes No
6. Related work There are also other methods that are related, for instance methods for architecture evaluation in product lines [9]: RAP, HoPLAA… The Reliability and Availability Prediction (RAP) method [15], part of QADA methodology [20][23], is used for predicting reliability and availability at the architecture level in a product line. This method captures reliability and availability requirements and maps them to functionality. And it uses a Soft-goal interdependency graph (SIG) for selecting the most adequate architectural style for the product line. HoPLAA (Holistic Product Line Architecture Assessment) [24] is an adaptation of ATAM (Architecture Trade-off Analysis Method) [6] for product lines. This method introduces variability in the quality attribute utility tree used for evaluation. For single-systems there are also approaches for modelling quality aspects. For instance, the UML QoS profile [25] for modelling quality aspects and fault tolerance characteristics.
7. Conclusions This study has compared six approaches for modelling quality attribute variability. And no approach meets all the identified requirements. The less fulfilled requirements are optionality at product line level and different priority levels in quality attributes. Optionality at PL level is only addressed more or less by Kuusela and Savolainen’s approach (definition hierarchy) in which quality attribute variability is represented at product level but with several representative products. In other approaches optionality is represented through priorities for each product, so there is not a global view of this optionality, it is only represented at product level. And different priority levels at product line level are only addressed at Zhang et al’s work (BBN approach). A reasoning technique is necessary to perform a complete analysis of the product line. Reasoning
Optionality at PL level No No No No More or less No
Degrees No No No No No More or less
Quantitative and Qualitative Yes No Yes No Yes Yes
Group impacts No No Yes No No Yes
techniques from artificial intelligence: Probabilistic models, CSP-Constraint Satisfaction Problems… seem to be very useful. These techniques could help to find the most adequate configuration satisfying some conditions (product requirements). Tool support is very important to facilitate the derivation. Tools should support not only quality attribute variability modelling and reasoning but also functional requirement variability. So existing tools for functional variability should be taken into account and extend them or integrate the new tools with the existing ones. Most of the surveyed methods have not been applied in real industrial product lines. As a conclusion a new approach or an extension of an existing approach could be interesting to address all the identified requirements for modelling varying quality attributes.
Acknowledgements This work was partially supported by The Basque Government, department of education, universities and research. Leire Etxeberria enjoys a doctoral grant of the researchers’ formation program.
8. References [1] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison Wesley, 1998 [2] Benavides, D., Trinidad, P., Ruiz-Cortés, A., Using Constraint Programming to Reason on Feature Models, The Seventeenth International Conference on Software Engineering and Knowledge Engineering (SEKE'05) [3] Benavides, D., Trinidad, P., Ruiz-Cortés, A., Automated Reasoning on Feature Models, Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05), 2005, pp. 491 – 503 [4] Benavides, D., Segura, S., Trinidad, P., Ruiz-Cortés, A first step towards a framework for the automated analysis of feature models, Managing Variability for Software Product Lines: Working With Variability Mechanisms workshop (SPLC'06), 2006
[5] Chung, L., Nixon, B., Yu, E. and Mylopoulos, J., Nonfunctional Requirements in Software Engineering, Kluwer Academic Publishers, 2000 [6] Clements, P., Kazman, R., Klein, M., Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2001 [7] Clements, P., Northrop, L., Software Product Lines: Practices and Patterns, Addison Wesley (2002) [8] Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000 [9] Etxeberria, L., Sagardui, G.: Product-Line Architectures: New Issues for Evaluation, 9th International Software Product Line Conference SPLC-EUROPE, 2005, pp. 174-185 [10] Giorgini, P., Mylopoulos, J., Nicchiarelli, E., and Sebastián, R., Reasoning with goal models”, Proceedings of ER’02, 2002 [11] González-Baixauli, B., Leite, J., Mylopoulos, J., Visual Variability Analysis for Goal Models, Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), 2004, pp. 198 – 207 [12] González-Baixauli, B., Laguna, M.A., Crespo, Y., Product Line Requirements based on Goals, Features and Use cases, International Workshop on Requirements Reuse in System Family Engineering (IWREQFAM), 2004, pp.4-7 [13] Halmans, G., Pohl, K., Communicating the variability of a software-product family to customers, Journal on Software and Systems Modeling (2003)2:15 –36 [14] IEEE Standard 1061-1992. Standard for a Software Quality Metrics Methodology. New York: Institute of Electrical and Electronics Engineers, 1992 [15] Immonen, A., A Method for Predicting Reliability and Availability at the Architecture Level, in Ed.: Timo Käkölä, T., Dueñas, J.C., Software Product Lines, Research Issues in Engineering and Management, Springer, 2006 [16] Jarzabek, S., Yang, B., Yoeun, S., Addressing quality attributes in domain analysis for product lines, IEE Proceedings Software., Vol. 153, No. 2, April 2006 [17] Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E, Spencer Peterson, A., Feature-Oriented Domain Analysis (FODA) Feasibility Study, CMU/SEI-90-TR21, Technical Report, 1990 [18] Kang, K.C., Kim, S., Lee, J., Shin, E., and Huh, M., FORM: a feature-oriented reuse method with domainspecific reference architectures, Annals of Software Engineering, 5, 1998, pp. 143-168 [19] Kuusela, J., Savolainen, J., Requirements Engineering for Product Families, Proceedings of the 22nd international conference on Software Engineering (ICSE), 2000, pp. 61 – 69 [20] Matinlassi, M., Niemelä, E., Dobrica, L., Qualitydriven architecture design and quality analysis method: A revolutionary initiation approach to a product line architecture, VTT Publications, 2002 [21] Myllärniemi, V., Männistö, T., Raatikainen, M., Quality Attribute Variability within a Software Product Family Architecture, Second International
conference on Quality of Software Architecture QoSA, 2006 [22] Mylopoulos, J., Chung, L., Yu, E. and Nixon, B., Representing and Using Non-functional Requirements: A Process-Oriented Approach, IEEE Transactions on Software Engineering, 18 (9), June 1992, pp. 483-497 [23] Niemelä, E., Architecture Centric Software Family Engineering, Product Family Engineering Seminar Product Family Engineering Seminar, 2005 [24] Olumofin, F.G., Misic, V.B.: Extending the ATAM Architecture Evaluation to Product Line Architectures, 5th Working IEEE/IFIP Conference on Software Architecture, WICSA 2005, IEEE Computer Society, 2005 [25] OMG Adopted Specification, UML TM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, ptc/2004-06-01, 2004 [26] Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J., COVAMOF: A Framework for Modelling Variability in Software Product Families, Proceedings of the Third Software Product Line Conference (SPLC 2004), Springer Verlag, (LNCS 3154), pp. 197-213, August (2004) [27] Sinnema, M., Deelstra, S., Nijhuis, J., Bosch, J., Modelling Dependencies in Product Families with COVAMOF, Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS'06), 2006, pp. 299-307 [28] Zhang, H., Jarzabek, S., Yang, B., Quality Prediction and Assessment for Product Lines, Proc. of the 15th International Conference On Advanced Information Systems Engineering (CAiSE'03), 2003, LNCS 2681, Springer-Verlag, pp. 681-695
Appendix: Comparison results Method
Goal-based model [11]
F-SIG [16]
COVAMOF [26]
Extended FM [3]
Definition hierarchy [19]
Explicit representation of the variability in software product families
Provide automatic reasoning on SPL dealing with extrafunctional features
Requirements capturing, analysis and documentation for product families
Represent the impact of variants on quality attributes
CVV (COVAMOF Variability View)
Feature model extended to deal with extra-functional features (quality features)
Definition hierarchy
Feature model and BBN model
Rules and inference
CSP-Constraint Satisfaction Problems
Case study: Intrada product family. There are also previous case studies COVAMOF-VS: Tool Suite for Microsoft Visual Studio
Two examples: Home Integration Systems (HIS) and JAMES PL
A database and tools to allow complex queries A case study of a weather station product family
Probabilistic reasoning: Bayesian belief network Example with CAD (Computer Aided Dispatch) system PL
A set of tools to manipulate information stored in a DB Design objectives in topmost nodes Priorities
A commercial tool for BBN: Hugin tool is used Nodes in the BBN model No
Element
BBN [28]
Specific goals
Represent requirements variants in a product line and provide support for variability analysis
Models
Goal model: functional goal sub-model and softgoal sub-model
Reasoning technique
Probabilistic model
A framework to record design rationale in the form of interdependencies among variant features and quality attributes F-SIG (FeatureSoftgoal interdependency graph): FORM’s feature model + SIG (Softgoal interdependency graph) No
Case studies
A published example giving the emphasis on variability
Example with CAD (Computer Aided Dispatch) system PL
Tool support
A tool implemented in Excel with visual basic components
MS Visio
Softgoals
Softgoals
Dependencies
Priorities are given per each softgoal Priorities are given per each softgoal Correlations among functional goals and softgoals.
No
No
Feature’s attribute relations No
No
No
Criterions
Priorities
Annotations
Association among variation points and dependencies
Features have attribute with quantitative value
Priorities and tree
Both
Explicit and implicit contributions from features to quality attributes Qualitative
Both
Quantitative
Both
Directed edge between a design decision or variant and a quality attribute. Both
No
No
Yes
No
No
Yes
Functional goal submodel
Feature model
Variation points
Feature model
Design decisions in the definition hierarchy
Feature model
Quality attribute variability
Variability representation
Optionality Levels Impacts
Qualitative or quantitative Group impacts Functional variability
A prototype of a holistic Feature Solver
