Vamos 2014 Vision
Vamos 2014 Vision
Nicolas Sannier, Guillaume Bcan, Mathieu Acher, Sana Ben Nasr, and Benoit Baudry
Inria - IRISA Universit de Rennes 1 Campus de Beaulieu 35000 Rennes, France
General Terms
Theory
Keywords
Product comparators, Product congurators, Product comparison matrices, Variability models, Feature organization
1.
INTRODUCTION
Product comparators and congurators have now become common in our daily activities. Whenever one desires to buy a new camera, a computer, a smartphone, a car or a shirt, one can explore, compare and congure a large number of customizable products. In diverse industries, many companies aim at giving customers products closer to their expectations and thus gain higher market shares [31]. Two kinds of systems product comparators and product congurators are usually developed and provided to ease the decision-making process of choosing a product. On the one hand, product comparators list similarities and dierences between two or more than two competing products. These sets of similarities and dierences can be
2.
In this section, we present a ctive scenario that illustrates pros and cons of comparators and congurators.
2.1
Alice and Bob live in Montreal (Canada) and want to buy their new car. Bob is a Hockey player, while Alice usually plays keyboards within a rock band. Besides the classic requirements (engine power, color, fuel consumption,
Figure 1: Example of a Product Comparison Matrix in a car comparator number of doors), they do not have particular requirements relatively to the car brand or its model. However, they do have some special requirements that are very important. They have a closed garage box. Rqt1: The car width must not exceed 1,75m. Bob is a relatively large person, as he plays Hockey, and is used to have long trips. Rqt2: The car must have a comfortable and adjustable interior. When Alice goes to rehearse with her friends, she needs to put down all her stu in the car. Rqt3: The car must have some reasonable cargo capacity. Bob enjoys driving using his armrest during his long trips, but Alice does not. Rqt4: The car must have independent armrests. Alice enjoys listening to music and she spend a lot of time with music on her player. Rqt5: The car must have a USB/Dock derivation to plug a media player. Though these requirements are not major functional requirements for a car, most of them are concrete and may be desirable features and have high customer priority [20]. Many car comparators exist on the Internet. In this section we propose a description of the comparison provided by a Canadian website1 and illustrated in Fig. 1. In this comparator, one has to strictly select the year of production, the car brand, the model and its trim (model version). Moreover, the comparator only take into account at most three cars to compare. As a consequence, A user is forced to have a rst coarse grain intuition of the vehicle he wants and take a rst signicant arbitrary decision even before starting the comparison process. Available online at http://www.autonet.ca/ comparenewvehicles#comparenewvehicles-tabs, last access 5th november 2013
1
With three cars under comparison, the comparator proposes a set of 28 clusters of 104 dierent features (characteristics). With Dierent car models, the set of features may vary accordingly to the features presence or absence from the cars. The comparison is presented as a car by feature matrix. These features are organized in two sections, a rather well dened and structured section that contains most of the clusters and a second part containing raw information, which is called options. We now observe the comparators accuracy with respect to Bob and Alice special requirements. We assess the relative position of the requirements evaluation in the matrix: Rqt1: The answer about the width of the car appears in the exterior dimensions cluster, and in particular, at line 96. Rqt2: Regarding the interior dimensions, they appear in the previous cluster interior dimensions and are presented from lines 85 to 92 of the comparison. Rqt3: For the cargo area dimension, the comparator provides the cargo volumes between lines 103 and 104. Rqt4 and Rqt5: For these two requirements, the comparator do not provide any information whereas these two features may represent interesting marketable features. The comparator does not only provide features information, it also provides a separate factual evaluation of the advantages / disadvantages of the compared cars. However it does not rank these cars, neither it proposes visual ranking of the comparison. It simply proposes a summary of the most obvious dierences.
2.2
Bob and Alice still not have completely chosen their new car but they go on conguring several cars from dierent
Figure 2: Example of a car congurator vendors and use car congurators such as the one presented in Fig. 2. These congurators are very similar as they rst impose you to chose the model version and package and then tune, within 5 or 6 steps, the remaining options such as color, interior trend, as well as some additional features. In Fig. 2, the scenario is as follows. First, the user chooses one of the cars models and its particular package. The user goes on with the cars color and nishes by choosing interior and exterior items and nally select extra features, which are mostly external items, that are out of the scope of the product specication. Depending of the vendors congurator, these steps can be independent or not, but the very large majority of the conguration has already been done while choosing the version of the car and its package. All of them do not propose all of the available features (imposed in the package or not mentioned at all). There exist combinatorial issues that set industrial limits in the product customization, as well as cognitive limits to human variability analysis capability [16]. Though the remaining options still propose a signicant variability, the very large majority of the conguration has already been imposed and realized through the initial version packaging. Yet user experience is not necessarily satisfactory. Trentin et al. recently discussed ve improvement directions for sales congurators that deal with: (1) focused navigation capability, (2) benet-cost communication, (3) exible navigation, (4) easy comparison, and (5) user-friendly product space description [31]. The previous scenarios illustrates the limits presented by Trentin et al., not only for congurators but also for comparators. Currently, when comparing products, one must choose between potential candidates, and force a rst decision that he may not want to make. Users features are not ordered accordingly to their preferences but presented in a raw. Not all product features are presented neither are subject of analysis. The process of conguring a product is mainly limited to a few number of features and hardwired. Comparators and congurators actually provide complementary solutions for visualizing and conguring products. Hence both systems can be combined: a comparator is a mean to obtain a rst rough intuition of the product he desires ; in a second step, congurator is used to get a more precise product denition and eventually customize it. Comparators can also be integrated as part of a conguration step, when customers focus on some aspect of a product. For example, a comparator of car engines can be activated when conguring the engine. The current problem faced by practitioners is the lack of comprehensive and systematic solutions for engineering high-quality comparators and congurators that are able to address the previous criteria [21, 31]. A possible unication of the two systems can be realized through the use of Product Comparison Matrices (PCMs). In essence, PCMs are a specic form of spreadsheets documenting the features
2.3
The ctive scenarios leads us to the following general observations. Comparators and congurators are very simple, convenient and complementary approaches for people who want to have a rst glance on dierent properties over a set of products or about a specic product. They are extensively used within commercial perspectives to provide customers valuable general products information as well as more detailed ones, when available.
of products under comparison. An example of PCM is in Fig. 1 where three products are compared accordingly to a set of properties (in practice, many more products can be considered and depicted). PCMs are obviously at the heart of product comparators. Congurators also operate over a set of (possible) products and PCMs can be a suitable input data for congurators2 . Our vision is that integrated tools, based on variability modeling and techniques, should be developed for generating dedicated comparators or congurators from PCMs. Variability models provide a sound foundation for PCMs, comparators and congurators while existing techniques developed in the eld can be reused to organize the conguration process, reason about the set of product, etc. To realize this vision, dierent research questions have to be addressed. A key issue is to provide and exploit a common, formally dened representation of PCMs through variability models. For this purpose, we need to further understand the anatomy and semantics of PCMs, develop automated techniques to synthesize variability models and exploit the variability models to derive comparators and/or congurators.
exclusion between the values, the availability of all features in the product, etc; Unknown value: one does not know if the criterion is satised. Cells are generally lled with ?, Unknown or in the example: TBD (see 4 of Fig. 1); Empty cell. It is tempting to interpret the empty value as the absence of a feature. Yet it can prevent the product from being selected, despite the uncertainty or the ignorance of the information. 5 of Fig. 1 gives a concrete example: there are obviously doors in a car, but the information is not present.
3.2
3.
PCMs abound on the Internet. They can be found in Wikipedia pages but are also visible in Web comparators (see Fig. 1). When comparing two or more products, PCMs are presented to users and list the features supported (or not) by a specic product. Intuitively variability models, like decision or feature models, can formally represent a set of comparable product. In this section, we illustrate and discuss the variability information patterns (we introduced in [29]) with a PCM found in an existing car comparator.
3.1
Interestingly, the variability patterns observed in the car comparator PCM are almost similar to the patterns reported in our previous empirical analysis over Wikipedia PCMs [29]. That is, we also observe Boolean yes/no values, single values, multi-values, unknown values and empty cells. A notable dierence is the absence of non homogeneous values for a given criterion (e.g., values can be both Boolean and multivalued). A possible reason is that PCMs of Wikipedia have been specied by an open and large community while PCMs of comparators are limited to a knowledgeable group of experts, facilitating the use of a common vocabulary. A systematic analysis of comparators found on the web is needed to conrm these observations. Another observation is that variability information in both types of PCMs not only contain boolean values but numerical values, variability inside products and uncertainty. These types of values challenge state-of-the-art techniques for reverse engineering and reasoning about variability models. In this short discussion, we already identify two research directions. In the next section, we elaborate more on the ongoing research challenges that have to be addressed to realize our vision around PCMs, comparators and congurators.
The car comparator of Fig. 1 compares 3 manually selected cars ( A in the gure) against numerous criteria ( B in the gure, most criteria are hidden for spacing purpose). This comparison is simply presented as a PCM. We note the presence of dierent comparison perspectives ( C in the gure) materialized by categories in the feature list. We observe the following patterns: Boolean yes/no values stating the presence or absence of the feature in the product. In the example, Disc front and Disc rear are common features of the 3 products (see 1 in Fig. 1); Single values whose purpose is to state that the criterion is satised and to precise this criterion. In 2 of Fig. 1, the value 4 for the second car states that the car has 4 passenger doors; Multi-values that enumerate a set of values that satisfy the criterion. The last row of the PCM shows an example (see 3 in Fig. 1). The semantics of multivalues is specic to a given context. A multi-value can have dierent interpretations and meanings: a mutual
2 Congurators are general conguration systems and are not limited to PCMs, i.e., the input of a congurator can be any forms of databases or a logical formula. In particular congurators can handle very large sets of congurations/products that are pointless or hard to enumerate [21, 32].
4.
RESEARCH PLAN
Our ultimate goal is to create tool-supported techniques for generating dedicated comparators or congurators from PCMs. We now propose research directions related to (1) the understanding, formalization and management of PCMs and (2) the use of variability models as a central formalism for analyzing and conguring a set of product. We also propose a research method and what resulting concrete outputs can be delivered at the end of the research. Fig. 3 summarizes our research plan.
4.1
Research Questions
We aim at addressing the following research questions: PCMs are at the heart of the research. It is thus crucial to better understand the syntax, semantics, limits (w.r.t. end-users and maintainers) of PCMs: RQ1: What is the syntax and semantics of PCMs? The variability patterns we reported in Section 3 or in [29] have to be rened and formalized and are not claimed to be exhaustive. Other syntactical constructs may be observed in other contexts. Another question concerns the semantics of the patterns, e.g., what does mean an empty value when choosing a product?
RQ5 (customized generation) O5 (reasoning techniques) RQ3 (specication and maintenance) O3 (domain-specic editor)
Editor
Figure 3: Research questions (RQ) and expected output (O) RQ2: What are the issues faced by endusers when exploiting a PCM? End-users read PCMs to nd the most appropriate product, ideally in a short amount of time. Several factors can limit the user experience: overwhelming users with too much information (i.e., too many products or too many criteria [16]); presenting imprecise information or with unclear semantics, making the PCM hard to understand, etc. RQ3: How to specify and maintain a PCM? Maintainers (e.g., contributors of Wikipedia [29], product managers or experts of a domain) write PCMs and as such should be dierentiated to endusers. Without any canvas, framework, or dedicated tools, practitioners are likely to write ad hoc PCMs with doubtful quality (e.g., with unclear semantics). We aim to propose a transition from PCMs to more dependable and assisted comparative (resp. conguration) environments. RQ4: How to synthesize variability models from PCMs? Variability patterns found in PCMs have to be translated into a formal variability model using systematic transformation rules. However, the process is likely to be semi-automatic and supervised by practitioners since the variability patterns are subject to interpretation. Scalable synthesis techniques, able to handle numerous products and features, have to be developed and applied in the specic context of PCMs. RQ5: How to generate congurators or comparators from variability models? We build upon the vision exposed in [9] that describes a generative process for devising Web congurators. Numerous techniques can be considered for this purpose (see Section 5) but an integrated solution is still missing. We also envision the combined generation of congurators and comparators. PCMs is a good starting point but other PCMs can be considered. Such empirical studies can benet to the understanding of PCMs. O2: We plan to conduct usability studies to better understand the PCMs limits as well as evaluating pros and cons of providing a congurator and/or a comparator. O3: As a concrete research output, we plan to develop a domain-specic environment (editor) for specifying PCMs. We hope the resulting PCMs can be easier to visualize, maintain and analyze (e.g., transform). O4: Supervised, tool-supported techniques to synthesize formal variability models from PCMs are another expected output of the research. O5: Engineering techniques to generate congurators or comparators from variability models are still to be developed.
5.
RELATED WORK
4.2
To address the ve research questions, our research plan and expected outputs are as follows: O1: As a research method, we plan to empirically study real-world PCMs. Our rst work with Wikipedia
Spreadsheets and PCMs. Considerable research eort has been devoted to the study of spreadsheets [24]. The effort is still ongoing around automated techniques for fault localization and guidelines towards well maintainable spreadsheets [1, 12, 18]. PCMs can be seen as a special form of spreadsheets. However, none of these works consider the specic nature of PCMs and especially the variability information they contain. The empirical study on PCMs of Wikipedia [29] is a rst step, but as elaborated in this paper further research eort is needed to understand, formalize and exploit PCMs. Reverse Engineering Variability Models. The product line research community has shown signicant interest in the ability to automatically generate (Boolean) feature models from existing data. Numerous feature model synthesis techniques were proposed [24, 17, 30] but they do not consider PCMs as input. Dumitru et al. [14], Ryssel et al. [27] and She et al. [13] process product-by-feature matrices, but only with Boolean values whereas other kinds of values are present in PCMs. Such techniques should be revised to take the variability patterns and kinds of values found in PCMs into account. In [3], we proposed a semi-automated procedure to support the transition from product descriptions (expressed in a PCM) to feature models. This initial work was conducted on a limited data sample. As a result, we overlooked dierent
aspects of PCMs (e.g. variability patterns, semantics). The research questions exposed in this paper are more general and go beyond variability models. Variability Modeling. Information in PCMs contains more than simple Boolean values. Products themselves exhibit variability [29]. Boolean variability models fail to formalize such types of values. Extensions of feature models are natural candidates for formalizing PCMs. Attributed feature models [6,11] can handle numerical values and model extra-functional constraints of products. Multi-features [11] can be used to model a part of the variability included in products. Probabilistic feature models [13] can model uncertainty and support soft-constraints. Product comparators and congurators can benet from supporting such constraints as users are likely to express preferences instead of denitive choices and propose more exibility during the comparison and conguration process. Despite these extensions and several studies on variability modeling languages [5,7,8,10,15], the formal connection between variability models and PCMs is still to be dened. Conguration. Abbasi et al. empirically analyzed 111 Web congurators [21] and derived a catalog of good and bad practices. Rabiser et al. performed a qualitative study to understand the benets and drawbacks of guidance capabilities in conguration tools [26]. There are techniques for organizing the conguration process [19], reasoning about decisions [7, 23] and generating user interfaces [25]. Recommender systems [14, 28] or visualization techniques for exploring a set of products [22] can be considered as well when developing congurators or comparators.
6.
CONCLUSION
In this paper, we presented our vision towards the use of variability models to devise product comparators or congurators from product comparison matrices (PCMs). We discussed pros and cons of comparators and congurators through a motivating example applied on Web commercial tools. We showed that PCMs are at the core of comparators and can be inputs of congurators. We described a unied approach based on the synthesis of formal variability models from PCMs. We set ve research questions and presented our research methodology related to the understanding, formalization and management of PCMs and the use of variability models for generating comparators and congurators. In the middle of the bridge between makers and users of product comparators and congurators, perspectives are many. The major challenge is to nd the best trade-o between the commercial/industrial combinatorial issues and the product variety paradox [31] that confuses users with too much variability information at a time. We believe that the use of variability modeling techniques and integrated tools to create, maintain, and transform more eciently PCMs can be leveraged to manage such trade-os.
7.
ACKNOWLEDGMENTS
8.
[1] R. Abraham and M. Erwig. Ucheck: A spreadsheet type checker for end users. J. Vis. Lang. Comput., 18(1):7195, 2007.
REFERENCES
[2] M. Acher, B. Baudry, P. Heymans, A. Cleve, and J.-L. Hainaut. Support for reverse engineering and maintaining feature models. In S. Gnesi, P. Collet, and K. Schmid, editors, VaMoS, page 20. ACM, 2013. [3] M. Acher, A. Cleve, G. Perrouin, P. Heymans, C. Vanbeneden, P. Collet, and P. Lahire. On extracting feature models from product descriptions. In VaMoS12, pages 4554. ACM, 2012. [4] N. Andersen, K. Czarnecki, S. She, and A. Wasowski. Ecient synthesis of feature models. In SPLC12, pages 106115, 2012. [5] K. Bak, K. Czarnecki, and A. Wasowski. Feature and meta-models in clafer: mixed, specialized, and coupled. In SLE10, LNCS, pages 102122. Springer, 2011. [6] D. Benavides, A. Ruiz-Cort es, and P. Trinidad. Automated reasoning on feature models. CAiSE05, 3520:491503, 2005. [7] D. Benavides, S. Segura, and A. Ruiz-Cortes. Automated analysis of feature models 20 years later: a literature review. Information Systems, 35(6), 2010. [8] T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czarnecki. A study of variability models and languages in the systems software domain. Software Engineering, 99(PrePrints):1, 2013. [9] Q. Boucher, G. Perrouin, and P. Heymans. Deriving conguration interfaces from feature models: A vision paper. In VAMOS12, 2012. [10] A. Classen, Q. Boucher, and P. Heymans. A text-based approach to feature modelling: Syntax and semantics of TVL. Sci. Comput. Program., 76(12):11301143, 2011. [11] M. Cordy, P.-Y. Schobbens, P. Heymans, and A. Legay. Beyond boolean product-line model checking: dealing with feature attributes and multi-features. In ICSE2013, pages 472481, 2013. [12] J. Cunha, J. Visser, T. L. Alves, and J. Saraiva. Type-safe evolution of spreadsheets. In FASE11, pages 186201, 2011. [13] K. Czarnecki, S. She, and A. Wasowski. Sample spaces and feature models: There and back again. In SPLC 08, pages 2231, 2008. [14] H. Dumitru, M. Gibiec, N. Hariri, J. Cleland-Huang, B. Mobasher, C. Castro-Herrera, and M. Mirakhorli. On-demand feature recommendations derived from mining public product descriptions. In ICSE11, pages 181190, New York, NY, USA, 2011. ACM. [15] H. Eichelberger and K. Schmid. A systematic analysis of textual variability modeling languages. In SPLC13, pages 1221, 2013. [16] J. T. Gourville and D. Soman. Overchoice and assortment type: When and why variety backres. Marketing Science, 24(3):382395, 2005. [17] E. N. Haslinger, R. E. Lopez-Herrejon, and A. Egyed. On extracting feature models from sets of valid feature combinations. In FASE13, pages 5367, 2013. [18] F. Hermans, M. Pinzger, and A. v. Deursen. Detecting and visualizing inter-worksheet smells in spreadsheets. In ICSE12, pages 441451, 2012. [19] A. Hubaux, P. Heymans, P.-Y. Schobbens, D. Deridder, and E. K. Abbasi. Supporting multiple
[20]
[21]
[22]
[23]
[24]
[25]
[26]
perspectives in feature-based conguration. Software and Systems Modeling, pages 123, 2011. N. Kano, N. Seraku, F. Takahashi, and S. Tsuji. Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, 14(2):147156, 1984. E. Khalil Abbasi, A. Hubaux, M. Acher, Q. Boucher, and P. Heymans. The anatomy of a sales congurator: An empirical study of 111 cases. In M. Norrie and C. Salinesi, editors, CAiSE13, 2013. A. Murashkin, M. Antkiewicz, D. Rayside, and K. Czarnecki. Visualization and exploration of optimal variants in product line engineering. SPLC13, 13, 2013. A. N ohrer and A. Egyed. C2o congurator: a tool for guided decision-making. Autom. Softw. Eng., 20(2):265296, 2013. R. R. Panko. Thinking is bad: Implications of human error research for spreadsheet research and practice. CoRR, abs/0801.3114, 2008. A. Pleuss, B. Hauptmann, D. Dhungana, and G. Botterweck. User interface engineering for software product lines: the dilemma between automation and usability. In Proc. of EICS12, pages 2534, 2012. R. Rabiser, P. Gr unbacher, and M. Lehofer. A qualitative study on user guidance capabilities in
[27]
[28]
[29]
[30]
[31]
[32]
product conguration tools. In Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering, ASE 2012, pages 110119, New York, NY, USA, 2012. ACM. U. Ryssel, J. Ploennigs, and K. Kabitzsch. Extraction of feature models from formal contexts. In FOSD11, pages 18, 2011. C. Salinesi, R. Triki, and R. Mazo. Combining conguration and recommendation to dene an interactive product line conguration approach. CoRR, abs/1206.2520, 2012. N. Sannier, M. Acher, and B. Baudry. From comparison matrix to variability model: The wikipedia case study. In ASE, pages 580585. IEEE, 2013. S. She, R. Lotufo, T. Berger, A. Wasowski, and K. Czarnecki. Reverse engineering feature models. In ICSE11, pages 461470. ACM, 2011. A. Trentin, E. Perin, and C. Forza. Sales congurator capabilities to avoid the product variety paradox: Construct development and validation. Computers in Industry, 64(4):436447, 2013. Y. Xiong, A. Hubaux, S. She, and K. Czarnecki. Generating range xes for software conguration. In M. Glinz, G. C. Murphy, and M. Pezz` e, editors, ICSE, pages 5868. IEEE, 2012.