A model for variability design rationale in SPL

(1)

A Model for Variability Design Rationale in SPL

Ism ˆenia Galv ˜ao

Department of Computer Science, University of Twente

P.O. Box 217, 7500 AE Enschede, The Netherlands

i.galvao@ewi.utwente.nl

Pim van den Broek

pimvdb@ewi.utwente.nl

Mehmet Aks¸it

aksit@ewi.utwente.nl

ABSTRACT

The management of variability in software product lines goes beyond the definition of variations, traceability and configu-rations. It involves a lot of assumptions about the variability and related models, which are made by the stakeholders all over the product line but almost never handled explicitly. In order to better manage the design with variability, we must consider the rationale behind its specification. In this paper we present a model for the specification of variabil-ity design rationale and its application to the modelling of architectural variability in software product lines.

Categories and Subject Descriptors

D.2.13 [Reusable Software]: Domain engineering

General Terms

Design, Documentation

Keywords

design rationale, software architecture, software product line, variability

1. INTRODUCTION

Variability specification is a core activity in many software engineering methods [12]. In the engineering of software product lines, variability management recognizably plays a vital role. It influences, among other aspects, the develop-ment of the core assets, the choice between variability mech-anisms, the configuration, and the instantiation of products. Variability models such as feature models [8] and orthogonal variability models [12] are often used to describe the com-monalities and the variabilities that differentiate the prod-ucts of a product line.

Current approaches for variability management [13, 17], pro-pose the connection between the variability model elements and other design models of the product line in order to guide

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

the propagation of the variability specification across the de-velopment phases. This is realized by tracing the variabil-ity. Moreover, due to the semantics of variability models, the way the features are structured may indicate trade-offs between features, as well as enforce the decision making pro-cess during product line scoping and product configuration steps. Also in these models, commonalities and variabili-ties reflect stakeholders’ intentions, and their composition constraints state some of the properties of the system. However, tracing implicit dependencies, handling trade-offs, recovering intentions, and preserving variability properties are not simple tasks when the rationale behind the vari-ability is not captured and used properly. A rationale is the justification behind a decision [6] and must explain its funda-mental reasons of a design step. Potential uses of rationale information include the support to reuse, change, consis-tency of decisions, traceability, maintenance, and knowledge transfer. To enable these uses, it is important to keep track of the rationale in a structured and formal way, in which its elements can be recorded, reviewed and controlled.

Although there is a growing number of models and tool sup-port for the management of variability, the automated gen-eration of product line artefacts [16] and the traceability of the variations across the product line life-cycle [1], little has been done on the direction of a model that supports the rationale of variability. The history of assumptions and decisions made regarding each product line piece and the variability definition is an asset that must be incorporated in the product line engineering proces. In an adoption or evolution scenario, the several stakeholders involved in the product line will profit from this information and will better understand how the life of the product line develops. Soft-ware architects will be able to communicate their rationale for the architecture and to understand how the other models influence it and are influenced by it.

The model we propose in this paper is a step towards the creation of a variability design rationale view. It encom-passes cognitive aspects of the variability definition which are relevant for communicating design, such as assumptions, properties and evidences. It will be applied in the future in an automation process of the verification of the design ra-tionale in product lines.

The next section introduces the specification of the proposed model for the rationale of variability. Section 3 describes the

(2)

Figure 1: Variability Rationale

application of the model to the modelling of architectural variability in software product lines. Section 4 discusses and evaluates the proposed model. Section 5 describes related work. Section 6 concludes the paper and lists future work.

2. THE RATIONALE MODEL

This section introduces a model for the specification of vari-ability design rationale. Its definition is in the form of a domain specific language of which the main elements are as-sumptions, properties and evidences, complemented by vari-ability specific terms.

Figure 1 shows the grammar of the domain specific language for variability rationale modeling. The grammar is written in a EBNF-like notation. We use the Xtext framework [2] to create the language parser, the lexical analyzer and a model editor integrated into the Eclipse IDE. The main rules in the

grammar are Model:, Rationale:, Assumption:, Claim: and Property:. The terminals ID and STRING are defined in the grammar Terminals, provided by XText in the package org.eclipse.xtext.common.Terminals.

A rationale model is a composition of elements of kind Ra-tionale, which consists of sets of assumptions. Each element of kind Assumption represents a statement about the de-sign that is assumed to be true. They are often reported by a Stakeholder but can be automatically captured in the system. A statement can be a Claim or a Property. Each assumption is made about a number of artefacts, and may have a list of subassumptions and evidences related to it. A Claim should be made within a category, such as ”general knowledge”, and will indicate a source or target reference, from which the claim was extracted or to which the claim must be propagated, respectively. A claim will have a sta-tus, that can be stated, generated or inferred. A Property defines a quality the system must have, what it must do or sometimes what it should not do. Properties can fall into the categories of quality attributes, invariants and other kinds of formal properties [3]. In this version, the domain specific language supports two categories of properties: SimpleProp-erty and VariancePropSimpleProp-erty. An Evidence is a part of the ra-tionale model as they constitute the means by which a fact or belief can be estabilished or disproved. Each evidence has a proposition supporting the design assumption. The source of an evidence must be stated and formally verified evidences will be followed by the term verified. The evidences listed for a claim may give support to make the assumption stronger, while the ones for a property will manifest information about the formal verification of the property.

3. ARCHITECTURE VARIABILITY

RATIO-NALE

The reason why a certain element in the product line is common or variable is determined by several forces. Model-driven techniques [16] and other approaches, such as the or-togonal variability model [12], suggest that traceability is a sufficient mechanism to find out the justification of the varia-tions by tracing the elements from or to features. However, these approaches do not trace the intentions of the stake-holders, nor do they consider that assumptions made at dif-ferent stages of the product line may become deprecated or invalidated.

We illustrate the usage of the model defined in Section 2 with an aspect-oriented architecture fragment of the MobileMe-dia product line [7]. At the domain specification level, Copy is an optional feature of the product line and Photo is the only kind of media that can be copied. The feature is related to the use case CopyPhoto and traced to several architecture components. A simplistic justification of how the variability of all the artefacts which directly depend on the selection of the feature Copy can be given by means of traceability relations.

Indeed, several architectural elements are involved in the copying of photos. For instance, PhotoViewController is a ”mandatory” component that provides the interfaces Con-trolCopy and InitPhotoView. The first interface is inter-cepted by the aspectual component PhotoCopy, while the

(3)

Figure 2: Partial architecture of MobileMedia

Figure 3: Rationale related to the Copy feature

second is requested by it. Figure 2 shows part of the archi-tecture. The elements of this view are components, aspec-tual components (boxes with round edges), connectors and aspectual connectors (dashed lines). Naturally, part of the assumptions made for the architecture (and its variability) is embedded in the specification of the models. However, the relationships between such assumptions, the properties they require and any evidence that the statement is valid are not documented for further verification.

Figure 3 shows a rationale model with a couple of assump-tions indirectly related to the feature Copy. Assumption A1 in the rationale RationaleFeatureCopy states that the op-eration copyPhoto in the interface ControlCopy is individu-aly considered as crosscutting by the stakeholder Nick. On the other hand, assumption A2 records a proposition that represents a verified evidence that the feature Copy is op-tional with the predicate ”not in(Copy, ProductA)”. This evidence supports the inferred assumption that the interface ControlCopy is optional.

4. DISCUSSION

In the previous sections we introduced a domain specific lan-guage for the representation of variability design rationale.

The language specification is an important step towards the definition of an abstract view over the artefacts. In prod-uct lines, the architecture elements are built and refined by interpreting several assumptions, including the ones behind the explicit variability definition [8, 12] and variability mech-anism usage. Our model for variability design rationale is complementary to other variability representations and or-thogonal to design views.

The proposed model must be further refined to represent the statements and propositions in a machine processable way. This is important because the description of rationale statements in natural language, as in [4, 5, 9, 10, 15], has interpretation limitations and we intend to automate the verification and interpretation of the rationale as much as possible. The proposed model will be used for the system-atic verification of the variability rationale and will assist on detecting violations of design assumptions.

Another extension we foresee is the specification of differ-ent kinds of properties that are useful for the verification of the assumptions with pose constraints to the design. Also, though the model does not give explicit support to decision making, by not defining elements to capture decisions, from our rationale definition, assumptions and properties could be used as decision criteria. The decisions can, therefore, profit from the assumptions’ structure here proposed. A final and important point is that we need to handle the difficulties to keep the consistency of the rationale documentation, and to enforce rationale usage by stakeholders and architects.

5. RELATED WORK

Tang et al. [14] present a rationale-based architecture model and traceability techniques for performing root cause anal-ysis and change impact analanal-ysis over rationales and archi-tectural elements. Capilla et al. [5] contribute with a model for the management of evolvable architectural design deci-sions that provides elements for the capture of rationale and the definition of variation points as decisions for the archi-tecture. Both contributions are limited to decision making during architecture design and do not provide means to re-fine the rationale in terms of several assumptions.

Bass et al. [4] use a cost model and a dependency model to rationalize variability decisions during architecture design. Different tactics for achieving variability are defined and as-sumptions about their applicability are assigned to them. The cost of each tactic is a property that is used to evaluate a tactic against another tactic. The assumptions and the values of the cost property are used to guide the decision process. This work does not provide a standard represen-tation of the rationale elements and also lacks verification mechanisms to check whether the assumptions hold after the realization of the architecture.

A contribution in the direction of combining rationale and variability management is given by Thurimella et al. [15]. Their rationale-based approach for variability management combines the QOC [11] model and elements of an orthogo-nal variability model. The authors apply the QOC method, including justifications to decisions taken while managing variability. This approach is limited to the early stages of SPL development, mixes the semantics of QOC and

(4)

ity model, and does not cope with the evolution nor with the verification of the design rationale.

Lago and Van Vliet [10] propose a metamodel to document long-term invariabilities of the system as assumptions. Their model associates assumptions to features and other struc-tural elements of the architecture. We give more emphasis on the structure of assumptions for the sake of verification of design rationale. In our case, assumptions may concern not only invariabilities, but also variabilities, claims and other assumed properties of the system. We structure the assump-tions in a more specific and formalized way, what enables a more detailed verification of the assumptions against the ac-tual design.

6. CONCLUSIONS AND FUTURE WORK

In this paper we presented a model for the specification of variability design rationale. The model is described in a do-main specific language and integrated with the Eclipse Mod-eling Framework (EMF). We illustrated the representation and usage of the model by demonstrating its application to the modelling of architecture variability in software product lines.

The variability design rationale provides an extra view over architectural models. The dependencies between the as-sumptions made by stakeholders, the variability specifica-tion and elements of the product line architectural model are made explicit in a computable fashion.

Future work consists of the integration of the rationale model into a reasoning and formal verification framework, so that the rationale can be verified against the other abstract or concrete model specifications. We are currently building a knowledge base for reasoning over design assumptions and their relationships. Also, we investigate how evidences of properties and assumptions can be processed using a com-bination of model checking techniques, such as graph-based transformations and temporal logic.

7. REFERENCES

[1] AMPLE Project. http://www.ample-project.net. [2] Eclipse Xtext. http://www.eclipse.org/Xtext/. [3] Baier, C., and Katoen, J.-P. Principles of Model

Checking. The MIT Press, 2008.

[4] Bass, L. J., Bachmann, F., and Klein, M. Making variability decisions during architecture design. In PFE (2003), pp. 454–465.

[5] Capilla, R., Nava, F., and Duenas, J. C. Modeling and documenting the evolution of architectural design decisions. In SHARK-ADI ’07: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent (Washington, DC, USA, 2007), IEEE Computer Society, p. 9.

[6] Dutoit, A. H., McCall, R., Mistrk, I., and Paech, B. Rationale Management in Software Engineering: Concepts and Techniques. In Rationale Management in Software Engineering, A. H. Dutoit,

R. McCall, I. Mistrk, and B. Paech, Eds. Springer, 2006, pp. 1–48.

[7] Figueiredo, E., Cacho, N., Sant’Anna, C., Monteiro, M., Kulesza, U., Garcia, A., Soares, S., Ferrari, F., Khan, S., Filho, F. C., and Dantas, F. Evolving Software Product Lines with Aspects: an Empirical Study on Design Stability. In ICSE ’08: Proceedings of the 30th International Conference on Software Engineering (New York, NY, USA, 2008), ACM, pp. 261–270.

[8] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., and Peterson, A. S. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Tech. rep., Carnegie-Mellon University Software Engineering Institute, November 1990.

[9] Kunz, W., and Rittel, H. Issues as Elements of Information Systems. Working Paper 131, Institute of Urban and Regional Development, University of California, Berkeley, California, 1970.

[10] Lago, P., and van Vliet, H. Explicit assumptions enrich architectural models. In ICSE (2005), pp. 206–214.

[11] MacLean, A., Young, R. M., Bellotti, V. M. E., and Moran, T. P. Questions, Options, and Criteria: Elements of Design Space Analysis. Human Computer Interaction 6 (1991), 201–250.

[12] Pohl, K., B¨ockle, G., and Linden, F. J. v. d. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2005.

[13] Reiser, M.-O., and Weber, M. Managing highly complex product families with multi-level feature trees. In RE ’06: Proceedings of the 14th IEEE International Requirements Engineering Conference (Washington, DC, USA, 2006), IEEE Computer Society, pp. 146–155.

[14] Tang, A., Jin, Y., and Han, J. A Rationale-based Architecture Model for Design Traceability and Reasoning. Journal of Systems and Software 80, 6 (2007), 918–934.

[15] Thurimella, A. K., Bruegge, B., and Creighton, O. Identifying and Exploiting the Similarities between Rationale Management and Variability Management. In SPLC ’08: Proceedings of the 12th International Software Product Line Conference (Washington, DC, USA, 2008), IEEE Computer Society, pp. 99–108. [16] Voelter, M., and Groher, I. Product line

implementation using aspect-oriented and model-driven software development. In SPLC ’07: Proceedings of the 11th International Software Product Line Conference (Washington, DC, USA, 2007), IEEE Computer Society, pp. 233–242.

[17] Zschaler, S., Sánchez, P., Santos, J., Alférez, M., Rashid, A., Fuentes, L., Moreira, A., Araújo, J., and Kulesza, U. Vml* - a family of languages for variability management in software product lines. In SLE (2009), pp. 82–102.