[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Chapter 9Cognitive Insights into Feature DiagramNotation and Beyond

9.1 Introduction

Variability is the ability of a software system or artefact to be extended, changed,customized or configured for the use in a particular context [GBS01]. Imple-mentation of variability allows delaying design decisions concerning a supportedfunctionality to later stages of the software development process. Rather thandeciding on specific features, a product will have, at early design stages, softwarearchitecture and set of components which are defined to allow the configuration offeatures to match user requirements, at a late design stage.

Managing variability is a major concern in the development, maintenance andevolution of software-intensive systems [Jar05, SB00]. There are two main reasonsfor this trend. First, in reuse approaches, including object-oriented frameworks,component-based software engineering and software product families, the reusabil-ity of any software artefact is determined by its ability to support the variabilityrequired from it. Second, the complexity of variability management has increasedtremendously; therefore, more systematic approaches are required to overcome thelimitations of ad hoc approaches. Successful management of variability in softwareleads to better customizable and reusable software products. To be managedeffectively and efficiently, variability must be explicitly modelled.

In this chapter, the feature-based variability modelling approach using FeatureDiagrams (FD) is described. First, we begin with the overview of the featuremodelling research. Then, we proceed to introducing the Feature Diagram notationand the basic set of its abstractions. Finally, we describe the extensions of FeatureDiagrams proposed by the authors of this book as well as other researchers.

V. Stuikys and R. Damasevicius, Meta-Programming and Model-Driven Meta-ProgramDevelopment, Advanced Information and Knowledge Processing,DOI 10.1007/978-1-4471-4126-6 9, © Springer-Verlag London 2013

143

144 9 Cognitive Insights into Feature Diagram Notation and Beyond

9.2 Overview of Feature Variability Management Research

Feature modelling is a family of notations and an approach for modelling com-monality and variability in product families [KCHC90]. In early stages of thesystem family development, feature models provide the basis for scoping the systemfamily by recording and assessing information such as which features are importantto enter a new market or remain in an existing market, which features incur atechnological risk, what is the projected development cost of each feature, etc.[BS99]. Later, feature models play a central role in the development of a systemfamily architecture, which has to realize the variation points specified in the featuremodels [Bos00, CE01]. In application engineering, which is the process of buildingindividual systems based on assets supplied by the system family development, fea-ture models can drive requirements elicitation and analysis. Knowing which featuresare available in the system family may help the customer to decide about the featureshis or her system should support. In particular, knowing which of the desiredfeatures are provided by the system family and which have to be custom-developedhelps to better estimate the time and cost needed for developing the system.

Currently, there are four major variability management methodologies used:feature modelling (FM), scope-commonality-variability (SCV) analysis [CHW98],COVAMOF [SDNC04] and formal concept analysis (FCA) [Sne96].

SCV analysis [CHW98] uses a theory of sets for modelling variability. It definescommonality as an assumption held uniformly across a given set of objects (S).Frequently, such assumptions are attributes with the same values for all elementsof S. Conversely, variability is defined as an assumption true of only some elementsof S, or an attribute with different values for at least two elements of S. SCV analysiscan be applied with different implementation paradigms, which determine differentstrategies for implementing variability, for example, in object-oriented design, S isa collection of classes, C is the code common to all classes in S; this code isplaced in the base class, and V is the ‘uncommon’ code in S; this code is placedin the subclasses. In template meta-programming [Vel95], S is a set of classesimplementing the same operations but on different types, C is the template code,and V is the actual parameters of template.

Formal concept analysis (FCA) uses concept lattices [Sne96] for modellingrelationship between concept variabilities in a system. FCA is based on a relationI � O � A between a set of objects O and a set of attributes A. The triple C D (O, A,I) is called a formal context. For a set of objects X � O, the set of common attributesis defined as �.X/ D fa 2 Aj8o 2 X W .o; a/ 2 I g. Similarly, for a set of attributesY � A, the common objects are defined by �.Y / D fo 2 Oj8a 2 Y W .o; a/ 2 I g.A pair c D (X, Y), where X � O and Y � A is called a concept, if Y D ¢(X) andX D £(Y).

FCA allows distinguishing between dependent and independent variation pointsas well as to model system variants on different configuration levels.

Feature modelling (FM) has its origins in FODA [KCHC90] and since has beendeveloped by a number of different authors [Bat05, CHE05b, GFD98, RP03]. InFM, a feature model consists of Feature Diagrams and some additional information

9.3 Introduction into Feature Diagrams 145

such as a short description and motivation for each feature, constraints, dependencyrules, etc. Such a feature model can be described using Feature Diagrams (FDs),which are discussed in detail in Sect. 9.3.

Other feature variability modelling methods and techniques are also usedsuch as variability specification language (VSL) [Bec03], object-orientedvariability modelling using OCL [SRP03], Koalish [ASM04], Forfamel [Asi04],CONSUL/Pure::Variants [BPS04], COSVAM [DSNC04], orthogonal variabilitymodelling (OVM) [PBL05], ConIPF [HKWC06], ontology-based modelling[LKSC07] and formal variability modelling using computational-tree logic (CTL)[LBL08]. Our intention is to focus on feature models insights here.

9.3 Introduction into Feature Diagrams

Feature Diagrams (FDs) are a graphical language used for representing andmodelling variability at a higher abstraction level, usually at the early design stages,such as formulation of requirements for product line software designs. Below, wepresent basic definitions and syntax and semantics of conceptualized FDs.

9.3.1 Feature Definitions and Original Context of Use

From the perspective of software engineering, it is commonly accepted that adomain can be analysed and modelled at a higher abstraction level using feature-based approaches. Informally, a feature is a prominent characteristic of a system,entity or concept in a domain. Since there is no consensus in the softwareengineering literature on what a feature is, we deliver some definitions of the term.

A feature is:

1. End-user visible characteristic of a system or a distinguishable characteristic ofa concept that is relevant to some stakeholder [KCHC90]

2. A logic unit of behaviour that is specified by a set of functional and qualityrequirements [Bos00]

3. Qualitative property of a concept [CE01]4. A functional requirement, a reusable product line (PL) requirement or a charac-

teristic that is provided by one or more members of a software PL [WG04]

9.3.2 Feature Model

Feature modelling is the activity of modelling the common and the variableproperties of concepts and their interdependencies in a domain and organizing them


into a coherent model referred to as a feature model [CE01]. The intention of afeature model is to represent and model a domain or its part using the featureconcept. Specifically, this activity can be seen as a part of the domain analysisprocess, for example, as it is described by FODA [KCHC90]. The advantage offeature models is the provision of an abstract, implementation-independent, conciseand explicit representation of the variability present in the software [Sip05].

A feature model represents the common and variable features of conceptinstances (sub-features) and the dependencies and relationships between the variablefeatures. The model delivers the intention (usually implicitly) of a concept, whereasthe set of instances it describes is referred to as an extension, which narrows themeaning and scope of the concept. This extension is often referred to as a hierarchyof features with variability [CKK06]. The primary purpose of a hierarchy is torepresent a potentially large number of features into multiple levels of increasingdetail. Variability defines what the allowed combinations of features are. To organizea hierarchy as an allowed combination of features, the identification of featuretypes is essential. Feature types are the inherent part of the feature model. Theyare discussed in the next section.

9.3.3 Feature Types

There are three basic types of features: mandatory, optional and alternative.Mandatory features allow us to express common aspects of the concept (usuallythey are referred to as commonality [CHW98]), whereas optional and alternativefeatures allow us to express variability. All basic features may appear either as asolitary feature or in groups. If all mandatory features in the group are derivatesfrom the same father in the parent-child relationship, we can speak about theAND relationship among those features (see also Table 9.1). An optional featureis the one which may be included or not if its father is included in the featuremodel. Alternative features, when they appear in groups as derivates from thesame father, may have the following relationships: OR, XOR, CASE, etc. TheXOR relationship also can be treated as a constraint (see Table 9.1). Usually thisrelationship appears as a constraint when features are derived from different parents.More advanced subtypes of alternative features are group constraints, attributes,cloning and additional constraints [CKK06].

A sub-feature may be mandatory, alternative, or optional with respect to onlythe applications, which also enclose its parent feature. If the parent of the featureis not included in the description of the system, its direct and indirect sub-featuresare unreachable. Reachable mandatory features must be always included in everysystem instance, while an optional feature may be included or not, and an alternativefeature replaces another feature when included. In FODA, selected optional andalternative features are highlighted in the FD of a specific system with the boxesaround the name of the selected feature. External composition rules describeadditional dependencies (e.g. constraints) between the features within of an FD.


Table 9.1 Feature Diagram language in FODA [KCHC90]

Feature type Definition Graphical notation

Mandatory If A then B A A

B C D

If A then B and C

Optional If A then B or none A A

B C D

If A then C or D or none

Alternative (casedecomposition)

If A then case of (B, C, D) A

C DB

Alternative (XORdecomposition)

If A then A

B C

(B but not C)or(C but not B)

9.3.4 Feature Diagram Definition and Variants of Notation

FDs are means for the modelling and management of variability, that is, the com-monalities and differences in the applications in terms of requirements, architecture,components and test artefacts [Kru02, PBL05]. Feature Diagrams were introducedby Kang and his colleagues as a part of the FODA method back in 1990 [KCHC90].In FODA, a Feature Diagram is the tree-like or directed acyclic graph (DAG) thatconsists of a set of nodes, a set of directed edges (arcs) and a set of edge decorations(see Table 9.1). The root node represents the top level feature (i.e. concept, entity,system or domain per se). The intermediate nodes represent compound featuresand leaves represent atomic features that are non-decomposable to smaller onesin a given context. The edges are used to progressively decompose a compoundfeature into more detailed features. Edges of the graph also denote relationshipsor dependencies between features, such as decomposition edges (or consists of).FODA further distinguishes AND decomposition and XOR decomposition. Addi-tionally, there can be textual constraints between non-sibling features: <requires>indicates that the former feature cannot be presented if the latter is not, and <mutex>

(abbreviation for ‘mutually exclusive with’) indicates that two features cannot bepresented simultaneously.

Additional variability mechanisms can be expressed in propositional logic[ZZM04], first-order predicate logic [Man02] or fuzzy logic [RP03] and may cutacross the feature hierarchy. Informal information such as priorities or relationsbetween variable features can be captured by annotations. We examine differentvariants of the FD notation used by several researchers in more detail.


Table 9.2 OFD FORM Feature Diagram language (According to [KKLC98])


Mandatory If A then B A

B C D

AIf A then B and C

Optional If A then B or none A

B C D

AIf A then C or D or none

Alternative (casedecomposition)

If A then case of (B, C, D) A

CB D


If A thenA

B C


Alternative (ORdecomposition)

If A then any of (B, C, D)

B C

Or1 Or2 Or3 Or4

A

D

In the feature-oriented reuse method (FORM), which is an extension of FODA,Kang et al. [KKLC98] introduced rectangular boxes for representing features andadded OR decomposition to allow the selection of any feature(s) from a group offeature nodes (see Table 9.2).

In the RSEB feature modelling method, Griss et al. [GFD98] preserved thestandard graph-type model without boxes for representing feature nodes. Newgraphical elements were introduced for representing OR and XOR decomposition:for OR relation, a full diamond is used to mark a parent node, and for XOR relation –an empty diamond is used. Also a new relation element, called ‘requires’, wasintroduced to denote that a certain feature requires another feature to be included.The graphical notation of RSEB Feature Diagram (RFD) language is presented inTable 9.3.

VBFD basically uses the same elements as RFD; however, the graphical notationis different: boxes are used to denote feature nodes, and arrows are used instead ofdiamonds for OR and XOR decomposition relations (see Table 9.4).

In the Generative Programming Feature Tree (GPFT) notation [CE01], themandatory relation has a full circle over the child feature. For OR and XORdecomposition relations, the parent node has a decoration arc that connects all childbranches. The notation is detailed in Table 9.5.


Table 9.3 Feature Diagram language in the RSEB method [GFD98]


Mandatory If A then B A A

B C D

If A then B and C

Optional If A then B or none AA

B C D


Alternative (OR decomposition) If A then

B C

A

D

any of (B, C, D)

Alternative (XOR decomposition) If A then

B C

A(B but not C)or(C but not B)

Requires K requires FF

requiresK

Table 9.4 VBFD Feature Diagram language [GBS01]


Mandatory If A then B A

B C D

AIf A then B and C


B C D


Alternative (ORdecomposition)

If A then any of (B, C, D)

B C D

A


If A then(B but not C)or(C but not B)

B

A

C

Requires K requires FF K

requires


Table 9.5 Feature Diagram notation in GPFT [CE01]


Mandatory If A then BA

B C D

AIf A then B and C


B C D

If A then C or Dor none

Alternative (OR decomposition) If A then any ofA

B C D

(B, C, D)

Alternative (XOR decomposition) If A then A

B C


9.3.5 Basic Set of Abstractions in Standard Feature Diagram

As a result of active research in the field of Feature Diagram notations and theiruse, currently there are many similar notations with different syntactic and semanticdiscrepancies. For more details, see, for example, [BHS05, DS06, SHT06, Sip05,THSC06]. In the context of this book, we use the notation of Feature Diagrams thatis shown in Table 9.6. The presented notation is a result of some adaptation of works[CE01, DS06, SHT06] as well as our own contribution (case of relation, a functionrelation between feature values and contextualization of FDs).

In the following section, we discuss the extensions of Feature Diagrams formodelling variability in specific domains of application or managing specificproduct requirements.

9.4 Extensions of Feature Diagrams

9.4.1 Ontology-Based Extension

Capturing design knowledge and its modelling are crucial issues for design supportand design knowledge management. With the further expansion of complexity,which is inspired by ever-growing technology capabilities, market demands, user

9.4 Extensions of Feature Diagrams 151

Table 9.6 Basic set of FD abstractions of feature models


Mandatory Feature B (C, D) is included ifits parent A is included

A

B C D

A

Optional Feature B (C, D) may beincluded if its parent A isincluded

A

B C D

A

Alternative (caseselection)

Exactly one feature has to beselected if its parent isselected

A A

B C CB D

Alternative (ORselection)

At least one feature has to beselected if its parent isselected

A A

B BC C D

Constraint<mutex>

Feature K excludes feature Fand vice versa K

xorF

Constraint<Require>

Feature K requires feature F requiresK F

requirements, new appliances (e.g. ambient intelligence, mobile computing), etc., itis not enough to rely on the domain content-based and feature-centric analysis inthe system development only.

The lack of explicit description of background knowledge of modelling raisesthe need for capturing design knowledge in a more formal, structural and organizedway, using a domain ontology. Gruber defines ontology as an ‘explicit specificationof a conceptualization’ [Gru94], though there are many other definitions (see,e.g. [Gua98]). Ontology of domain artefacts, in general, consists of systematicdefinitions of fundamental concepts and relationships which exist in the physicalworld related to target artefacts, and shows how to capture the artefacts. Ontologiesare especially useful when the context awareness should be introduced into adomain.

Context awareness is a very important feature in such appliances as ambientintelligence, e-learning systems, knowledge-based information systems and manyothers because this kind of information hides (if it is not yet revealed) or bringsmore complex relationships of features that can be treated as knowledge (if thisinformation is already revealed). In a broader sense, context analysis is a matter ofcognitive science. Software engineering approaches (such as the FODA method for


Table 9.7 Feature types, ontology and constraints for feature model representation

Feature type Definition, formalism and semantics of relationshipsGraphical notation(syntax)

Concept andits context

Concept is represented by the root with the explicitlystated context on the left at the same level;context is seen as the highest mandatory featurewith variants

<Concept><Context>

Ontology A compound of atomic features and theirrelationships; ontology expresses the domainknowledge in some way

domain analysis) do not also neglect the importance of the context; however, theseapproaches deal with the context in a narrow sense (usually statically as, e.g. FODAthat neglects possible changes in the context).

The structure and meaning of a concrete FD is dependable on the context and thelatter on the goal an FD is pertaining. By changing such attributes as <goal> and<context>, we alter the shape and, perhaps, semantics of the FD (e.g. feature types).Having in mind requirements of the product line, the context is inevitably changingin architectural design. This property further leads to treating attributes <goal> and<context> as generic categories (see Table 9.7) meaning that each have some pre-specified concrete value taken from a prescribed space. When representing the sameinitial concept, the use of <context> results in the construction of a set of the relatedFDs. The latter corresponds to the product line approach, in which the related groupsof features model product families.

The context-dependent attributes of FDs are the explicitly stated generic context,a set of related FDs, the extended scope of variability, the richer domain ontologyand an architectural description of a domain with ontology-based variability inmind. The essential attribute of context-enriched FDs is domain ontology (seeTable 9.7). In general, domain ontology can be expressed in a variety of waysdepending on the domain, feature properties and design goal (context). Sometimes,it is enough to specify relationships among features – leaves using the simplestconstraint relationships such as ‘feature A <requires> feature B’ or ‘A and B aremutual exclusive features’ (see Tables 9.5 and 9.6). If the features are of Booleantype, more complex relationships based on the propositional logic can be used.

9.4.2 Extension for Quality-Oriented Modelling

Software quality is defined as the degree to which software possesses a desiredcombination of attributes (IEEE Std. 1061–1992) [IEEE92]. A quality attributecan be defined as a property of a software system that has been formulated asa requirement by a stakeholder. Assessment of the system’s quality attributes atthe modelling stage is essential to justify design decisions early. By selecting theappropriate design decisions before starting the product design and implementation


phase, it is possible to reduce development costs and production time. In somedomains, such as embedded system design, satisfaction quality attributes are evenmore important than functional requirements. However, most of existing approachesdo not integrate quality variability as a part of the systematic variability managementof software product lines [MMR06].

In a software product line, different instances of a system may have differentquality, or quality can be optional for some product instance. Furthermore, there canbe relationships between functionality features and quality features, so the selectionof a functional feature can influence or impact system’s quality [ESB07]. Qualityprediction and assessment for product lines is very important because it can directlyinfluence the selection of other features of product instances [ZJY03]. Niemela[Nie05] defined three different types of quality attribute variability:

1. Optionality of a quality attribute, when quality requirements are valid only forsome members of software product family

2. Levels of a quality attribute, when quantitative quality requirements can beassigned to system instances

3. Influence of a functional variability on quality, when there is an indirect effect offunctional features on the quality requirements

Variability representation requires the use of diagrams or models to captureall the information. To implement such models, usually, the existing modellingapproaches are extended or used in conjunction with other modelling approaches.Firesmith [Fir03] formulates the requirements for developing quality modellingapproaches. The quality model must provide:

1. A taxonomy of its component quality factors and sub-factors (i.e. aspects,attributes or characteristics)

2. Specific quality criteria (descriptions) and metrics that can be used to unambigu-ously specify the associated aspect of quality or to determine software qualityduring testing

In general, feature models can be used to capture and model quality attributesbecause the feature definition also covers non-functional properties such as quality.Quality models are defined similarly to feature models as sets of characteristicsand relationships between them; so, in the most cases, quality models can berepresented as hierarchies (taxonomies, ontologies) of quality attributes [Fir03].However, feature modelling approaches do not give any guidance for specifyingthe quality attribute in a verifiable manner.

The extension of Feature Diagrams with an additional <prefer> constraintis useful for modelling preference of selection of a feature based on qualityconsiderations. In a software product line, quality assessment is especially importantbecause an error or an inadequate design decision can be spread into a lot ofproducts. Moreover, in a product line, different members of the line may requiredifferent quality attributes. Therefore, a method for quality-aware software withinproduct line engineering that takes into account the variability of quality aspects andfacilitates quality assessment can be realized.


We consider an agent (a software designer, a decision-maker), who tries to selectfeatures from a set of alternatives described using a feature tree. The features canbe compared if some kind of order can be implied between them: either a directpreference (p is preferred to q) or indirect preference induced from a measurementand its associated scale (e.g. p is longer, bigger, more reliable than q). Let S be the setof all software products in a product family expressed through a set of alternatives,that is, various types of features. To define preference logic (following [KT05]) forquality modelling, we define three types of preferences of p over q as follows:

1. Weak preference relation � on S.2. Strong preference relation > on S.3. Indifference relation D on S.

Weak preference relation is a binary relation on S such that p � q, if and only if p isat least as preferable as q.

Strong preference relation is a binary relation on S such that p > q, if and only if pis always more preferable as q.

Indifference relation is a binary relation on S such that p D q, if and only if p (furtheriff ) is indifferent to q (in all cases p, q 2 S).

Given a set of preference relations R between the elements of S, we can definemany different orderings of S leading to the multidimensional choice problem.For two preference criteria, for example, we can define the following preferencerelations:

The p(c1,c2) is strongly preferred over the q(c1,c2) iff the p(c1) is strongly preferredover the q(c1) and the p(c2) is strongly preferred over the q(c2), where c1, c2 arethe preference criteria.

The p(c1,c2) is weakly preferred over the q(c1,c2) iff the p(c1) is weakly preferredover the q(c1) and the p(c2) is weakly preferred over the q(c2).

For the multi-criteria quality modelling case we can introduce the followingpreference generalization. Let C be the set of all quality criteria for S. Then:

The p is strongly preferred over q iff p is strongly preferred over all q(ci), whereci 2 C .

The p is weakly preferred over q iff p is weakly preferred or indifferent over q(ci).

In practice, first a preference table is constructed, where the results of theevaluation of each quality characteristic against each functional feature is presenteddenoting the existing preference relationship (if such exists). Then, a combinedfeature-quality model is constructed, where both feature hierarchy and quality as-pect hierarchy are represented as branched of the model’s topmost node representingthe modelled system itself. Finally, quality and feature hierarchy nodes are relatedusing the preference relations (a dashed line with the <prefer> label leading from


Table 9.8 Complexity of cos function implementation methods

Implementation methodWorst caseprecision

Time,ms

Voltage drop,mV Data memory, B

Taylor series n�6.639 688n � 57 32n � 7 0LUT without interpolation m�0.778 560 280 8mLUT with linear interpolation m�1.367 1,150 580 8m

Table 9.9 Preferences of quality characteristics

Characteristic Taylor series LUT LUT with interpolation

Accuracy (A)

Speed (S)

Power consumption (P)

Memory usage (M)

a quality aspect toward a system’s functional feature, the selection thereof wouldincrease overall system’s quality).

Example. Suppose we have a set of components (programs, functions) with asimilar functionality P. We also have a set of selection criteria G that correspond tothe quality characteristics of components. Each criterion gj is a computable functionover component pi W gj .pi / ! R; gj 2 G; pi 2 P . The aim here is to model apreferable selection of a designer in terms of earlier selected design criterion.

For example, we have different implementations of cosine function: cos frommath library, approximate cos based on Taylor series, cos based on look-up table(LUT) and cos based on LUT with linear interpolation. The set of characteristicsthat can be measured for each of these components is faccuracy, speed, powerconsumption, memoryg.

For the application of trigonometric functions in real-time embedded systems,typically both the numerical precision and the resource demands are relevant.Depending upon the selected design criterion, we should be able to select a preferredimplementation of the cos function. Suppose, we have obtained the experimentallyand analytically established complexities of cosine function implementation meth-ods (see Table 9.8).

Different quality characteristic trade-offs based on obtained results are summa-rized in Table 9.9. The preferences are evaluated using preference logic.

The results of preference modelling are represented as a Feature Diagram inFig. 9.1. From this diagram, the designer can learn that if high speed and low powerconsumption of the implementation is a top priority, then he/she should select LUTwithout interpolation, whereas if high accuracy and low memory usage is the issue,then the Taylor-series-based implementation is the most preferred one.


Implementationmethod

Look-Up TableTaylor series

withoutinterpolation

withinterpolation

Cosine functionimplementation

Characteristics

MemorySpeed

Power Accuracy

<prefer>

Fig. 9.1 Feature Diagram of cos function implementations and their quality characteristics

9.4.3 Feature Diagram Extension for Variation SequenceModelling

A key aspect of variability management in software product families is the explicitrepresentation of the variability. Sinnema et al. [SVD06] have formulated thefollowing requirements for variability modelling techniques:

1. Variation points should be represented uniformly as first class entities in all levelsof abstraction.

2. Variability should be represented hierarchically.3. Variability dependencies should be represented explicitly.4. Interactions between dependencies should be represented explicitly.

Having these requirements in mind, we consider the following task: given aprogramming task domain D, a program model Mp (Mp 2 D), a family of program

models Mm

�Mm D S

P

Mp; Mm 2 D

�, commonalities C of Mp (C 2 D), variability

V of Mm (V 2 D) and a set of dependencies Fd describing relations R betweenmembers of variability set V. We need to map V onto Mm under given constraintsimposed by Fm. We use the modal logic [Che95], which is a system of the formallogic that deals with modalities. The modal logic extends the propositional logicwith two unary modal operators: � for necessarily (must) and ˙ for possibly (can).These operators are defined as follows: if A is a formula, so are �A and ˙A. �Ais usually interpreted as ‘it is necessarily true that A’, and ˙A as ‘it is possibly truethat A’.


We introduce these elements of the variation sequence modelling (VSM):

1. Variant – design alternative that represents a specific instance of variability in aprogram model Mp

2. Variation point – a location in the model Mp where variants arise3. Variation sequence – a grouping of dependable variation points that cross-cut a

family of program models Mm [DS09]4. Variability dependency – relationship and interaction between variants, variation

points and variation sequences5. Variability configuration – a mapping from variation sequences to a program

family model Mm

The main concept that represents variability at the implementation level is thevariation point. A variation point is a spot in a software asset where variation willoccur. According to Becker [Bec03], a variation point (a) localizes a variation in asoftware asset, (b) abstracts from the specific details of variant implementation and(c) supports its specialization to a concrete variant in an appropriate way at a laterstage.

Based on this conception, there can be two types of variation points [GBS01]:

1. Open variation point allows for new variants associated with it.2. Closed variation point does not allow adding new variants.

Variation points are to be obtained in advance through applying feature orvariability-oriented domain analysis and modelling (e.g. FODA [KCHC90], SCV[CHW98]). How many variation points are to be introduced in the program familymodel is a matter of requirements specification performed by a domain analyst.But the scope always can be widened or narrowed depending on the particularrequirements imposed by the needs of a product line. Any variation point inducesa semantic interaction, that is, changes in variants at a variation point, which mayhave consequences to the semantics at the other variation points.

First, we describe variability for a general case using the notation and taxonomyproposed in [JB04]. Variability can be described by a set of variation points VP, aset of variants for a specific variation point V, a power set (the set of subsets) of allvariants: P D } .VP � V /, and variability dependencies K W VP ! V that bindvariation point and variant in a formal and system-independent way.

A variation sequence is a novel concept that we use to describe complex variabili-ties characterized by a hierarchical structure of variation points with many differentnested variants. The introduction of variation sequences is motivated by the 2ndrequirement to variability modelling [SVD06]. A similar concept to a variation se-quence can be found in aspect-oriented programming [MK03], where cross-cuttingconcerns are aspects of a program which affect (cross-cut) other concerns. Theseconcerns often cannot be cleanly decomposed from the rest of the system in both thedesign and implementation, and result in either scattering or tangling of the program.

A variation sequence (VS) can be defined as a single aspect of a software asset’svariability that cross-cuts a component (system) and reveals itself through one ormore variation points. We can define VS as a set of all variation sequences. Variation


Table 9.10 Variation point variability dependencies (Adapted from [JB04] and[BDSC11])

Dependency type Relation type Formal description in modal logicD1. Dependencies between

variation points VPxand VPy

Requires VPx ! �VPy:VPx ! :˙VPy

Excludes VPx ! :˙VPy:VPx ! �VPy

D2. Dependencies betweenvariation point VPx andvariant Vyn

Requires VPx ! �(VPy , Vyn):VPx ! :˙ (VPy , Vyn)

Excludes VPx ! :˙ (VPy , Vyn):VPx ! �(VPy , Vyn)

D3. Dependencies betweenvariant Vxn andvariation point VPy

Requires (VPx ,Vxn) ! �VPy:(VPx ,Vxn) ! :˙Vyn

Excludes (VPx ,Vxn) ! :˙VPy:(VPx ,Vxn) ! �VPy

D4. Dependencies betweenvariants Vxn and Vym

Requires (VPx ,Vxn) ! �(VPy ,Vym):(VPx ,Vxn) ! :˙ (VPy ,Vym)

Excludes (VPx ,Vxn) ! :˙ (VPy ,Vym):(VPx ,Vxn) ! �(VPy ,Vym)

sequence reveals itself in a set of dependable variation points VP. If two or morevariation sequences intersect, then we have a composite variation point with manyvariations that is characterized by complicated variability. A variation point canbelong to one or more variation sequences. If a variation point belongs to two ormore variation sequences, then we have a composite variation point.

Variability dependency is a restriction on the variant selection of one or morevariation points [JB04]. Dependencies are imposed by the application domain (e.g.customer requirements) or the environment (e.g. target platform). According to[BCKC04], there are three main dependencies between variants and/or variationpoint: (1) dependency between variant and variation point, (2) dependency betweenvariant and variant and (3) dependency between variation point and variation point.

Simple dependencies specify the restriction on the binding of one or two variationpoints in terms of relations require and exclude, for example, ‘the binding of variantA1 to variation point A excludes the binding of variant B1 to variation point B’[SDNC04]. However, in large and complex product families, dependencies usuallyare more complex and typically affect a large number of variation points. Jaring andBosch [JB04] have proposed taxonomy of variability dependences. Their taxonomyincludes four types of dependencies where each type contains four subtypes. Thesesubtypes can be classified into two groups according to their relation type (requiresor excludes). Variation point variability dependencies are described formally andsummarized in Table 9.10.

The Feature Diagrams are extended with four additional types of dependenciesbetween variation sequence(s) and variation point(s) [BDSC11]. The dependenciesare described formally in Table 9.11.


Table 9.11 Dependencies of variation sequences and variation points (Adapted from [BDSC11])

Dependency type Relation typeFormal description in modallogic

D5. Dependencies between variation sequenceSu and variation points VPx and VPy

Requires Su ! �(VPx,VPy):Su ! :˙ (VPx,VPy)

Excludes Su ! :˙ (VPx,VPy):Su ! �(VPx,VPy)

D6. Dependencies between variation sequenceSu and Sw – variation point VPx

Requires Su ! �(Sw, VPx):Su ! :˙ (Sw, VPx)

Excludes Su ! :˙ (Sw, VPx):Su ! �(Sw, VPx)

D7. Dependencies between variationsequences Su – Sw and variation point VPx

Requires (Su, Sw) ! �VPx:(Su, Sw) ! :˙VPx

Excludes (Su, Sw) ! :˙VPx:(Su, Sw) ! �VPx

D8. Dependencies between variation sequenceSu – variation point VPx and variationsequence Sw – variation point VPy

Requires (Su, VPx) ! �(Sw, VPy):(Su, VPx) ! :˙ (Sw, VPy)

Excludes (Su, VPx) ! :˙ (Sw, VPy):(Su, VPx) ! �(Sw, VPy)

Example. For demonstrating variability modelling using the VSM and variabilityimplementation using meta-programming, we consider a family of software com-ponents implementing simple arithmetic expressions [BDSC11]. Each arithmeticexpression can be represented as a binary tree, where nodes are operations andleaves are variables. For simplicity, we only analyse binary trees of length 3, whichrepresent arithmetic expressions with three operations and four variables.

Consider (1) arithmetic expressions composed of a sequence of four variablesV D (x, y, z, u), (2) two operations from a set of operations OP D fC, *g and (3) twotypes, where each variable and function having a type from the set T D fshort, intg.

The syntax tree for such expressions is given in Fig. 9.2a and representativeinstances of a function family in Fig. 9.2b.

Suppose that variables are commonalities, and types and operations are variabil-ity, that is, variables are fixed, but types and operations can be selected freely. Sucha family of the arithmetic expression functions can be described formally by 3-tupleF D (C, S, R), where C is function commonality that is invariant across the entirefamily of functions, variation sequence S is a set of function variation sequencesthat group dependable variation points VP and R are variability dependencies thatbind function variation points.

Here, we consider eight function variation points:

VP D fvp1, vp2, vp3, vp4, vp5, vp6, vp7, vp8g,where the variation point vp1 models a type of the return value; variation pointsvp2, vp3, vp4, and vp5 model a type of variables; and variation points vp6,vp7, and vp8 model operations.


V1 V2 V3 V4

OP1

OP2 OP3

int func (int x, int y, int z, int u) { return (x + y) + (z + u);

}

short func (short x, short y, short x, short u) {

return (x * y) + (z * u); }

a

b

Fig. 9.2 Expression syntaxtree (EST) (a) andrepresentative instances of thefunction family (b)

A composition of function commonality C and function variation points VP canbe represented informally in CCC programming language with variation points VPembedded within source code (shown between ‘<’ and ‘>’ symbols):

<vp1> func (<vp2> x, <vp3> y, <vp4> z, <vp5> u)freturn (x <vp6> y) <vp7> (z <vp8> u);gWe assume that all variables and the function return value always have the same

type. Therefore, vp1 : : :vp5 can be grouped into the same variation sequence:

s1 D (vp1, vp2, vp3, vp4, vp5).

If all model operations are independent, when we have three different variationsequences, each containing only one variation point:

s2 D (vp6),s3 D (vp7),s4 D (vp8).

If operations at the second level of the expression syntax tree (EST) must bedependable, there we have another variation sequence:

s5 D (vp6, vp8).

If all operations in the expression must be the same, then we have the variationsequence:s6 D (vp6, vp7, vp8).


We have a set of six variation sequences in an arithmetic expression family:

S D fs1, s2, s3, s4, s5, s6g,where

s1 !� (vp1 \ vp2 \ vp3 \ vp4 \ vp5);s2 !� (vp6);s3 !� (vp7);s4 !� (vp8);s5 !� (vp6 \ vp8);s6 !� (vp6 \ vp7 \ vp8).

Variation sequence s1 is orthogonal to s2 : : : s6, whereas variation se-quences s2 : : : s6 are dependable. Some dependencies between variation pointsand variation sequences in an arithmetic function family are

R D fr1, r2, r3, r4, r5, r6, r7g,where

r1 :D s1 ! � (vp1 \ vp2 \ vp3 \ vp4 \ vp5);

// function type and variable types used in the expression must be the same.

r2 :D (s2, s3, s4) ! :˙ (s6), i.e.(vp6, vp7, vp8) ! :˙(vp6 \ vp7 \ vp8);

// all operations used in the expression cannot be the same.

r3 :D s5 ! :˙ s6, i.e.(vp6 , vp8) ! :˙�( (vp6 \ vp7 \ vp8));

// operations at the 2nd level cannot be the same.

r4 :D (s2, s3, s4) ! � (vp6, vp7, vp8) , i.e.(vp6, vp7, vp8) !� (vp6, vp7, vp8);

// all operations used in the expression must be different.

r5 :D s6 !� (vp6 \ vp7 \ vp8);

// all operations used in the expression must be the same.

r6 :D s2 ! � s4, i.e. (vp6) ! � (vp8);

// operations at the 2nd level of the EST must be the same.

r7 :D s3 ! :˙ (s2, s4);

// operation used at the top level cannot be the same as at the 2nd level.

The above description of an arithmetic function family variability is neithercomplete nor exhausting, but rather shows a part of function variation points andits variability, for example, a function can have more variation points, such as a


Fig. 9.3 Specification of an arithmetic function family using Open PROMOL meta-language

function name. We have a set of configurations in the function family, which arebounded by operational constraints:K D fk1, k2, k3g,

where

k1 ! � (s1 \ s2 \ s3 \ s4),k2 ! � (s1 \ s2 \ s4),k3 ! � (s1 \ s6).

Each configuration models a family of programs and can be implemented usinga meta-program. In meta-programming terms, variation sequence models a meta-parameter, variation point models a placeholder for the meta-parameter, and variantmodels a value of the meta-parameter. The entire set of configurations (meta-configuration) can be implemented by a meta-meta-program only.

The implementation of variability configuration k2 as a meta-program satisfyingvariability dependenciesr1 and r6 is given in Fig. 9.3. The meta-program is writtenin Open PROMOL meta-language. This arithmetic function family has 8 variationpoints and 2 variation sequences associated with each meta-parameter. The variationpoints are locations where meta-language functions for target code modificationare inserted: @sub function returns the value of the meta-parameter, and @casefunction selectively inserts CCC language terminals depending upon the meta-parameter value.

The meta-program encapsulates a family of functions to calculate sum, product,sum-of-product and product-of-sum arithmetic expressions. Any of the membersof the function family can be generated on demand upon selection of the meta-parameter values (8 different function instances can be generated from a meta-program presented in Fig. 9.3).

For more details demonstrating variability modelling using the VSM and vari-ability implementation using meta-programming, see [BDSC11]. We also recom-mend considering VSM as a separate research task, where the formal specificationis based on using graph colouring and modal logic and the implementation phase isbased on using meta-programming.


Table 9.12 Extension of Feature Diagram with feature grouping


Mandatory Feature B (C, D) isincluded if its parentA is included

A

[1..1] [1..1] [1..1]

A

B C D

Optional Feature B (C, D) may beincluded if its parentA is included

A A

[0..1] [0..1] [0..1]

B C D

Alternative (caseselection)

Exactly one feature has tobe selected if itsparent is selected

A A

<0..2> <0..3>

B BC C D

Alternative (ORselection)

At least one feature has tobe selected if itsparent is selected

A A

<1..2> <1..3>

B BC C D

A

Key:

Solitary feature with feature cardinality [1..1]

Solitary feature with feature cardinality [0..1]

Solitary feature with feature cardinality [n..m]

Feature group withgroup cardinality <n-m>(or <1-1> if no cardinalityexplicitly stated)

A

A

B C

<n-m>

<n-m>

Fig. 9.4 Cardinality-based extension of Feature Diagrams (FDs) in [CHE05a, CHE05b]

9.4.4 Other Known Extensions of Feature Diagram Notation

Riebisch et al. [RBSC02] proposed using grouping in Feature Diagrams. Groupedfeatures are represented with annotations, for example, [0..1] means that a featurecan be either selected or not. Grouping [0..0] means that the feature is not selected.Grouping [1..1] means that the feature must be selected. The syntax of this extensionis given in Table 9.12.

Czarnecki et al. [CHE05a] defined a new FD language to account for stagedconfiguration. The novelty of the language is feature cardinality (the number oftimes a feature can be repeated in a product) in addition to the more usual (group)cardinality (see Fig. 9.4).

An abstract syntax of the Feature Diagram consists of nodes which can be eitherfeature nodes or grouping nodes. A feature node may have a set of zero or more


Car

Carbody

TransmissionEnginePower

EnginePulls

TrailerAir

Conditioning

AutomaticManual ElectricGasoline

0.10.2

0.20.40.20.8

Fig. 9.5 Feature Diagram of a simple car with feature weights (Adapted from [CE01] and [RP03])

sub-nodes via the sub-feature relationship, which in itself has feature cardinality.Solitary sub-features from the concrete syntax are thus represented in the abstractsyntax as a node with an <is-sub-feature-of> link. A grouping node, on the otherhand, has at least one or more sub-feature nodes in its feature group.

Furthermore, a new semantics is proposed, where the full shape of the unorderedtree is important, including repetition and decomposable features. The semanticsis defined in a 4-stage process, where FDs are translated in turn into an extendedabstract syntax, a context-free grammar and algebra.

Benavides et al. [BTR05] propose to use constraint programming toreason on feature models. They extend the basic FD language with extra-functional features (a relation between one or more attributes of a feature, e.g.latency/availability D 50), attributes and relations between elements of fuzzylogic. When developing software product line, generic FDs are annotated witha priority for each variable feature (see an example in Fig. 9.5). The meaning canbe as follows: components realizing the features may already exist or should bedeveloped. The decision of which components to develop first or of which shouldbe developed because of their foreseen importance/usage (within a specific project,for a given user’s profile, etc.) may be derived from the weighted generic featuremodel, partially denoted as ‘fuzzy priorities’. In comparison to rigid priorities,which have a fixed value, decisions based on priorities contained within specificranges promotes constraint-based reasoning for interacting and interfering features.Domain knowledge and the Feature Diagrams with connections between thefeatures and feature ranges allow the building of generators for the automaticgeneration of systems matching a specific user’s profile needs.

A key advantage of using weights in the feature models in a product line contextis the possibility of using the feedback to tune and update the weights to satisfycurrent business needs.

In the extension of FD languages with Boolean logic proposed by Czarnecki andWasovski [CW07], a feature model represents a set of configurations, each being aset of features selected from a feature model according to its semantics. The set ofconfigurations represented by a feature model can be described by a propositional

9.6 Exercise Questions 165

formula defined over a set of Boolean variables, where each variable correspondsto a feature. The propositional formula can be constructed as a conjunction of (1)implications from all sub-nodes to their parents, (2) additional implications fromparents to all their mandatory features, (3) implications from parents to groups and(4) any additional constraints represented as propositional formulas.

Extension of FDs with a propositional logic also has been studied by Batory[Bat05] and Zhang et al. [ZZM04].

9.5 Summary

A key aspect of product line engineering is the explicit representation and mod-elling of variability in software families [WL99]. Current variability managementtechniques are based on the separation of commonalties and variabilities andlocalization of code variants in variation points. Variability is modelled throughdependencies between different system features (domain variation points) andvariants. A common notation for variability modelling in product line design is aFeature Diagram.

Feature Diagrams have been under extensive research for two decades; till now,however, the notation has not been standardized yet, though there are initiativeson that activity. An overwhelming majority of researchers are using a certainsubset (core) of Feature Diagram abstractions. For solving specific product linedesign and variability management problems in different areas of application,several researchers propose different extensions to Feature Diagram language,which significantly enhance the expressive power of the language and open the wayfor design automation and integration with other design methodologies. However,these extensions have not been accepted for the common use by the researchcommunity, yet.

9.6 Exercise Questions

9.1. Clarify the terms: domain, domain commonality, domain variability anddomain scope using (a) informal definition of the terms, (b) formal definitionof the terms and (c) testing the terms viability with simple examples ofillustrative domains or domains of your interest.

9.2. Clarify the term variability modelling and give a definition and formulateaims of the activity in general and in your particular domain.

9.3. Identify and specify the tasks of this activity for your research.9.4. Review the basic approaches to support variability modelling using the cited

references or other references.


9.5. Outline variability management research using additional sources. Enumeratethe reasons why domain variability is so important in modelling product linesor program families in general and in meta-programming field in a particular.

9.6. Using additional sources, compare four major variability managementmethodologies: feature modelling, scope-commonalty-variability (SCV)analysis [CHW98], COVAMOF [SDNC04] and formal concept analysis(FCA) [Sne96].

9.7. Perform a comparative study of feature-based models expressed throughFeature Diagrams focusing on (a) terminological issues (feature types andrelationships, their types, etc.) and (b) syntactical discrepancies of thegraphical notation.

9.8. Discuss different forms to represent features connecting the discussion withtopics presented in Chap. 9.

9.9. Evaluate suitability of the feature representation form selected for yourresearch.

9.10. Identify a subset of Feature Diagrams as a graphical specification languagefor your research and motivate its selection.

9.11. Identify attributes to characterize merits and drawbacks of the feature modelsas compared to other representation forms.

9.12. Discuss the need for extension of the Feature Diagrams focusing on thefollowing aspects: (a) capabilities for context modelling, (b) quality-orientedmodelling and (c) variation sequence modelling.

9.13. Provide an extensive study and research on aspects (a), (b) and (c) of Exercise9.12.

9.14. Study the paper [BDSC11] and provide a more extensive research on thistopic.

References

[Asi04] Asikainen T (2004) Modelling methods for managing variability of configurablesoftware product families. Licentiate thesis of science in technology at HelsinkiUniversity of Technology

[ASM04] Asikainen T, Soininen T, Mannisto T (2004) A Koala-based approach for modellingand deploying configurable software product families. In: 5th Workshop on productfamily engineering (PFE-5), Sienna, 4–6 November. Springer, Berlin

[Bat05] Batory D (2005) Feature models, grammars, and propositional formulas. In: ObbinkH, Pohl K (eds) 9th international software product line conference (SPLC 2005),Rennes, 26–29 September 2005. LNCS, vol 3714. Springer, Berlin/Heidelberg,pp 7–20

[BCK+04] Buhne S, Chastek G, Kakola T, Knauber P, Northrop L, Thiel S (2004) Exploring thecontext of product line adoption. In: Proceedings of the product family engineeringworkshop PFE-5. Sienna, Italy, 4–6 November 2003. Springer, Berlin

[BDS+11] Burbaite R, Damasevicius R, Stuikys V, Bespalova K, Paskevicius P (2011) Productvariation modelling using feature diagrams and modal logic. In: Proceedings of the12th IEEE international symposium on computational intelligence and informatics,Budapest, Hungary, 21–22 November 2011, pp 74–77

References 167

[Bec03] Becker M (2003) Towards a general model of variability in product families. In: 1stworkshop on software variability management, Groningen, February 2003

[BHS05] Bontemps Y, Heymans P, Schobbens P-Y, Trigaux J-Ch (2005) Generic semantics offeature diagrams variants. In: Feature interaction workshop (FIW), Leicester, 28–30June 2005, pp 58–77

[Bos00] Bosch J (2000) Design and Use of software architectures, adopting and evolving aproduct-line approach. Addison-Wesley, Reading

[BPS04] Beuche D, Papajewski H, Schroder-Preikschat W (2004) Variability managementwith feature models. Sci Comput Program 53(3):333–352

[BS99] De Baud J-M, Schmid K (1999) A systematic approach to derive the scope ofsoftware product lines. In: Proceedings of the International Conference on SoftwareEngineering, ICSE, Los Angeles, 1CA, USA, May 16–22, 1999. ACM 1999,pp 34–43

[BTR05] Benavides D, Trinidad P, Ruiz-Cortes A (2005) Automated reasoning on featuremodels. In: Proceedings of the 17th international conference on advanced infor-mation systems engineering, CAiSE. Porto, 13–17 June 2005. LNCS, vol 3520.Springer, Berlin/Heidelberg, pp 491–503

[CE01] Czarnecki K, Eisenecker U (2001) Generative programming: methods, tools andapplications. Addison-Wesley, Boston

[CHE05a] Czarnecki K, Helsen S, Eisenecker U (2005) Staged configuration through special-ization and multi-level configuration of feature models. Softw Process Improv Pract10:143–169

[CHE05b] Czarnecki K, Helsen S, Eisenecker U (2005) Formalizing cardinality-based featuremodels and their specialization. Softw Process Improv Pract 10(1):7–29

[Che95] Chellas BF (1995) Modal logic: an introduction. Cambridge University Press,Cambridge

[CHW98] Coplien J, Hoffman D, Weiss D (1998) Commonality and variability in softwareengineering. IEEE Softw 15:37–45

[CKK06] Czarnecki K, Kim CHP, Kalleberg KT (2006) Feature models are views on ontolo-gies. In: Proceedings of the 10th international software product line conference,Baltimore, MD, 21–24 August 2006. IEEE Computer Society, Los Alamitos,pp 41–51

[CW07] Czarnecki K, Wasowski A (2007) Feature diagrams and logics: there and backagain. In: 11th international software product line conference, SPLC 2007, Kyoto,Japan, 10–14 September 2007, pp 23–34

[DS06] Djebbi O, Salinesi C (2006) Criteria for comparing requirements variabilitymodeling notations for product lines. In: CERE workshop at RE’06 conference,Minneapolis, 2006, pp 20–35

[DS09] Damasevicius R, Stuikys V (2009) Specification and generation of learning objectsequences for E-learning using sequence feature diagrams and metaprogrammingtechniques. In: Ninth IEEE international conference on advanced learning technolo-gies, Riga, Latvia, 2009, pp 572–576

[DSN+04] Deelstra S, Sinnema M, Nijhuis J, Bosch J (2004) COSVAM: a technique forassessing software variability in software product families. In: Proceedings of the20th international conference on software maintenance (ICSM 2004), Chicago,11–17 September 2004, pp 458–462

[ESB07] Etxeberria L, Sagardui G, Belategi L (2007) Modelling variation in qualityattributes. In: Proceedings of the first international workshop on variability ofsoftware-intensive systems VaMos 2007, Lero, 2007, pp 51–60

[Fir03] Firesmith D (2003) Using quality models to engineer quality requirements. J ObjTechnol 2(5):67–75

[GBS01] Van Gurp J, Bosch J, Svahnberg M (2001) On the notion of variability in softwareproduct lines. In: Working IEEE/IFIP conference on software architecture (WICSA2001), Amsterdam, 28–31 August 2001, pp 45–54


[GFD98] Griss L, Favaro J, D’Alessandro M (1998) Integrating feature modeling with theRSEB, Victoria, BC, Canada. In: Proceedings of the fifth international conferenceon software reuse. Victoria, BC, 2–5 June 1998. IEEE Computer Society Press, LosAlamitos, pp 76–85

[Gru94] Gruber T (1994) Toward principles for the design of ontologies used for knowledgesharing. IJHCS 43(5/6):907–928

[Gua98] Guarino N (1998) Formal ontology in information systems. In: Proceedings ofFOIS’98, Trento, Italy, 6–8 June 1998. Ios Press, Amsterdam, pp 3–15

[HKW+06] Hotz L, Krebs T, Wolter K, Nijhuis J, Deelstra S, Sinnema M, Macgregor J (2006)Configuration in industrial product families – the ConIPF methodology. Ios Press,Berlin

[IEEE92] IEEE Std. 1061–1992 (1992) Standard for a software quality metrics methodology.IEEE, New York

[Jar05] Jaring M (2005) Variability engineering as an integral part of the software productfamily development process. PhD thesis, University of Groningen

[JB04] Jaring M, Bosch J (2004) A taxonomy and hierarchy of variability dependenciesin software product family engineering. In: Proceedings of the 28th internationalcomputer software and applications conference (COMPSAC 2004), Hong Kong,27–30 September 2004, pp 356–361

[KCH+90] Kang K, Cohen S, Hess J, Novak W, Peterson S (1990) Feature-oriented domainanalysis (FODA) feasibility study. TR CMU/SEI-90-TR-21, Software EngineeringInstitute, Carnegie Mellon University, November 1990

[KKL+98] Kang KC, Kim S, Lee J, Kim K, Kim GJ, Shin E (1998) FORM: a feature–orientedreuse method with domain–specific reference architectures. Ann Softw Eng 5:143–168

[Kru02] Krueger C (2002) Variation management for software production lines. In: Proceed-ings of the 2nd international software product line conference. LNCS, vol 2379.ACM Press, San Diego, pp 37–48

[KT05] Kaci S, van der Torre LWN (2005) Algorithms for a nonmonotonic logic ofpreferences. In: Proceedings of the 8th European conference on symbolic andquantitative approaches to reasoning with uncertainty, ECSQARU 2005, Barcelona,Spain, 6–8 July 2005. LNCS, vol 3571. Springer, Heidelberg, pp 281–292

[LBL08] Liu J, Basu S, Lutz R (2008) Generating variation-point obligations for composi-tional model checking of software product lines. Technical report 08–04, ComputerScience, Iowa State University

[LKS+07] Lee S-B, Kim J-W, Song C-Y, Baik D-K (2007) An approach to analyzingcommonality and variability of features using ontology in a software product lineengineering. In: Proceedings of the 5th ACIS international conference on softwareengineering research, management & applications, Busan, 2007, pp 727–734

[Man02] Mannion M (2002) Using first-order logic for product line model validation. In:Chastek GJ (ed) Proceedings of the second international conference on softwareproduct lines, SPLC 2, San Diego, CA, USA, 19–22 August 2002. LNCS, vol 2379.Springer, Berlin, pp 176–187

[MK03] Masuhara H, Kiczales G (2003) Modeling cross-cutting in aspect-oriented mech-anisms. In: Cardelli L (ed) Proceedings of the 17th European conference onobject-oriented programming, ECOOP 2003, Darmstadt, Germany, 21–25 July2003. LNCS, vol 2743. Springer, Heidelberg, pp 2–28

[MMR06] Myllarniemi V, Mannisto T, Raatikainen M (2006) Quality attribute variabilitywithin a software product family architecture. In: Proceedings of the 2nd interna-tional conference on quality of software architecture QoSA, Vasteras, 2006

[Nie05] Niemela E (2005) Architecture centric software family engineering. Product familyengineering seminar. In: Tutorial in 5th working IEEE/IFIP conference on softwarearchitecture (WICSA), Pittsburgh, 2005

References 169

[PBL05] Pohl K, Bockle G, van der Linden F (2005) Software product line engineering.Springer, Berlin/Heidelberg/New York

[RBS+02] RiebischM, Bollert K, Streitferdt D, Philippow I (2002) Extending feature diagramswith UML multiplicities. In: 6th conference on integrated design & processtechnology (IDPT 2002), Pasadena, 2002, pp 2–7

[RP03] Robak S, Pieczynski A (2003) Employment of fuzzy logic in feature diagrams tomodel variability in software families. Trans SDPS J Integr Des Process Sci 7(3):79–94

[SB00] Svahnberg M, Bosch J (2000) Issues concerning variability in software productlines. In: van der Linden F (ed) Proceedings of the international workshop onsoftware architectures for product families, IW-SAPF-3, Las Palmas, Spain, 15–17March 2000. LNCS, vol 1951. Springer, Berlin/Heidelberg, pp 146–157

[SDN+04] Sinnema M, Deelstra S, Nijhuis J, Bosch J (2004) Covamof: a framework for mod-eling variability in software product families. In: Proceedings of 3rd internationalconference on software product lines, SPLC, Boston, 30 August–2 September 2004.LNCS, vol 3154. Springer, Berlin/Heidelberg, pp 197–213

[SHT06] Schobbens P-Y, Heymans P, Trigaux J-Ch (2006) Feature diagrams: a survey anda formal semantics. In: Proceedings of the 14th IEEE international requirementsengineering conference, Minneapolis/St.Paul, 11–15 September 2006. IEEE CSWashington, DC, pp 136–145

[Sip05] Sipka M (2005) Exploring the commonality in feature modeling notations. In:Bielikova M (ed) IIT.SRC 2005, Slovak University of Technology, 27 April 2005,pp 139–144

[Sne96] Snelting G (1996) Reengineering of configurations based on mathematical conceptanalysis. ACM Trans Softw Eng Methodol 5(2):146–189

[SRP03] Streitferdt D, Riebisch M, Philippow I (2003) Details of formalized relationsin feature models using OCL. In: Proceedings of the 10th IEEE internationalconference on engineering of computer-based systems (ECBS 2003), Huntsville,7–10 April 2003, pp 297–304

[SVD06] Sinnema M, Van Der Ven JS, Deelstra S (2006) Using variability modelingprinciples to capture architectural knowledge. ACM SIGSOFT Softw Eng Notes(SIGSOFT) 31(5):1–6

[THS+06] Trigaux J-C, Heymans P, Schobbens P-Y, Classen A (2006) Comparative semanticsof feature diagrams: FFD vs. vDFD. In: Fourth international workshop on compara-tive evaluation in requirements engineering, 2006. CERE’06, Minneapolis/St. Paul,September 2006, pp 36–47

[Vel95] Veldhuizen T (1995) Using CCC template metaprograms. CCC Rep 7(4):36–43[WG04] Webber DL, Gomaa H (2004) Modeling variability in software product lines with

the variation point model. Sci Comput Program (SCP) 53(3):305–331[WL99] Weiss DM, Lai CTR (1999) Software product-line engineering: a family based

software development process. Addison-Wesley, Reading[ZJY03] Zhang H, Jarzabek S, Yang B (2003) Quality prediction and assessment for product

lines. In: Proceedings of 15th international conference on advanced informationsystems engineering, CAiSE 2003, Klagenfurt, 16–18 June 2003. LNCS, vol 2681.Springer, Berlin/Heidelberg, pp 681–695

[ZZM04] Zhang W, Zhao H, Mei H (2004) A propositional logic-based method for verifica-tion of feature models. In: Davies J, Schulte W, Barnett M (eds) Formal methodsand software engineering, 6th international conference on formal engineeringmethods, Seattle, WA, USA, 8–12 November 2004. LNCS, vol 3308. Springer,Berlin/Heidelberg

[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Documents