Modelling Variation in Quality Attributes

Transcription

1 Modelling Variation in Quality Attributes Leire Etxeberria, Goiuria Sagardui, Lorea Belategi Faculty of Engineering University of Mondragon Limerick

2 Research group &3 ; /7, 43 Research areas: Software Product Lines Component Based Development,.: :907$ , $419, #080,7. 74:5 2

3 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 3

4 Introduction Software Product Line (SPL) is a set of software-intensive 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 [Clements 02] Variability: Functional variability Quality attribute variability Software quality is the degree to which software possesses a desired combination of attributes [IEEE 92] Quality attributes Operational attributes: performance, security, availability, usability Development attributes: modifiability, portability, reusability, integrability, testability 4

5 Quality attribute variability In a SPL, different members may require different levels of a quality attribute Availability, security, reliability Different types of quality attribute variability [Niemelä 02] 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. 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. Indirect variation: Functional variability can indirectly cause variation in the quality requirements 5

6 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 6

7 Requirements for QA variability,25 0 Help system Location Language Topic structuring Context-sensitive help Local Online English Spanish Table of contents Index Search Important quality attributes for our PL Usability Cost 7

8 Requirements for QA variability What does usability mean in our PL? Usability is understood as Supporting international use, Efficiency, Learnability, Working in an unfamiliar context And cost? Cost is understood as software price and maintenance cost Are there any optional or variant quality concerns? Optional: Supporting International use is optional: some customers do not require this option Learnability is optional: if the product is for expert users it is not selected Variant: Efficiency is an alternative variant (it depends on user type): efficiency for experts vs efficiency for novices. In our PL we can have different quality attribute levels: High, Medium or Low. For instance: high usability, medium usability and low usability 8

9 Requirements for QA variability Different kinds of influential relations: Qualitative impact More languages Supporting international use Usability More languages Maintenance cost Cost Context-sensitive help Working in an unfamiliar context Usability Index Efficiency for experts Index Efficiency for novices Table of contents Efficiency for novices Table of contents Efficiency for experts Quantitative impact Software price = Σ feature price. Each feature has a quantitative impact on software price, so they impact on cost. Group impacts Impacts negatively Impacts very negatively Impacts positively Impacts very positively However, in some cases, there are packages (a set of features or options together) and they are cheaper that buying all the features separately 9

10 Requirements for QA variability Reasoning: Which is the product with the highest usability? Which is the cheapest product? What is the value or level for usability and cost starting from a set of functional requirements? For instance: Online, English, index and search and without context-sensitive help What is the level for usability and cost? Is this configuration possible (a set of functional and quality requirements)? High usability and Online, Spanish, table of contents and without context-sensitive It is not possible to get a high level of usability English should be selected and also context-sensitive help Detect conflicts among qualities and provide help to performance a trade off analysis If we want a cheap product with high usability, we have to negotiate: no so high usability or a bit more expensive product 10

11 Requirements for QA variability Modelling and automatic reasoning: Represent quality attribute variability in order to analyze and reason about the model. Complex analysis automate Help for derivation and also early prediction of quality attributes Quality attribute characterization: Quality attributes have vague definitions mechanism for characterizing quality attributes is necessary Optionality: Optional attributes and refinements Levels: Different priority levels in quality attributes are need. Example: High, medium, low Quantitative and qualitative: Indirect variation must be represented with qualitative and quantitative impacts Group impacts: The impact of two variants together is not always the sum of the individual impacts of those two variants alone 11

12 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 12

13 Overview of approaches Approaches that address quality attribute variability modelling have been surveyed: Goal-based model [González-Baixauli 04, 04b] F-SIG (Feature-softgoal interdependency graph) [Jarzabek 06] COVAMOF [Sinnema 06] Extended feature model [Benavides 05] Definition hierarchy [Kuusela 00] BBN (Bayesian Belief Network) [Zhang 03] 13

14 Goal based model Models A functional goal model: goals and task (functions) A softgoal model: quality attributes Impacts Correlations with influence labels (--,-,?,+,++) Priorities are given per each softgoal on a percentile scale to perform the analysis Figure taken from [González-Baixauli 04] 14

15 F-SIG (Feature-softgoal interdependency graph) Models Feature model (FODA) to model functional requirements SIG (Softgoal interdependency graph) to model non-functional requirements using softgoals Explicit and implicit contributions from features to quality attributes: Label (break:--, hurt:-, unkown:?, Help: +, Make: ++) Figure taken from [Jarzabek 06] 15

16 COVAMOF CVV (COVAMOF Variability View): Quality attributes as dependences Three association types: Abstract, directional and logical Product class Legend Variation Point Feature Layer Full Custom Basic Variant Realization Dependency notepad interface word mail interface manager built-in editor database interface file storage network interface Realizes Processor Usage Dependency Interaction Architecture Layer Editor Component Performance Persistency Component tepad Built-in Word Memory Consumption Database Files Figure taken from [Sinnema 06b] 16

17 Extended feature model Feature model extended to deal with extra functional features using Attributes, characteristics of a feature that can be measured such as availability, cost, latency, bandwidth and relations among attributes Figure taken from [Benavides 05] 17

18 Definition hierarchy Model A logical AND tree Topmost nodes are quality attributes The other nodes are 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. Figure taken from [Kuusela 00] 18

19 BBN (Bayesian Belief Network) Models Feature model to capture functional requirements BBN model to capture the impact of functional variants on quality attributes Quality attributes are represented as nodes in the BBN model. Quality attributes are noted with definitions. For instance High or Low, and those definitions are specific for each domain. Figures taken from [Zhang 03] 19

20 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 20

21 Comparison Goals Modelling or representation: To provide a way to capture and represent varying quality attributes and impacts of functional variants on those quality attributes. Analysis or reasoning: To provide support for variability analysis and reasoning. Models The most used model is the feature model. F-SIG, Extended goal-based model [González-Baixauli 04b], Benavides et al s extended feature model and BBN approach use it. In order to represent quality, goal-oriented model seems to be appropriate (two of the approaches use it: Goal-based model and F-SIG). Another existing model used by an approach is the Bayesian Belief Model (BBN). It is used to model the impacts of functional variants on quality attributes. New diagrams specially developed for variability representation are also proposed by surveyed approaches: COVAMOF framework and the definition hierarchy which models functional and quality variability. 21

22 Comparison Reasoning techniques Tools 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 Most of the methods provide tools that have been developed specifically for those methods. Case studies The exception are BBN approach that use a commercial tool for Bayesian networks and F-SIG that uses MS Visio for drawing the models. Most of the approaches have been applied 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 been applied in a real product line case. Moreover, COVAMOF is based on more industrial case studies. 22

23 Comparison Quality attribute Characterization The soft-goal approach is very useful for characterizing quality attributes and the definition hierarchy also 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. Levels and optionality In most of the methods, it is supported but only at product level: product specific priorities, criterions 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. Group impacts: Only two approaches take into account group impact (COVAMOF and BBN). Quantitative or qualitative. Most of the methods allow both kinds 23

24 Comparison: how approaches address requirements Automatic reasoning QA characterization Optionality at PL level Levels Quantitative and Qualitative Group impacts Goal-based model Yes Yes Yes F-SIG Yes COVAMOF Yes Yes Yes Extended FM Yes Definition Hierarchy Yes More or less Yes BBN Yes More or less Yes Yes 24

25 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 25

26 Related methods Methods for architecture evaluation in product lines: The Reliability and Availability Prediction (RAP) method [Immonen 06] To predict reliability and availability at the architecture level in a product line. 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) [Olumofin 05] is an adaptation of ATAM (Architecture Trade-off Analysis Method) for product lines. It 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 [OMG 04] for modelling quality aspects and fault tolerance characteristics. 26

27 Overview Introduction Requirements for QA variability Overview of approaches Comparison Related work Conclusions 27

28 Conclusions Six approaches for modelling quality attribute variability have been compared 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. A reasoning technique is necessary to perform a complete analysis of the product line. Reasoning techniques from artificial intelligence: Probabilistic models, CSP- Constraint Satisfaction Problems 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. Existing tools for functional variability should be taken into account and extend 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. 28

29 Thanks for your attention! Contact information: Leire Etxeberria University of Mondragon 29

30 References [Benavides 05] 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 [Clements 02] Paul Clements, Linda rthrop, Software Product Lines: Practices and Patterns, Addison Wesley, 2002 [Etxeberria 05] Etxeberria, L., Sagardui, G.: Product-Line Architectures: New Issues for Evaluation, 9th International Software Product Line Conference SPLC-EUROPE, 2005, pp [González-Baixauli 04] 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 [González-Baixauli 04b] 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 [IEEE 92] IEEE Standard Standard for a Software Quality Metrics Methodology. New York: Institute of Electrical and Electronics Engineers, 1992 [Immonen 06] 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 [Jarzabek 06] Jarzabek, S., Yang, B., Yoeun, S., Addressing quality attributes in domain analysis for product lines, IEE Proceedings Software., Vol. 153,. 2, April 2006 [Kuusela 00] Kuusela, J., Savolainen, J., Requirements Engineering for Product Families, Proceedings of the 22nd international conference on Software Engineering (ICSE), 2000, pp [Niemelä 02] Niemelä, E., Architecture Centric Software Family Engineering, Product Family Engineering Seminar Product Family Engineering Seminar, 2005 [Olumofin 05] 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 [OMG 04] OMG Adopted Specification, UML TM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, ptc/ , 2004 [Sinnema 06] 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 [Sinnema 06b] Sinnema, M., Deelstra, S., Hoekstra, P., The COVAMOF Derivation Process, 9th International Conference on Software Reuse, ICSR 2006, Proceedings. Lecture tes in Computer Science 4039, Springer (2006) (Presentation) [Zhang 03] 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