Staged Configuration Using Feature Models

Transcription

1 Staged Coniguration Using Feature Models Krzyszto Czarnecki 1, Simon Helsen 1, and Ulrich Eisenecker 2 1 University o Waterloo, Canada 2 University o Applied Sciences Kaiserslautern, Zweibrücken, Germany Abstract. Feature modeling is an important approach to capturing commonalities and variabilities in system amilies and product lines. In this paper, we propose a cardinality-based notation or eature modeling, which integrates a number o existing extensions o previous approaches. We then introduce and motivate the novel concept o staged coniguration. Staged coniguration can be achieved by the stepwise specialization o eature models. This is important because in a realistic development process, dierent groups and dierent people eliminate product variability in dierent stages. We also indicate how cardinality-based eature models and their specialization can be given a precise ormal semantics. 1 Introduction Feature modeling is a key approach to capturing and managing the common and variable eatures o systems in a system amily or a product line. In the early stages o sotware amily development, eature models provide the basis or scoping the system amily by recording and assessing inormation such as which eatures are important to enter a new market or remain in an existing market, which eatures incur a technological risk, what is the projected development cost o each eature, and so orth [1]. Later, eature models play a central role in the development o a system amily architecture, which has to realize the variation points speciied in the eature models [2, 3]. In application engineering, eature models can drive requirements elicitation and analysis. Knowing which eatures are available in the sotware amily may help customers decide which eatures their system should support. Knowing which desired eatures are provided by the system amily and which have to be custom-developed helps to better estimate the time and cost needed or developing the system. A sotware pricing model could also be based on the additional inormation recorded in a eature model. Feature models also play a key role in generative sotware development [2,4 7]. Generative sotware development aims at automating application engineering based on system amilies: a system is generated rom a speciication written in one or more textual or graphical domain-speciic languages (DSLs). In this context, eature models are used to scope and develop DSLs [2, 8], which may range rom simple parameter lists or eature hierarchies to more sophisticated DSLs with graph-like structures. Feature modeling was proposed as part o the Feature-Oriented Domain Analysis (FODA) method [9], and since then, it has been applied in a number o domains including telecom systems [10,11], template libraries [2], network

2 protocols [12], and embedded systems [13]. Based on this growing experience, a number o extensions and variants o the original FODA notation have been proposed [10, 11, 13 17]. 1.1 Contributions and Overview In this paper, we make the ollowing contributions: we present a cardinalitybased notation or eature models, which integrates and adapts our existing extensions to the FODA notation namely eature cardinalities, group cardinalities, eature diagram reerences, and attributes. We also propose the novel concept o staged coniguration based on specializing eature models and illustrate how specialization can be achieved in a sound way. Finally, we briely indicate how a cardinality-based eature model can be ormalized. The details o this ormalization are elaborated elsewhere [18]. The remainder o the paper is organized as ollows. Section 2 reviews background concepts and related work on eature modeling. Our cardinality-based notation or eature modeling is presented in Section 3. Staged coniguration is described in Section 4. Section 5 gives a glimpse o an approach to ormalize eature models. Appendix A gives a comparison o three dierent notations or eature modeling. 2 Background and Related Work 2.1 Features, Feature Diagrams, and Feature Models A eature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate between systems. Features are organized in eature diagrams. A eature diagram is a tree with the root representing a concept (e.g., a sotware system), and its descendent nodes are eatures. In the FODA eature diagram notation (see the letmost column o Table 1 in Appendix A), eatures can be mandatory, optional, or alternative. Feature models are eature diagrams plus additional inormation such as eature descriptions, binding times, priorities, stakeholders, and so orth. Feature diagrams oer a simple and intuitive notation to represent variation points in a way that is independent o implementation mechanisms such as inheritance or aggregation. It is important not to conuse eature diagrams with part-o hierarchies or decompositions o sotware modules. Features may or may not correspond to concrete sotware modules. In general, we distinguish the ollowing our cases: Concrete eatures such as data storage or sorting may be realized as individual components. Aspectual eatures such as synchronization or logging may aect a number o components and can be modularized using aspect technologies. Abstract eatures such as perormance requirements usually map to some coniguration o components and/or aspects.

3 Grouping eatures may represent a variation point and map to a common interace o plug-compatible components, or they may have a purely organizational purpose with no requirements implied. 2.2 Summary o Existing Extensions Since its initial introduction in the technical report by Kang and associates [9], several extensions and variants o the original FODA notation have been proposed. In the ollowing summary, we abstract rom variations in concrete syntax and ocus on the conceptual extensions. eature cardinalities. Features can be annotated with cardinalities, such as [1.. ] or [3..3]. Mandatory and optional eatures can be considered special cases o eatures with the cardinalities [1..1] and [0..1], respectively. Feature cardinalities were motivated by a practical application [13] (ater they were initially rejected [2]). groups and group cardinalities. Alternative eatures in the FODA notation can be viewed as a grouping mechanism. Two urther kinds o groups were proposed in Czarnecki s thesis [14]: the inclusive-or group and the inclusiveor group with optional subeatures (see the middle column o Table 1 in Appendix A). 3 The concept o groups was urther generalized in [17] as a set o eatures annotated with a cardinality speciying an interval o how many eatures can be selected rom that set. The previous kinds o groups become special cases o groups with cardinalities (see the rightmost column o Table 1 in Appendix A). attributes. Attributes were introduced by Czarnecki and associates [13] as a way to represent a choice o a value rom a large or ininite domain such as integers or strings. An elegant way to model attributes proposed by Bednasch [19] is to allow a eature to be associated with a type (such as integer or string). A collection o attributes can be modeled as a number o subeatures, where each is associated with a desired type. relationships. Several authors [10, 11, 16] proposed to extend eature models with dierent kinds o relationships such as consists-o or is-generalizationo. eature categories and annotations. FODA distinguishes among context, representation, and operational eatures. FeatuRSEB [10] proposes unctional, architectural, or implementation eature categories. Section 2.1 gives yet another categorization. Additional inormation on eatures suggested in FODA include descriptions, constraints, binding time, and rationale. Other examples are priorities, stakeholders, deault selections, and exemplar systems [2, 14]. 3 Inclusive-or eatures were introduced independently by Czarnecki [14] and Griss and associates [10]. However, inclusive-or eatures in Griss and associates work [10] imply reuse-time binding, whereas inclusive-or eatures in Czarnecki s work [14] are independent o binding time.

4 modularization. A eature diagram may contain one or more special lea nodes, each standing or a separate eature diagram [19]. This mechanism allows the breaking up o large diagrams into smaller ones and the reuse o common parts in several places.this is an important mechanism because, in practice, eature diagrams can become too large to be considered in their entirety. 3 Cardinality-Based Feature Modeling This section proposes a cardinality-based notation or eature modeling, which is based on modest changes to the previously introduced concepts o eature cardinalities, group cardinalities, and diagram modularization (see Section 2.2). In particular, a eature cardinality speciication may consist o a sequence o intervals. Furthermore, our notation does not allow eatures that are members o a eature group to be qualiied with eature cardinalities. This is because a eature cardinality is a property o the relationship between a single subeature and its parent. Similarly, a group cardinality is a property o the relationship between a parent and a set o subeatures. Next to cardinalities, we have the notion o eature diagram reerences, which allow us to reuse or modularize eature models in a similar ashion as described by Bednasch [19]. In contrast to Bednasch s work [19], eature diagram reerences allow recursion, which may be either direct or indirect. Direct recursion occurs when a eature diagram reerence reers to the eature diagram in which it resides, while indirect recursion involves more than one diagram. The chosen set o conceptual extensions and their adaptations are motivated both by practical applications and the urge to achieve a balance between simplicity and conceptual completeness. Feature cardinalities and attributes are common in modeling both embedded sotware [13] and enterprise sotware (see our example in Section 3.1). The primary motivation or including group cardinalities is elegance and completeness. Although our experience so ar shows that the vast majority o groups are either exclusive-or or inclusive-or, other group cardinality values may still be useul in more exotic situations (e.g., [17] and the example in Section 3.1). Compared to the more proound semantic implications o eature cardinalities, the addition o group cardinalities is semantically relatively straightorward. In our notation, we do not consider relationships between eatures such as consists-o or is-generalization-o because we think that they are better modeled using other notations such as entity-relationship or class diagrams. In general, we believe that a eature modeling notation should ocus purely on capturing commonality and variability. However, i necessary, a tool with an extensible metamodel [19, 20] may allow the user to introduce additional kinds o relationships. Finally, eature categories and other additional inormation are domain dependent, and as previously argued by Czarnecki and associates [13], we think that they are better handled as user-deined, structured annotations. Such annotations are also supported through an extensible metamodel [19].

5 securityproile [0..*] permissionset(string) passwordpolicy ileio iledialog expiration chars never indays (Int) lowercase uppercase unrestricted <2 4> restricted specialchar digit [0..*] ilepath(string) open environmentvariables close permission <0 2> read write Fig. 1. Security proile example 3.1 A Security Proiling Example As a practical example to demonstrate the expressiveness o our eature modeling language, consider a eature model o an operating system security proile in Fig. 1. The password policy o the security proile has an expiration time and possible requirements on the kind o characters to be used. Passwords can be set to never expire, or to expire only ater a given number o days. The number o days a password remains valid can be set in the integer attribute o the indays eature. Generally, whenever a eature has an attribute, we indicate its type within parentheses ater the eature name; or example, myfeature (Int). Itisalso possible to speciy a value o the associated type immediately with the type; myfeature (5 : Int) or example,. The constraints on the kind o characters required in a password are speciied by a eature group with cardinality 2 4. This means that any actual password policy must speciy between two and our (dierent) requirements on the kind o characters. In our example, since no cardinality was speciied or the group o expiration policies, the cardinality 1 1 is assumed (i.e., the expiration policies orm an exclusive-or group). The security proile also has zero or more permission sets. This is indicated with the eature cardinality [0.. ]. I a eature cardinality is [1..1], we draw a little illed circle above the eature. Observe that eatures belonging to a group do not have a eature cardinality. A permission set determines various permissions or executing code. In our simple model, a permission set has a string attribute to speciy its name, and

6 FeatureGroup groupcardinality Attribute type TypedValue * ContainableByFG ContainableByF * Feature name StringValue value IntValue value FeatureModel FDReerence * GroupedFeature SolitaryFeature eaturecardinality RootFeature 1 * Fig. 2. UML metamodel or cardinality-based eature models allows us to speciy permissions with respect to ile IO, ile dialogs, and environment variables. (Other examples would be permissions to access a database, invoke relection, access a Web address, etc.) According to our model, ile IO can be restricted to a list o ile paths, or it is unrestricted. For each ile path, we can speciy its name and associated read/write permissions. Notice that we use a eature diagram reerence or the permission model because we want to reuse it or environment variables. In this paper, we use a dashed line to represent a eature diagram reerence, but it should be noted that, in practice, a dierent representation may be necessary to avoid a convoluted diagram. This is especially important i the purpose o the eature diagram reerence is to modularize a large eature model over dierent diagrams. Finally, the permission to open a ile dialog and to close it can be selected independently. The empty circle above the eatures open and closed indicates that those eatures are optional (i.e., they have the eature cardinality [0..1]). 3.2 A Metamodel Now that we have seen an example o a cardinality-based eature model, we explain the available concepts more accurately by means o an abstract syntax model, where we will reer to the example in Fig. 1 or clariication. Consider the Uniied Modeling Language (UML) metamodel or cardinalitybased eature models in Fig. 2. A eature model consists o any number o root eatures, which orm the root o the dierent eature diagrams in the model. In the security proile example, both the eatures securityproile and permission are root eatures. A root eature is only one o three dierent kind o eatures. The other two are the grouped eature and the solitary eature. The ormer is a eature which can only occur in a eature group. For example, the eature never is a grouped eature in a eature group, which is contained by the eature expiration. A solitary eature is a eature which is, by deinition, not grouped in a eature group. Many eatures in a typical eature model are solitary; or example, the eature passwordpolicy and permissionset.

7 Features can have an optional attribute o a certain type, and those attributes can have an optional value. In this simpliied model, we only have integer and string attributes. Fig. 2 also has a class named FDReerence that stands or a eature diagram reerence. It can reer to only one root eature, but a root eature can be reerred to by several reerences. In the example, the eature permission is reerred to by two reerences. The abstract classes ContainableByFG and ContainableByF stand or those kind o objects that can be contained by a eature group and a eature, respectively. A eature group can contain only grouped eatures or eature diagram reerences, whereas a eature can contain only solitary eatures, eature groups, and reerences. A solitary subeature o a eature is qualiied by a eature cardinality. 4 It speciies how oten the solitary subeature (and any possible subtree) can be duplicated as a child o. A eature cardinality I is a sequence o intervals o the orm [n 1..n 1 ]...[n l..n l ], where we assume the ollowing invariants: i {1,...,l 1} : n i,n i N n l N n l N { } n N : n< 0 n 1 i {1,...,l} : n i n i i {1,...,l 1} : n i <n i+1 An empty sequence o intervals is denoted by ε. An example o a valid speciication o a eature cardinality is [0..2][6..6], which says that we can take a eature 0, 1, 2, or 6 times. Note that we allow the last interval in a eature cardinality to have as an upper bound the Kleene star. Such an upper bound denotes the possibility o taking a eature an unbounded number o times. For example, the eature cardinality [1..2][5.. ] requires that the associated eature is taken 1, 2, 5, or any number greater than 5 times. Semantically, the eature cardinality ε is equivalent to [0..0] and implies that the subeature can never be chosen in a coniguration. A eature group expresses a choice over the grouped eatures in the group. This choice is restricted by the group cardinality n n, which speciies that one has to select at least n and at most n distinct grouped eatures in the group. Given that k>0 is the number o grouped eatures, we assume that the ollowing invariant on group cardinalities holds: 0 n n k. At this point, we ought to mention that, theoretically, we could generalize the notion o group cardinality to be a sequence o intervals as we did or eature cardinalities. However, we have ound no practical applications o this usage, and it would only clutter the presentation. Grouped eatures do not have eature cardinalities because they are not in the solitary subeature relationship. This avoids redundant representations or groups and the need or group normalization that was necessary or the notation in Czarnecki s work [14]. For example, in that notation, an inclusive-or group 4 More precisely, a eature cardinality is attached to the solitary subeature relationship. This relationship is implicit in the metamodel.

8 with both optional and mandatory subeatures (corresponding to eature cardinalities [0..1] and [1..1] respectively), would be equivalent to an inclusive-or group in which all the subeatures were optional. Keeping eature cardinalities out o groups also avoids problems during specialization (see Section 4.3). For example, the duplication o a subeature with a eature cardinality [n..n ], where n > 1, within a group could potentially increase its size beyond the upper bound o the group cardinality. Even without the redundant representations or groups, there is still more than one way to express the same situation in our notation. For example, the ollowing two dierent diagrams are identical in their semantics. permission permission <0 2> read write [0..1] read [0..1] write Conceptually, we keep these two diagrams distinct and leave it up to a tool implementer to decide how to deal with them. For instance, it might be useul to provide a conversion unction or such diagrams. Alternatively, one could decide on one type o preerred orm which is shown by deault. In Appendix A, we discuss a comparison o the new cardinality-based notation with the FODA notation and the notation introduced in [2, 17]. For the sake o readability, we will keep using the latter notation whenever an appropriate equivalent exists. However, because the cardinality-based notation has no eature cardinality in groups, we will not use the illed circle on top o grouped eatures. 4 Staged Coniguration 4.1 Motivation A eature model describes the coniguration space o a system amily. An application engineer may speciy a member o a system amily by selecting the desired eatures rom the eature model within the variability constraints deined by the model (e.g., the choice o exactly one eature rom a group o alternative eatures). The process o speciying a amily member may also be perormed in stages, where each stage eliminates some coniguration choices. We reer to this process as staged coniguration. Each stage takes a eature model and yields a specialized eature model, where the set o systems described by the specialized model is a proper subset o the systems described by the eature model to be specialized. The need or staged coniguration arises in the context o sotware supply chains [7]. Let us take a look at an example based on a real scenario involving the coniguration and generation o basic services or electronic control units (ECUs) embedded in an automobile. Basic services such as tasking support, network drivers, network management, lash support, diagnosis, and so orth, are

9 implemented as components by dierent sotware vendors. A sotware vendor may deliver dierent conigurations o its component to dierent car manuacturers to relect the diering requirements o the individual manuacturers (such as dierent terminologies or provided interaces). Doing so constitutes the irst coniguration stage. In a second stage, each car manuacturer has to urther conigure the components or each dierent ECU in a car, depending on the needs o the control unctions (such as break control or engine management) to be installed on the given ECU. The second coniguration stage may be even more complex, as some global settings and available options may be determined by the manuacturer, while other settings may be provided by the suppliers o the control unctions. Finally, given a concrete coniguration, the code implementing the basic services is generated. Based on the outlined requirements, it should be possible to perorm coniguration in stages and to compose (possibly specialized) eature models. In general, supply chains require staged coniguration o platorms, components, and services. However, staged coniguration may be required even within one organization. For example, security policies could be conigured in stages or an entire enterprise, its divisions, and the individual computers. The enterpriselevel coniguration would determine the choices available to the divisions, and the divisions would determine the choices available to the individual computers. 4.2 Coniguration vs. Specialization A coniguration consists o the eatures that were selected according to the variability constraints deined by the eature diagram. The relationship between a eature diagram and a coniguration is comparable to the one between a class and its instance in object-oriented programming. The process o deriving a coniguration rom a eature diagram is also reerred to as coniguration. Specialization is a transormation process that takes a eature diagram and yields another eature diagram, such that the set o the conigurations denoted by the latter diagram is a true subset o the conigurations denoted by the ormer diagram. We also say that the latter diagram is a specialization o the ormer one. A ully specialized eature diagram denotes only one coniguration. Finally, staged coniguration is a orm o coniguration achieved by successive specialization ollowed by deriving a coniguration rom the most specialized eature diagram in the specialization sequence. In general, we can have the ollowing two extremes when perorming coniguration: a) deriving a coniguration rom a eature diagram directly and b) specializing a eature diagram down to a ull specialization and then deriving the coniguration (which is trivial). Please note that sometimes we might not be interested in arriving at one speciic coniguration. For example, a eature diagram that still contains unresolved variability could be used as an input to a generator. This could be useul when generating a specialized version o a ramework (which still contains variability) or when generating an application that should support the remaining variability at runtime.

10 4.3 Specialization Steps In Section 4.1, we described the process o staged coniguration as the removal o possible coniguration choices. In this section, we discuss in more detail what kind o coniguration choices can be eliminated. We will call the removal o a certain coniguration choice a specialization step. There are six categories o specialization steps: a) reining a eature cardinality, b) reining a group cardinality, c) removing a grouped eature rom a eature group, d) assigning a value to an attribute which only has been given a type, e) cloning a solitary subeature, and ) unolding a eature reerence. We discuss each o these possibilities in more detail below. Reining eature cardinalities. A eature cardinality is a sequence o intervals representing a (possibly ininite) set o distinct natural numbers. Each natural number in the cardinality stands or an accepted number o occurrences or the solitary subeature. Reining a eature cardinality means to eliminate elements rom the subset o natural numbers denoted by the cardinality. This can be achieved as ollows: 1. remove an interval rom the sequence; or 2. i an interval is o the orm [n i..n i ]wheren i <n i, (a) reduce the interval by increasing n i to n i or decrease the n i to n i as long as n i n i.in i =, then it is possible to replace with a number m such that n i m; or (b) split the interval in such a way that the new sequence still obeys the eature cardinality invariant and then reduce the split intervals. A special case o reining a eature cardinality is to reine it to [0..0] or ε. In either case, it means we have removed the entire subeature and its descendents. We leave it up to a tool to decide whether to visually remove eatures with eature cardinality [0..0] or ε. Reining group cardinalities. A group cardinality n 1 n 2 is an interval indicating a minimum and maximum number o distinct grouped eatures to be chosen rom the eature group. Its orm is a simpliication o a eature cardinality and can only be reined by reducing the interval (i.e., by increasing n 1 to n 1 and decreasing n 2 to n 2 as long as n 1 n 2 ). Currently, we do not allow splitting an interval because we have no representation or such a cardinality. O course, such an operation should be incorporated whenever we allow sequences o intervals or group cardinalities. Removing a grouped eature rom a eature group. A eature group o size k with group cardinality n 1 n 2 combines a set o k grouped subeatures and indicates a choice o at least n 1 and at most n 2 distinct grouped eatures. A specialization step can alter a eature group by removing one o the grouped

11 subeatures with all its descendents, provided that n 1 <k. The new eature group will have size k 1, and its new group cardinality will be n 1 min(n 2,k 1), where min(n, n ) takes the minimum o the two natural numbers n and n.the ollowing is an example specialization sequence where each step removes one grouped subeature rom the group: <2 3> <2 3> <2 2> It is not possible to remove grouped subeatures rom a eature group once n 1 = k. In that case, all subeatures have to be taken, and all variability is eliminated. Assigning an attribute value. An obvious specialization step is to assign a value to an uninitialized attribute. The value has to be o the type o the attribute. Cloning a solitary subeature. This operation makes it possible to clone a solitary subeature and its entire subtree, provided the eature cardinality allows it. Moreover, the cloned eature may be given an arbitrary, but ixed, eature cardinality by the user, as long as it is allowed by the original eature cardinality o the solitary subeature. Unlike the other specialization operations, cloning may change the diagram without removing variabilities. However, the new diagram will generally be more amenable to specialization, so we consider it a specialization step nonetheless. We explain this process with an example: 0 [2..2][4..*] [3..3] [1..*] 0 0 The eature cardinality [2..2][4.. ] o the original subeature 0 indicates that 0 must occur at least two times or more than three times in a coniguration. In the specialized diagram above, we have cloned 0 (to the let) and assigned it a new eature cardinality [3..3]. The original eature 0 (to the right) has a new cardinality that guarantees the new diagram does not allow conigurations

12 previously orbidden. In the example, because we have chosen to give the let 0 the ixed eature cardinality [3..3], the eature cardinality o the rightmost 0 has to be [1.. ]. Specialization has occurred since the new diagram does not allow a user to select only 0 two times. Consider another example: 1 [2..*] [2..2] [0..*] 1 1 In this case, no actual specialization took place. The cloned eature 1 to the let has been given the ixed cardinality [2..2]. However, because the original eature cardinality was [2.. ], the rightmost 1 now has cardinality [0.. ]. More generally, suppose I =[n 1..n 1 ]...[n l..n l ]and0<m.providedwehave (n l = ) (m n l < ), it is possible to clone the solitary subeature o with eature cardinality I as ollows: I [m..m] L(m,I) Given that we always have n = or any n N, we can deine the unction L (m, I) as ollows: L (m, ε) =ε i (m n) : [(n m)..(n m)]l (m, I) L (m, [n..n ]I) = i (n <m) (m n ) : [0..(n m)]l (m, I) i n <m : L (m, I) The reader may wonder why we only allow the cloned eature to be given a ixed eature cardinality. This is because, in general, it is impossible to construct a correct eature diagram by cloning a eature and giving it an arbitrary interval or sequence o intervals without some more expressive orm o additional constraints. However, there are a ew useul special cases or this situation that we do not consider in this paper and leave or uture work. Unolding a eature diagram reerence. Finally, we have a specialization step that allows the user to unold a eature diagram reerence. This basically means that we substitute the reerence or the entire eature diagram it reers to by means o its root eature. Although this operation never removes variability, we consider it a specialization step or the same reasons as mentioned above or

13 securityproile permissionset( Internet :String) passwordpolicy [0..*] permissionset(string) iledialog ileio expiration chars ileio iledialog <1 1> <1 1> <3 4> unrestricted environmentvariables indays (30:Int) open specialchar restricted close restricted lowercase digit [0..*] uppercase ilepath(string) environmentvariables open permission <0 1> read permission <0 2> read write Fig. 3. Sample specialization o the security proile the cloning o a solitary eature: it makes the new eature model potentially more amenable or specialization because each unolded eature diagram can now be specialized dierently. 4.4 Security Proiling Example Revisited Let us now apply the notion o staged coniguration to the security proile example rom Section 3.1. Assume, or instance, that the IT inrastructure o a company supports the security proile rom Fig. 1. The company then decides to specialize this proile to deine a standard enterprise-level security proile as depicted in Fig. 3. The specialization is achieved by a combination o steps rom Section 4.3. In the eature passwordpolicy, we have eliminated the ability to have a nonexpiring password and set the expiry time at 30 days. On top o that, the company requires at least three dierent kind o characters to be used instead o two. Moreover, we clone the eature permissionset and assign it the name Internet because we want to speciy a speciic permission set or programs running rom the Internet. In particular, we want ile IO to be restricted and allow no access to local ile paths. Moreover, ile dialogs may be allowed only to be opened, but Internet programs may be given the permission to read environment variables. Observe that we unolded the permission eature diagram reerence under the environmentvariables eature. I desired, the enterprise-level security proile could be urther specialized by individual departments and then or individual computers within the departments.

14 5 Feature Models as Context-Free Grammars The semantics o a eature model can be deined by the set o all possible conigurations. A coniguration itsel is denoted by a structured set o eatures chosen according to the inormal rules o interpretation o eature diagrams. Although this description is suicient in practice, it is helpul to provide a ormal semantics to improve the understanding o some o the intricacies o eature modeling. For example, a ormal semantics allows us to deine exactly what it means when two apparently dierent eature models are equivalent (i.e., denote the same set o conigurations). More interestingly, i eature model specialization maps to the semantic interpretation o a eature model, it would be possible to ormally establish that eature model specialization reduces the set o possible conigurations. Our approach to obtaining such a semantics is to cast eature models back into a well-known ormalism: context-ree grammars. The semantic interpretation o a eature diagram then coincides with a natural interpretation o the sentences recognized by the grammar. It is beyond the scope o this paper to provide a detailed account o exactly how a eature model can be translated into a context-ree grammar, but the interested reader is invited to examine the details in an accompanying technical report [18]. We have to mention that eature diagrams, as they are presented in this paper, can actually be modeled as regular grammars 5 and do not require the additional expressiveness o context-ree grammars. The main reason to use contextree grammars instead is purely or convenience. It is not only possible to speciy cardinality-based eature models as a contextree grammar. Feature model specialization can be mapped onto a set o operations on the context-ree grammar. Those operations are such that it is possible to determine that the set o all conigurations o a specialized eature model is never greater than the set o conigurations o the original eature model. 6 Conclusion and Future Work Cardinality-based eature modeling provides an expressive way to describe eature models. Staged coniguration o such cardinality-based eature models is a useul and important mechanism or sotware supply chains based on product lines. AmiEddi [21,22] was the irst editor supporting the eature modeling notation rom [2]. As a successor o the irst prototype, CaptainFeature [19,20] implements a cardinality-based notation that is similar to the one described in this paper. In uture work, we plan to extend our model with external constraints and reerence attributes [13]. Meanwhile, commercial tools supporting variant coniguration or product lines are starting to emerge (e.g., GEARS [23] and Pure::Consul [24, 25]). Pure::Consul is even directly based on FODA-like eature modeling. More 5 Regular grammars require that the right-hand side o a production can only have one terminal possibly ollowed by a nonterminal.

15 advanced capabilities such as staged coniguration and cardinality-based eature modeling still need to be addressed by these tools. The study o specialization at the grammar level [18]) has helped to better understand possible specialization steps at the diagram level. In act, such an analysis has revealed specialization steps other than those described in Section 4.3. Some o them can be quite involved, and some cannot even be translated back into the concrete syntax o the proposed eature diagram notation. The current specialization steps in this paper (Section 4.3) are an attempt to balance simplicity and practical relevance. We think that specialization and direct coniguration should be two distinct procedures. Although any desired coniguration can be achieved through specialization, specialization oers iner grained steps that would be unnecessarily tedious or direct coniguration. We already have experience with tool support or coniguration based on existing tool prototypes: ConigEditor [13] and CaptainFeature [19, 20]. Both support coniguration in a strictly top-down manner. This contrasts with our approach where staged coniguration o a eature model can be achieved in an arbitrary order. Adequate tool support or the newly introduced cardinality-based eature notation as well as its specialization is under way. Acknowledgements We would like to thank Michal Ankiewicz or ruitul discussions about the metamodel presented in this paper. We also would like to thank Thomas Bednasch or his work on CaptainFeature, which helped us to advance our understanding o eature modeling. Reerences 1. DeBaud, J.M., Schmid, K.: A systematic approach to derive the scope o sotware product lines. In: Proceedings o the 21st International Conerence on Sotware Engineering (ICSE), IEEE Computer Society Press (1999) Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley (2000) 3. Bosch, J.: Design and Use o Sotware Architecture: Adopting and evolving a product-line approach. Addison-Wesley (2000) 4. Weiss, D.M., Lai, C.T.R.: Sotware Product-Line Engineering: A Family-Based Sotware Development Process. Addison-Wesley (1999) 5. Cleaveland, C.: Program Generators with XML and Java. Prentice-Hall (2001) 6. Batory, D., Johnson, C., MacDonald, B., von Heeder, D.: Achieving extensibility through product-lines and domain-speciic languages: A case study. ACM Transactions on Sotware Engineering and Methodology (TOSEM) 11 (2002) Greenield, J., Short, K.: Sotware Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley (2004) To be published. 8. Deursen, A.v., Klint, P.: Domain-speciic language design requires eature descriptions. Journal o Computing and Inormation Technology 10 (2002) 1 17

16 9. Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S.: Feature-oriented domain analysis (FODA) easibility study. Technical Report CMU/SEI-90TR -21, Sotware Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (1990) 10. Griss, M., Favaro, J., d Alessandro, M.: Integrating eature modeling with the RSEB. In: Proceedings o the Fith International Conerence on Sotware Reuse (ICSR), IEEE Computer Society Press (1998) Lee, K., Kang, K.C., Lee, J.: Concepts and guidelines o eature modeling or product line sotware engineering. In Gacek, C., ed.: Sotware Reuse: Methods, Techniques, and Tools: Proceedings o the Seventh Reuse Conerence (ICSR7), Austin, USA, Apr.15-19, LNCS 2319, Springer-Verlag (2002) Barbeau, M., Bordeleau, F.: A protocol stack development tool using generative programming. In Batory, D., Consel, C., Taha, W., eds.: Proceedings o the ACM SIGPLAN/SIGSOFT Conerence on Generative Programming and Component Engineering (GPCE 02), Pittsburgh, October 6-8, LNCS 2487, Springer- Verlag (2002) Czarnecki, K., Bednasch, T., Unger, P., Eisenecker, U.W.: Generative programming or embedded sotware: An industrial experience report. In Batory, D., Consel, C., Taha, W., eds.: Proceedings o the ACM SIGPLAN/SIGSOFT Conerence on Generative Programming and Component Engineering (GPCE 02), Pittsburgh, October 6-8, LNCS 2487, Springer-Verlag (2002) Czarnecki, K.: Generative Programming: Principles and Techniques o Sotware Engineering Based on Automated Coniguration and Fragment-Based Component Models. PhD thesis, Technical University o Ilmenau, Ilmanau, Germany (1998) Available rom Hein, A., Schlick, M., Vinga-Martins, R.: Applying eature models in industrial settings. In Donohoe, P., ed.: Proceedings o the Sotware Product Line Conerence (SPLC1), Kluwer Academic Publishers (2000) Svahnberg, M., van Gurp, J., Bosch, J.: On the notion o variability in sotware product lines. In: Proceedings o The Working IEEE/IFIP Conerence on Sotware Architecture (WICSA). (2001) Riebisch, M., Böllert, K., Streiterdt, D., Philippow, I.: Extending eature diagrams with UML multiplicities. In: 6th Conerence on Integrated Design & Process Technology (IDPT 2002), Pasadena, Caliornia, USA. (2002) 18. Czarnecki, K., Helsen, S., Eisenecker, U.: Formalizing cardinality-based eature models and their staged coniguration. Technical Report 04-11, Departement o Electrical and Computer Engineering, University o Waterloo, Canada (2004) Bednasch, T.: Konzept und implementierung eines konigurierbaren metamodells ür die merkmalmodellierung. Diplomarbeit, Fachbereich Inormatik, Fachhochschule Kaiserslautern,Standort Zweibrücken, Germany (2002) Available rom dt_bednasch.pd (in German). 20. Bednasch, T., Endler, C., Lang, M.: CaptainFeature ( ) Tool available on SourceForge at Selbig, M.: A eature diagram editor analysis, design, and implementation o its core unctionality. Diplomarbeit, Fachbereich Inormatik, Fachhochschule Kaiserslautern,Standort Zweibrücken, Germany (2000) 22. Mario Selbig: AmiEddi ( ) Tool available at generative-programming.org. 23. Krueger, C.W.: Sotware mass customization. White paper. Available rom http: // (2001)

17 24. pure-systems GmbH: Variant management with pure::consul. Technical White Paper. Available rom (2003) 25. Beuche, D.: Composition and Construction o Embedded Sotware Families. PhD thesis, Otto-von-Guericke-Universität Magdeburg, Germany (2003) Available rom A Overview o Feature Modeling Notations The cardinality-based eature modeling notation o this paper is a continuation o existing modeling notations [2, 17]. Table 1 compares the current proposal with the extended notation rom [2, 17] and the FODA notation. Table 1 compares three dierent notations or eature diagrams. The letmost column shows the FODA notation [9] which has mandatory ( 1 ), optional ( 2 ), and alternative subeatures ( k... 1 ). In the extended notation [2,14], depicted in the middle column, alternative groups come in two lavors: inclusive-or and exclusive-or groups. Moreover, an exclusive-or group can also have optional subeatures. The right column shows some possibilities o the cardinality-based notation that have an equivalent diagram in the extended notation. O course, the cardinality-based notation allows or many additional eatures and eature groups that cannot be expressed in either the FODA notation or the extended notation. However, to improve readability, we suggest using the extended notation o the middle column whenever possible, except or the use o illed circles above grouped eatures that belong to a eature group. A eature modeling tool may provide the appropriate syntactic sugar or those cases.

18 Table 1. Comparison o eature modeling notations FODA notation Extended notation Cardinality-based in [9] in [2, 14] notation mandatory and optional mandatory and optional mandatory and optional subeatures subeatures subeatures [1..1] [0..1] alternative subeatures exclusive-or group group with cardinality 1 1 <1 1> k 1 k 1 n/a inclusive-or group group with k 1 cardinality 1 k <1 k> k 1 k 1 n/a exclusive-or group with group with optional subeatures cardinality 0 1 <0 1> k 1 k 1