Reasoning about Feature Models in Higher-Order Logic

Mikolas Janota and Joseph KinirySchool of Computer Science and Informatics

University College DublinBelfield, Dublin 4, Ireland

mikolas.janota@ucd.ie, joseph.kiniry@ucd.ie

Abstract

A mechanically formalized feature modeling meta-model is presented. This theory is a generic higher-orderformalization of a mathematical model synthesizing severalfeature modeling approaches found in the literature. Thismeta-model supports not only a better understanding of thevarious approaches to feature modeling, but also supportsreasoning about and within feature model approaches, fea-ture models, and on feature trees and their configurations.

1 Introduction

While recently performing a survey of the use of formalmethods in software product line (SPL) research [CN02] wefound that there were several different approaches to fea-ture modeling. While most of these approaches stem fromFODA [KCH+90], some have very subtle differences (ei-ther intentionally or accidentally) and, frequently, preciseexplanations of their semantics are unavailable [FFB02].

Because we wanted to deeply understand feature model-ing, we decided to mechanically formalize a feature mod-eling meta-model, a generic higher-order formalization of amathematical model synthesizing several feature modelingapproaches found in the literature. This meta-model has notonly helped us better understand the various approaches tofeature modeling, but also reason about and within featuremodels.

Additionally, as part of the Mobius1 project, we are lead-ing the development of the Mobius Program VerificationEnvironment (PVE), an Eclipse-based platform for design-ing, testing, performing various kinds of static analyses,and automatically and interactively formally verifying Javaprograms. As we are integrating PVS into this environ-ment, we have an opportunity to directly use executable

1http://mobius.inria.fr

PVS theories from within Eclipse. Using the underlyingformalism of feature meta-models described in this paper,we have an opportunity to make the Mobius PVE a feature-aware programming environment, and perhaps even inte-grate feature-oriented programming and the main program-ming paradigm of Mobius, that of proof-carrying code. Tobridge these two worlds we plan to assign features to Javacomponents in a manner similar to Batory’s AHEAD toolsuite on a feature-aware component model [Bat05].

Thus this work contains several contributions. First,we have mechanically formalized in a higher-orderlogic (HOL) a “feature model meta-model” that integratesproperties found in several feature modeling approachesfrom the literature. To provide evidence that our meta-model is sufficiently rich to reason about, and with, existingfeature models, we have formalized specific existing featuremodel frameworks in our meta-model. Complementing thiswork, we have formulated and proven a number of interest-ing meta-theoretical lemmas about different feature model-ing approaches, which helps one understand how differentapproaches relate to one other. To compare feature models,we have identified, formulated and proven some interest-ing feature model transformations. Additionally, becausewe are reasoning with/in HOL, we can express complex de-pendencies about and within a feature model, and can rea-son about an unbounded number of configurations. Finally,because we have mechanically realized the theory in thehigher-order prover PVS, we have an “executable” modelthat can be used in conjunction with standard software en-gineering tools like integrated development environments.

Before describing our formalism, we first review in Sec-tion 2 the relevant background material on feature model-ing and, in particular, formalizing about, and within, featuremodels.

The meta-model is then described in detail in Section 3and, using that meta-model, we formalize specialization asa relation between models.

To provide evidence that our meta-model is flexible andhas utility, in Section 4, we realize a number of feature

11th International Software Product Line Conference

0-7695-2888-0/07 $25.00 © 2007 IEEEDOI 10.1109/SPLINE.2007.36

13

model examples from the literature. In particular, Czar-necki et al. ’s cardinality and cloning-based scheme(s) (withattributes and model transformations) are formalized. Next,concrete feature models and configurations are describedand checked within our theory.

In Section 5 we review the existing feature modeling ap-proaches from which we derive, and against which we com-pare, our formal meta-model.

Finally, we reflect on this work and propose some nextsteps. In particular, in the interest of full disclosure, wehighlight this work’s limitations and strengths in plain lan-guage.

2 Feature Modeling

We presume the reader is generally aware of the existingwork on feature models/modeling, particularly its origins inFODA [KCH+90] and the general ideas of domain engi-neering and application engineering. We only highlight thespecific work that informs this research, providing a foun-dation for our meta-model.

The technical report introducing the feature orienteddomain analysis [KCH+90] represents the seminal workin feature modeling used in product lines. Among otherthings, the report has introduced the following basic con-cepts.

Feature diagram: A tree of features—a graphical repre-sentation of a feature hierarchy. The meaning of theparent-child relation between features in a tree is thatthe child cannot be selected into a configuration unlessthe parent is also included. Features are categorized asbeing either mandatory, optional, or alternative.

Each alternative feature is part of a group of alternativefeatures under a certain parent, meaning that exactlyone of these children has to be selected whenever thisparent is selected. An optional feature may or maynot be included into the configuration when its parentis selected. A mandatory feature has to be selectedwhenever its parent is selected.

Composition rules: Rules are a mechanism enabling theexpression of mutual dependency (requires) and mu-tual exclusion (mutex-with) relations between two arbi-trary features. Using these relations one expresses re-lationships between features across the tree structure.

Czarnecki et al. provides an extension (as well as disam-biguation) of FODA, where the most important extensionof the introduced feature meta-model are the groups or sub-features2 [CE00].

2At least one of the features from an or sub-group has to be selectedwhenever their parent is selected.

Czarnecki et al. ’s work has further evolved in thecardinality-based notation [CHE04b, CHE04a], based ona case study that we use later [CBUE02]. In this approach,constraints on features are expressed using admissible car-dinalities, as in, for example, Entity-Relation (ER) or UMLmodeling.

Each feature is either a member of a feature group (agroup feature), or it is a solitary feature. Each feature grouphas a cardinality specifying how many features out of thatgroup may be selected when the parent of that group is se-lected. A set of admissible cardinalities is expressed as alist of intervals of natural numbers. Each solitary featurehas a cardinality associated with it specifying how manycopies of that particular feature may be selected wheneverits parent is selected. Selecting multiple copies of the samefeature into a configuration is called feature cloning.

For example, a solitary feature with the cardinality [1..1]corresponds to the mandatory classification; a group withthe cardinality [1..1] corresponds to an alternative group.

A feature model can be broken up into multiple trees (aforest), where a root of a tree can be referenced from theinside of another tree as a sub-feature. Redundancies arethus avoided, as a single tree may be referenced multipletimes. The use of a forest also provides a modularizationmechanism for large feature models.

Additionally, attributes (also called properties) of fea-tures are used to represent variabilities with a large domain,such as numeric values or strings.

Apart from the feature-model, Czarnecki et al. describea number of specializations steps, i.e., operations on the di-agram that lead to a more specialized diagram [CHE04b].Examples of specialization steps include eliminating admis-sible cardinalities of a certain feature, or assigning a valueto an attribute.

3 Formalization

For the purpose of formalization we must decide howto model the individual concepts of all of the feature mod-eling approaches summarized in Section 2. In the modelsthat we have examined in the literature, a feature is simplyan entity with possibly some properties, such as “name”.This led us to formalizing a feature as a record with a setof attributes, where each attribute models a property of thatparticular feature.

Utilizing this definition, we define a feature configura-tion as the set of features that are selected and the values oftheir attributes. Subsequently, a feature model is defined asa function that determines the set of valid configurations. Inother words, we regard a feature model as an “oracle” thatresponds either valid or invalid for a given configuration.

What follows defines a feature meta-model and a featuremodel. We first formalize a type system of features, as the

14

PVS theorem prover provides a typed higher-order logic.

Definition 3.1. First we introduce the following types thatcharacterize the entities of our feature modeling theory T.Let F be the (uninterpreted) type of features, I the type ofattribute identifiers, AT the type of attribute types, and AVthe type of attribute values.

A value typing function assigns a type to every attributevalue: typing : AV → AT

Let T be a set of feature types, where each type is a paircomposed of a set of identifiers, representing the attributes,and a function assigning types to these identifiers (an at-tribute typing function). We express this as the followingdependent type

T ≡ (ids : P(I))× (att : ids → AT )

In the following, for a type t ∈ T we will use the notationt.ids and t.att to access the identifiers in t and the attributetyping function of t, respectively.

A feature typing function assigns types to all features:type : F → T

This definition provides types for features and their at-tributes (see Example 3.4). The following definition intro-duces types characterizing the actual feature model.

Definition 3.2. A value assignment is a function assigningvalues to the attributes of all the features in the domain.The type of a value assignment function ν is a subtype ofthe function type

F → (D → AV) where D ⊆ I

such that, for any feature f , dom(ν(f)) = type(f).idsand, for all id ∈ dom(f), typing(ν(f)(id)) =type(f)(id).

In plain language, this means that the value assignmentadheres to the typing prescribed by the functions typingand type. We will refer to this type, a type of all valueassignments, as A.

The features selected in a configuration are modeled bya selection function which is of the type select, defined asa function from features to booleans: select ≡ F → B

Finally, a restriction functions is at the heart of every fea-ture model. Given a configuration (the values of attributesand given a set of selected features), the restriction functionindicates whether this configuration is admissible or not.This is expressed as the following type

restr ≡ select× A → B

Now that we have defined all the necessary types, wedefine the notion of feature meta-model.

Definition 3.3. A feature meta-model M, defined within ourtheory T, is a set of restriction functions and a feature modelis a particular selected restriction function M∈ M.

Example 3.4. This example illustrates how the functionsdefined above is used. We wish to model the record f1 =[ name : string ] and the assignment f1.name= “a name”.

The following formula states that the value “a name” isof the type string.

typing(“a name”) = string

Then it is possible to express that the type of feature f1 isa record that contains a single attribute identified by theidentifier name, whose type is string.

type(f1) = 〈{name}, λid : {name}•string〉

The following formula states that the value assignmentfunction ν has assigned the value “a name” to the attributename of the feature f1.

ν(f1)(name) = “a name”

Example 3.5. In many feature modeling approaches, suchas the original FODA model, one cannot express restric-tions on attributes. In our terminology, such a model’s re-striction function does not depend on the feature attributes.Formally, a restriction function restr is independent of fea-ture attributes if and only if:

∀s : select; a1, a2 : A•restr(s, a1) = restr(s, a2)

Czarnecki et al. introduced the notion of a staged con-figuration, an approach to configuration where the model isgradually specialized until a model enabling a single config-uration remains [CHE04b] . Using the above formalization,it is straightforward to formally define specialization.

Definition 3.6. Let m1 and m2 be feature models definedon the same set of attributes and feature domain. Let restr1

and restr2 be their restriction functions respectively. Thenm2 is a specialization of m1 if and only if all the admissi-ble configurations by restr2 are also admissible by restr1.This is realized as the following predicate on restrictionfunctions.

specialization?(restr2, restr1 : restr) ≡∀s : select; a : A•restr2(s, a) ⇒ restr1(s, a)

This definition is more liberal than that presented byCzarnecki et al. as a specialization that does not reduce theset of possible configuration is still considered a specializa-tion here.

4 Applying the Theory

In the previous section we have formally defined the con-cept of the feature model. This section brings feature dia-grams into this context. More specifically, we address the

15

translation of a feature diagram, (a labeled graph on fea-tures), to a feature model, which is a restriction function onconfigurations (see Definitions 3.1, 3.2, and 3.3).

This translation is accomplished in two steps. First weformalize a specific type of feature diagram as a mathemat-ical construct. Second, we define a function that takes thisconstruct and returns a restriction function corresponding tothe semantics of that diagram.

Furthermore, we illustrate on several lemmas and exam-ples how we can reason and work with this formalization.

Please note that we do not provide the full account of theproofs here due to space limitations. Rather sketches of theproofs written in the proof assistant PVS are provided. Asin the previous section, we utilize a standard mathematicalnotation to describe the PVS formalization. We encouragethe reader to download our PVS theories and proofs fromour research group’s homepage3 for more details.

4.1 Feature Diagram Formalization

In this section we formalize the feature model presentedby Czarnecki et al. using our theory T, as mechanically re-alized in the PVS theorem prover [CHE04b].

From the meta-modeling point of view, this model rep-resents an interesting challenge because we must model theability to clone a feature. We have chosen to model this no-tion by introducing the concept of clone groups. A clonegroup contains all the possible clones of the feature that wewish to be cloneable. In other words, such a group repre-sents a pool of clones for that particular feature.

The only restriction that we impose on a clone group isthat all of its members must be of the same type. Hence,for each solitary feature in the original model, we introducea clone group whose members (the clones) are of the typeof that feature. Since the grouped features in the originalmodel are aggregated into a group, it is only natural to makethem members of groups in our model as well. We refer tothese kind of groups simply as feature groups.

Admissible cardinalities must also be formalized. Theyare realized by labeling each group with the set of its ad-missible cardinalities. In the original work, cardinalitiesare represented as lists of intervals of natural numbers; inthe model presented here, however, we enable any subset ofnatural numbers. While there is a difference between thesetwo representations, it is not crucial for this work.

Definition 4.1. Given the types defined in Definitions 3.1and 3.2, and given an additional type G, the type of groups,a feature tree is a tuple

TREE ≡ 〈R,LT ,LC , groups, members〉

3http://secure.ucd.ie/

where R : F is the root concept of the feature tree, G is a setof groups, where each group is labeled by LT according toits type, and by LC determining its admissible cardinalities,

LT : G → feature | clone

LC : G → P(N)

The structure of the diagram is defined by the functionsgroups and members. For each feature f , groups deter-mines which groups f owns and the function members de-termines the features that belong to a given group.

groups : F → P(G)members : G → P(F)

These two functions have to satisfy the following conditions:(1) the root concept does not belong to any group, (2) nofeature belongs to more than one group, (3) each group isused for partitioning at most one feature and, finally, (4)members of each clone group must have the same type.

∀g : G•R /∈ members(g) (1)

∀g1, g2 : G•g1 6= g2 ⇒members(g1) ∩members(g2) = ∅ (2)

∀f1, f2 : F•f1 6= f2 ⇒groups(f1) ∩ groups(f2) = ∅ (3)

∀g : G•LT (g) = clone ⇒∀f1, f2 ∈ members(g)•type(f1) = type(f2)

(4)

Now that we have defined what a feature diagram is, wedefine the standard parent-child relationship between fea-tures.

Definition 4.2. Given a feature tree T =〈R,LT ,LC , groups, members〉, two features are inthe parent-child relation if the parent feature owns a groupof which the child is a member. This relation is captured bythe following equation:

child?(p, c : F) ≡(∃g : G•g ∈ groups(p) ∧ c ∈ members(g))

This parent-child relation, and the structure imposed bythe definitions of groups and members, enforces a treestructure only on the features that are reachable from theroot, and we have formally proven this fact in our PVStheory. (In practice, the tree will not even contain infinitepaths.) By not forcing all features to be part of a single tree,we can track and reason about features that are not usedsince, due to the selection mechanism, features not reach-able from the root cannot be selected. An addition bonus isthat one is not forced to change the feature domain when-ever the model is modified.

16

Definition 4.3. Given a feature tree T =〈R,LT ,LC , groups, members〉, the restriction func-tion of type select : select, a : A is a conjunct of thefollowing conditions:

• the root of T must be selected: select(R)

• whenever a feature f is selected, there must be a pathof selected features from the root to f :

∀f : F•select(f) ⇒(∃f1, . . . , fn•

(f1 = R) ∧ (fn = f)∧(∀i ∈ [1. . .(n− 1)]•child?(fi, fi + 1))∧(∀i ∈ [1. . .n]•select(fi)))

• for each group, if its owner is selected, its cardinalitiesmust be satisfied:

∀p : F ; g : G•select(p) ∧ g ∈ groups(p) ⇒|{f : F • f ∈ members(g) ∧ select(f)}| ∈ LC(g)

(5)

We will denote the function taking a feature and return-ing its restriction function as restriction:

restriction : TREE → (select× A → B)

4.2 Meta-model Properties

Next, we present an example of a lemma that relatesthe concept of a mandatory feature to the cardinality no-tation [CE00]4. By realizing feature relations of “classical”feature models like FODA in our formalism we can “sanitycheck” our model against the many earlier formalizationsof the same constructs. Providing such “native” lemmasand formalisms also provides a natural target for a directtranslation of classical feature diagrams into our theory.

The Mandatory Lemma. If a group g has exactly the ad-missible cardinality 1, and contains exactly one member m,then in any valid configuration that selects the owner of thatgroup, m is selected as well. I.e., m is a mandatory feature.

∀ft : TREE, g : G;m : F•(ft.Lc(g) = {1} ∧ ft. members(g) = {m}) ⇒(∀s : select, a : A•

(restriction(ft)(s, a)∧(∃p : F•s(p) ∧ g ∈ ft. groups(p))) ⇒s(m))

4We have formalized and proven an analogous lemma for the alterna-tive feature in our theory.

Proof sketch. This lemma follows from Definition 4.3’sequation 5, imposed by the restriction function. Since theadmissible cardinality of the group g, LC(g), is exactly 1,and m is the only member of g, m has to be selected when-ever the owner of g is selected.

Our meta-model of feature modeling approaches is de-signed such that it is easily refined and extended. For ex-ample, we might require that all the selected members ofa clone group are unique via their attribute values. Anyother constraints are then simply expressed as additionalconjuncts.

4.3 Model Transformation

Our formalization enables us to reason about the oper-ations on feature models, as illustrated by the followinglemma. Recall that a specialization of a feature model wasdefined in Section 3.

The Cardinality Specialization Lemma. Whenever a newfeature tree ft2 is obtained from an existing feature treeft1 by removing some admissible cardinalities of a certaingroup g, the feature tree ft2 is a specialization of the origi-nal tree ft1. This fact is formalized in the following formularelating two feature trees that differ from one another onlyin their cardinality function:

∀ft1, ft2 : TREE, g : G,LC : G → P(N)•ft2 = 〈ft1.R, ft1.LT ,LC , ft1. groups, ft1.members〉LC(g) ⊆ ft1.LC(g)∧(∀l : G•(l 6= g) ⇒ ft2.LC(l) = ft1.LC(l))) ⇒

specialization?(restriction(ft2), restriction(ft1))

Proof sketch. We must show that any configuration admis-sible by ft2 is also admissible for ft1. Since the two treesdiffer only in the set of admissible cardinalities for the groupg, only requirement 5 is different in the resulting restrictionfunctions. Let us introduce the following shorthand,

Sg ≡ |{f : F • f ∈ members(g) ∧ select(f)}|

then the proof hinges on the following implication,

Sg ∈ ft2.LC(g) ⇒ Sg ∈ ft1.LC(g)

which follows immediately from the precondition that re-quires ft2.LC(g) ⊆ ft1.LC(g).

Additionally, in this context we are able to formalizethe individual steps of transformations as functions from amore general restriction function to the specialized restric-tion function. As an example, the following definition intro-duces the function assign-value , which takes a restrictionfunction r and returns its specialization that requires that agiven attribute atr has a given value v. In the following, the

17

type of val requires that the attribute value corresponds tothe type of the attribute.

assign-value (r : restr, f : F , atr : type(f).ids;val : {v : AV • typing(v) = type(f).att(atr)}) ≡λs : select, ν : A•r(s, ν) ∧ (ν(f)(atr) = val)

Properties of such transformations can be investigated asillustrated by the following formula:

∀r : restr; f : F ; atr : type(f).ids;val : {v : AV • typing(v) = type(f).att(atr)} •

specialized?(assign-value (r, f, atr, val), r)

Analogously, the following higher-order function spe-cializes a given restriction function with a requires relationbetween two given features.

require(restr : restr, requiree : F , required : F) ≡λs : select, ν : A•

restr(select, ν)∧(s(requiree) ⇒ s(required))

Please note that both these specializations are conjunctsof the original restriction function and the additional con-straint, which guarantees that we obtain a specialization.

The two functions above, require and assign-value ,suggest how we can specialize a restriction function step-by-step. Moreover, this style of reasoning provides amechanism to combine the information captured in a fea-ture tree with additional constraints by using the functionrestriction to obtain the first restriction function in the spe-cialization chain. This is schematically illustrated by:

fm = specn(. . . (spec1(restriction(ft))) . . . )

We are particularly intrigued by the simplicity and rich-ness of this specialization-based (function type subtyping)approach to model refinement.

4.4 Feature Models with Cloning

In Czarnecki et al. ’s paper on staged configuration, aconcrete feature tree of an operating system security profileis used as an example [CBUE02]. Due to space issues, weillustrate here only the topmost nodes of the tree as realizedin our formal model.

A graphical representation of this example feature tree isdepicted in Figure 1.

This feature tree is graphically depicted using our for-malism in Figure 2. In this diagram style we continue to useovals to represent features and introduce the use of rectan-gles to represent groups. A normal feature group is a plainrectangle, (the passwordPolicyGroup with a cardinality of1), and cloned feature groups as a stack of rectangles (see

securityProfile

permissionSet(String)passwordPolicy

[0..*]

Figure 1. The topmost nodes of the featuretree example from Czarnecki et al. [CHE04b].

securityProfile

passwordPolicy

passwordPolicyGroup

card: {1}

permissionSet(String)

permissionSetGroup

card: ℕ

Figure 2. Our representation of the featuretree from Figure 1.

Figure 3). Note that we are not introducing a new featuremodeling graphical notation, we are only depicting our for-mal model graphically for the benefit of the reader.

On this example we can illustrate the advantage of usinga full HOL description. This model has an unbounded num-ber of configurations as the number of possible assignmentsis infinite and the permissionSet feature can be cloned adlibitum. Thus, to investigate properties, one cannot directlyemploy a (finite state) model checker, for example. Onesuch property is illustrated by the following lemma.

Lemma 4.4. The passwordPolicy feature will be includedin every valid configuration of the the security profile tree.This fact is stated as a formula quantified over all featureconfigurations. Please recall that the function restrictionreturns a restriction function for a given feature tree. Letsecurity-tree be the tree depicted in Figure 1.

∀s : select; ν : A•restriction(security-tree)(s, ν) ⇒ s(passwordPolicy)

Proof sketch. This lemma immediately follows from thefact that the root (the securityProfile feature) has to be se-lected in every valid configuration, and from the mandatorylemma (see Section 4.2).

18

To show that this model is consistent, we must pro-vide a configuration and prove that it is valid. In thePVS theory, we define a configuration by selecting the fea-tures securityProfile, passwordPolicy, permissionSet0,and permissionSet1, where the clones permissionSet0,permissionSet1 are assigned arbitrary names. Subse-quently, we mechanically prove that this configuration isvalid.

4.5 Feature Models with Attributes

As our formalized feature meta-model supports at-tributes, an example including the use of attributes is war-ranted. This example, focusing on a satellite softwarecase study, is a slightly modified version of an exam-ple from Czarnecki et al. ’s paper on generative program-ming [CBUE02].

Satellite

PacketRouterApp

StorageControlApp UserDefinedApp

StorageControlAppGroup

PacketRouterAppGroup

UserDefinedAppGroup

card: ℕcard: {1} card: {0, 1}

CircuitSwitchedApp

Figure 3. A fragment of the satellite featuremodel from Czarnecki et al. [CBUE02].

In this example, a fragment of which is summarized inFigure 3, the interface to a satellite system consists of a sin-gle mandatory packet router application, an optional stor-age control application, and a number of applications. Be-cause the hardware resources of a satellite are fixed and pre-cious, we must ensure that any given configuration will fitwithin those resource bounds. For example, we must ensurethat all selected applications will fit in the main memory ofthe satellite. Such a constraint is easily expressed with at-tributes.

The feature UserDefinedApp has an attributeMaxStorageFieldSize of type integer. We interpretthis attribute to mean the maximum amount of mainmemory that the given feature can demand of the satel-lite’s software system. Additionally, the feature Satellitecontains the related field MaxUserMainMemory, whichindicates a satellite’s (fixed, finite) main memory size avail-able for user-defined applications. Both of these attributesare summarized in the “exploded” feature representationsin Figure 4.

UserDefinedApp

APID: IntMaxStorageFieldSize: Int

Satellite

MaxUserMainMemory: Int

Figure 4. Exploded representation of thefeatures Satellite and UserDefinedApp fromFigure 3.

To formally capture the aforementioned memory con-straint, we specify the following restriction function. Letsatellite-tree be the tree depicted in Figure 3.

λs : select; ν : A•restriction(satellite-tree)∧∃n : N, sel : P(F)•

sel = {f : F•s(f)∧f ∈ members(UserDefinedAppGroup)}

∧ |sel| < n

∧(∑

c∈sel ν(c)(MaxStorageFieldSize)

< ν(Satellite)(MaxUserMainMemory))

This constraint defines a new restriction function via spe-cialization. The new restriction function specializes theexisting restriction function obtained from the diagram byadding the desired constraint as an additional conjunct. Theconstraint states that the set of the selected clones is finite,and that the sum over the MaxStorageFieldSize attribute ofthe selected clones is less than the MaxUserMainMemoryattribute of the Satellite feature. We have verified validand invalid configurations against this specialized restric-tion function in PVS.

This example illustrates the need for two kindsof groups—clone groups and feature groups. To beable to state this example constraint, we need all themembers of the UserDefinedApp to have the attributeMaxStorageFieldSize. In other words, we need for all themembers of the UserDefinedApp group to have the sametype. On the other hand, the PacketRouterApp group,which is a group of alternative features, contains featuresthat are potentially of different type.

The example also suggests how constraints of thiskind could be expressed more succinctly. In particular,the introduction of auxiliary functions and constraints forfrequently-used constructs would be beneficial. It is naturalto require that a configuration contains a finite set of fea-tures, thus, this constraint should be part of the panoply ofthe predefined specializations. Another example of a fre-quently used construct is a function that returns the set ofselected features in a given group or a set.

19

Using a HOL formalization of a feature modeling meta-model, many new avenues of investigation are now avail-able. And, while having a mechanical formalization ensurescertain meta-theoretical properties about the research (e.g.,soundness of the theory, correctness of model refinementsand transformations, etc.), there are tradeoffs in demandingthis level of rigor. We will first discuss related work that hasboth influenced this meta-model and that we can model inour theory. Then we discuss the pros and cons of our ap-proach. Finally, we reflect on some potential next researchsteps.

5 Related Work

Propositional formulas were introduced into the SPL do-main by Mannion [Man02]. The principal idea is that vari-ability and commonality, defined by a feature diagram, aretranslated into a propositional formula where the atoms rep-resent features and the formula is valid if and only if a givenconfiguration is admissible.

This idea has been extensively addressed by Ba-tory [Bat05]. This work formalizes the correspondencebetween feature diagrams, grammars, and propositionalformulas. Czarnecki et al. also introduced the use ofcontext-free grammars as a semantics for their featuremodel [CHE04b, CHE04a].

Neither of these approaches, propositional formulas orgrammars, work well with all models. A semantics givenas a propositional formula is not well-suited for a meta-model that enables cloning of features, especially in thework of Czarnecki et al. where a feature can be cloned adlibitum. Whereas the grammar-based approaches elegantlymodel feature cloning, and the structure of the translateddiagram is well-reflected by the grammar, the full use ofcross-cutting dependencies, such as excludes and requires,is difficult to capture. Most importantly, however, it is notclear how dependencies between attributes should be mod-eled.

Czarnecki and Kim describe the use of OCL in the con-text of a feature model to express constraints that are notexpressible by the diagram, the so called additional con-straints [CK05]. Their formalism allows at most one at-tribute per feature and the type of an attribute is either aprimitive type or a reference to another feature. In this con-text, the feature diagram is translated to UML. In the UMLdiagram, entities correspond to features and a multiplicity atthe aggregate end of every composition is 1, while the mul-tiplicity at the other end is the same as the correspondingcardinality in the feature diagram.

Kim and Czarnecki also addressed the issue of evolutionof a feature model in the context of specialization [KC05].More specifically, when a feature model is configured viaspecialization, and later that feature model evolves, the

changes made by the evolution are reflected by the special-ized models. The article describes how to cope with a set ofevolution changes and specializations. The authors appliedthe QVT relation language to express the relations betweenspecializations of the original and evolved models.

Benavides et al. apply the techniques of constraint pro-gramming to feature models [BTRC05]. The authors extendthe feature meta-model with the capability of out-fitting fea-tures with attributes and define constraints between theseattributes, where the form of constraints is inspired by thework of Streitferdt et al. [SRP03]. The authors provide atranslation of the feature model constraints to a constraintprogramming problem. This translation enables the use aconstraint solver for analyzing a given configuration.

This work demonstrates the benefits of translating theconstraints between features into a format understood bya reasoning engine. The use of constraint programming inthe SPL domain appears to be quite promising. The article,however, does not provide the full account of the constraintlanguage used.

Schobbens et al. introduce a generic formalization of fea-ture models based on the FODA notation [SHT06]. Theirmeta-model is parameterized by two concepts: a graph type,which can be either a DAG or a tree; and node types, whichare sets of boolean functions (e.g., a set of ands for everyarity s ∈ N+ forms a node type). Cross-graph constraintsare either expressed as graphical constraints or by using atextual constraints language. In the context of this parame-terization, the concept of a feature diagram is defined. Sub-sequently, the authors define the concepts of a model anda valid model of a feature diagram. A model of a featurediagram is a subset of its nodes, representing the selectedfeatures, and a valid model is such a model that satisfies allthe constraints imposed by the diagram. Additionally, theauthors examine the expressiveness of their meta-models.

A formalization of a feature modeling approach us-ing the Z language has also been defined by Sun et al.[SZLW05]. The authors formalize the ODM notation, avariant of the original FODA notation. The formalizationis realized as a set of relations, each of which defines a dif-ferent type of the parent-feature relationships (e.g., alter-native, mandatory, etc.). A number of theorems about themeta-model are proven to verify certain desired propertiesof the definitions. For example, one of these theorems statesthat if a feature is selected, and its children are alternative,then exactly one of its children is selected. Furthermore, theauthors realize the formalization in the Alloy tool in a sub-set of the Z language to automatically reason about featuremodels.

Gheyi et al. provide a semantics for a concrete featuremodel with propositional constraints (attributes are not con-sidered) in Alloy [GMB06]. An interesting aspect of thiswork is that the authors focused on refactoring of feature

20

models, and the article formalizes the notion correct refac-toring, i.e., an operation is a correct refactoring if it pre-serves the semantics of the original feature model.

5.1 Limitations and Strengths

Using a HOL theorem prover is often a double-edgedsword. We can express dependencies of arbitrary complex-ity, as illustrated by the satellite example in Section 4.5.Thus, it is not necessary to introduce new constructs or no-tations, since the PVS system provides tool support, lan-guage, and its semantics. Reasoning at the meta-modellevel, i.e., statements of the form “for all models ...”, isvery difficult or impossible to accomplish in a tool withweaker expressivity (e.g., a tool without higher-order fea-tures). Furthermore, some feature modeling approaches in-clude first-order quantification (over attribute values, for ex-ample); consequently such a first-order approach cannot bemeta-modeled without using (at least) a second-order logic.Our use of PVS is motivated by this requirement, our ex-pertise in PVS, and the fact that powerful second-order in-teractive provers simply do not exist.

On the other hand, the proofs regarding concrete featuremodels are unnecessarily tedious. We believe that one of thereasons for this is that the defined feature model imposes toofew implicit restrictions. For example, it is possible in ourmeta-model to have configurations with an infinite numberof selected features, or a tree can contain infinite paths. Ad-ditionally, as discussed below, we are not using any domain-specific strategies in PVS, thus we are only currently usingthe “raw” PVS language and proof system with few auxil-iary constructs. It is not clear how much these restrictionsand constructs will make the reasoning easier.

A scenario we are considering, discussed in more detailin the sequel, is the use a feature modeling tool to describethe desired diagram, automatically produce the PVS repre-sentation of the diagram along with the rudimentary proofs,and utilize PVS for dependencies not expressible by a fea-ture diagram. For example, if a feature is selected, a proofhas to be given that there is a path to the root of selectedfeatures, and constructing such a proof is easily automated.

5.2 Future Work

To support within the Mobius PVE the main metaphorthat feature-oriented programmers are used to, we hope toeither adopt an existing feature diagramming component, orif necessary, develop our own using GEF5. A natural nextstep is generating GEF, and compiling GEF to PVS theo-ries, a standard syntax for feature diagrams. If one does notyet exist, we believe that Graphviz6’s dot file format is a

5http://www.eclipse.org/gef/6http://www.graphviz.org/

good candidate given its simplicity, its focus on annotateddirected graphs, its quality tool support, and our familiaritywith it.

Once we have a given feature model and proposed se-lection in PVS, we can check its consistency, as we haveshown in this paper. Likewise, we can check the valid-ity of a given configuration within a given feature model.Of course, given that PVS is an interactive theorem prover,such checks, especially when arbitrary constraints on fea-tures and attributes are specified, is sometimes a laboriousprocess. In the past we have used several solutions to auto-mate these kinds of standard operations.

First, we can write domain-specific PVS strategies. Fora theory as simple as the one presented here, this should bestraightforward enough. And, while writing flexible strate-gies that are robust in the face of theory evolution is a fineart, we have sufficient experience in PVS to accomplishsuch. Another solution for automation is relying upon amodel checker or an SMT solver, both of which are inte-grated with PVS 4 and the Mobius PVE. By mapping ourtheory to a model within PVS (in the case of using themodel checker), or by relying upon only first-order terms(in the latter case of using an SMT solver), then we cansolve problems like the feature model configuration checkautomatically and efficiently.

Finally, there are many open questions about featuremodels that we would like to investigate now that we havea HOL formalization. What are the appropriate notions ofsoundness and completeness of a set of specialization op-erations with respect to our formalization? Might feature(meta-)models be more naturally formalized using recordsand structural subtyping? What other kinds of interest-ing refinements are there? Should we formalize and rigor-ously compare other proposed feature models? Does a fea-ture model with some notion of multiple-inheritance makesense?

The full PVS formalization of our theory of feature meta-models, all the discussed examples (and others for which wehad no room to discuss), and all proofs is available via ourresearch group’s homepage7.

6 Acknowledgments

This work is partially supported by Science FoundationIreland under grant number 03/CE2/I303-1, “LERO: theIrish Software Engineering Research Centre.” This workwas funded in part by the Information Society Technolo-gies programme of the European Commission, Future andEmerging Technologies under the IST-2005-015905 MO-BIUS project. This article reflects only the authors’ viewsand the Community is not liable for any use that may bemade of the information contained therein.

7http://secure.ucd.ie/

21

References

[Bat05] Don Batory. Feature models, grammars, andpropositional formulas. In Henk Obbink andKlaus Pohl, editors, Proceedings of the 9th In-ternational Conference, SPLC 2005, volume3714 of Lecture Notes in Computer Science.Springer Berlin/Heidelberg, September 2005.

[BTRC05] David Benavides, Pablo Trinidad, and Anto-nio Ruiz-Cortes. Automated reasoning onfeature models. In Pastor Oscar and JoaoFalcao e Cunha, editors, Proceedings of 17thInternational Conference, (CAiSE 2005), vol-ume 3520 of Lecture Notes in Computer Sci-ence. Springer–Verlag, 2005.

[CBUE02] Krzysztof Czarnecki, Thomas Bednasch, PeterUnger, and Ulrich Eisenecker. Generative pro-gramming for embedded software: An indus-trial experience report. In Don Batory, CharlesConsel, and Walid Taha, editors, Proceedingsof the ACM SIGPLAN/SIGSOFT Conferenceon Generative Programming and ComponentEngineering (GPCE 2002), volume 2487 ofLecture Notes in Computer Science. SpringerBerlin/Heidelberg, October 2002.

[CE00] Krzysztof Czarnecki and Ulrich W. Eisenecker.Generative Programming – Methods, Tools,and Applications. Addison-Wesley PublishingCompany, 2000.

[Cha02] Gary J. Chastek, editor. Software ProductLines, volume 2379 of Lecture Notes in Com-puter Science. Springer Berlin/Heidelberg, Au-gust 2002.

[CHE04a] Krzysztof Czarnecki, Simon Helsen, and Ul-rich Eisenecker. Formalizing cardinality-basedfeature models and their staged configuration.Technical Report 04–11, Department of Elec-trical and Computer Engineering, University ofWaterloo, Canada, April 2004.

[CHE04b] Krzysztof Czarnecki, Simon Helsen, and Ul-rich Eisenecker. Staged configuration usingfeature models. In Robert L. Nord, editor,Proceedings of Third International Conference,SPLC 2004, volume 3154 of Lecture Notes inComputer Science. Springer Berlin/Heidelberg,August 2004.

[CK05] Krzysztof Czarnecki and Chang Hwan PeterKim. Cardinality-based feature modeling andconstraints: A progress report. In Proceedings

of International Workshop on Software Facto-ries, 2005.

[CN02] Paul Clements and Linda Northrop. Soft-ware Product Lines: Practices and Patterns.Addison-Wesley Publishing Company, 2002.

[FFB02] Daniel Fey, Robert Fajta, and Andras Boros.Feature modeling: A meta-model to enhanceusability and usefulness. In Chastek [Cha02].

[GMB06] Rohit Gheyi, Tiago Massoni, and Paulo Borba.A theory for feature models in Alloy. In Pro-ceedings of First Alloy Workshop, 2006.

[KC05] Chang Hwan Peter Kim and Krzysztof Czar-necki. Synchronizing cardinality-based featuremodels and their specializations. In Proceed-ings of European Conference on Model DrivenArchitecture: Foundations and Applications,Lecture Notes in Computer Science. Springer–Verlag, 2005.

[KCH+90] Kyo C. Kang, Sholom G. Cohen, James A.Hess, William E. Novak, and A. SpencerPeterson. Feature-oriented domain analy-sis (FODA), feasibility study. Technical ReportCMU/SEI-90-TR-021, Software EngineeringInstitute, Carnegie Mellon University, Novem-ber 1990.

[Man02] Mike Mannion. Using first-order logic forproduct line model validation. In Chastek[Cha02].

[SHT06] Pierre-Yves Schobbens, Patrick Heymans, andJean-Christophe Trigaux. Feature diagrams: Asurvey and a formal semantics. In Proceedingof 14th IEEE International Requirements Engi-neering Conference (RE’06). IEEE ComputerSociety, 2006.

[SRP03] Detlef Streitferdt, Matthias Riebisch, and IlkaPhilippow. Details of formalized relationsin feature models using OCL. In Proceed-ings of the 10th IEEE International Confer-ence on Engineering of Computer-Based Sys-tems (ECBS 2003). IEEE Computer Society,2003.

[SZLW05] Jing Sun, Hongyu Zhang, Yuan Fang Li, andHai Wang. Formal semantics and verifica-tion for feature modeling. In Proceedingsof the 10th IEEE International Conferenceon Engineering of Complex Computer Sys-tems (ICECCS 2005). IEEE Computer Society,2005.

22