Professional Documents
Culture Documents
SPL Chapter For IGI-Final
SPL Chapter For IGI-Final
1 Introduction
Designing, developing and maintaining a good software system is a challenging task still in this 21st
century. The approach of reusing existing good solutions for developing any new application is now one
of the central focuses of software engineers. Building software systems from previously developed
components saves cost and time of redundant work, and improves the system and its maintainability. A
new software development paradigm, software product line [1], is emerging to produce multiple systems
by reusing the common assets across the systems in the product line. However, the idea of product line is
not new. In 1976 Parnas [2] proposed modularization criteria and information hiding for handling product
line.
A software product line is a set of software-intensive systems sharing a common, managed set of features
that satisfy the specific needs of a particular market segment or mission and that are developed from a
common set of core assets in a prescribed way [1]. Core assets are the basis for software product line. The
core assets often include the architecture, reusable software components, domain models, requirements
statements, documentation and specifications, performance model, etc. Different product line members
may differ in functional and non-functional requirements, design decisions, run-time architecture and
interoperability (component structure, component invocation, synchronization, and data communication),
platform, etc. The product line approach integrates two basic processes: the abstraction of the
commonalities and variabilities of the products considered (development for reuse) and the derivation of
product variants from these abstractions (development with reuse) [3].
1
The main idea of software product line is to explicitly identify all the requirements which are common to
all members of the family as well as those that are different, and then arrange them in a model. This
implies a huge model which will help the stakeholders to be able to trace any design choices and
variability decisions as well. Finally, the derivation of the product is done by selecting the required
variants from the model and configuring them according to product requirements.
Common requirements among all family members are easy to handle as they simply can be integrated
into the family architecture and are part of every family member. But problem arises from the variant
requirements among family members. Variants are usually modeled using feature diagram, inheritance,
templates and other techniques. In comparison to analysis of a single system, modeling variants adds an
extra level of complexity to the domain analysis. In any product line model, the same variant has
occurrences in different domain model views. Different variants have dependencies on each other. Tracing
multiple occurrences in different model views of any variant and understanding the mutual dependencies
among variants are major challenges during domain modeling. While each step in modeling variant may
be simple but problem arises when the volume of information grows. As a result, the impact of variant
becomes ineffective on domain model. Therefore, product customization from the product line model
becomes unclear and it undermines the very purpose of domain model.
tree according to product requirements and customized product can then be derived from these selected
features. While deriving this product, the decision table is required to handle various features and their
dependencies. However, defining such table involves manual handling of variants and hence, formal
verification is not directly admissible for such approach.
We use logical representation of feature models facilitating the development of decision table in a
formally sound way. We define six types of logical notation to represent all the parts in a feature model.
First-order logic has been used for this purpose. These notations are used to define all possible scenarios
of a feature model. It is often leveled that manual verification leads to numerous error for large models
and often misses the minute detail in the verification. To overcome this problem we use the model
checker Alloy [5]. We encode our logical definitions into Alloy and check the validity of the logical
verification that we perform by hand.
Although such modeling technique supports sound formal definition, it still lacks the ontological and
sharable knowledge description of the features and concepts. To capture domain knowledge and common
vocabularies in any field ontology has shown itself an acceptable paradigm [6]. It is also necessary to
process and exploit knowledge in a computer system. Among the various available approaches for
knowledge representation, ontologies appear to be a promising solution due to its ability to make the
domain knowledge computer readable and processable. Besides various inference algorithms and tools
are available to infer new knowledge from the existing, Semantic Web technology can provide a
meaningful and shared ontological description of the domain. Web Ontology Language (OWL) [7] is one
of the most expressive languages for specifying, publishing and sharing ontologies. It also provides
proper mechanism to exploit the potential of Semantic Web by prescribing how data are defined and
related. Importantly, OWL not only facilitates better machine interoperability than that of XML, RDF,
RDFS etc. but also has formal semantics and support for defining additional vocabulary. It is therefore
evident that semantic web technology, OWL in particular, can be used to represent a particular domain
and define the relationship of various features within that domain. Among the various available dialects,
this paper uses OWL-DL which is based on Description Logic (DL) [8].
We present a case study of Hall Booking System product line. We analyze and model the variants as well
as the variants dependencies and perform our proposed verification techniques.
Modeling Variants
Though it is possible to create a software system family without developing a distinct variability model
where the domain is well understood by all members (i.e. developer, stakeholders), the variability model
offers some potential advantages:
It provides a distinct document characterizing all the variants of the family as a whole for both domain
engineers and stakeholders interested in the product line.
It has a place for recording the selection and application related decision of each variant which is part
of a family and provides support to implement any member product.
The required variant of any particular product can be validated and verified by it.
While developing the variability model, we have some objectives to be met by the model. The model
should specify both the commonalities and variants of the family members. In the case of variants, it
should contain their application areas, constraints, possible values, dependencies, etc. Along with these
objectives, the variability model should contain the customization and configuration structure of each
variant of the system family which will guide the application engineer to generate any product from the
system family.
requires and exclude. A part of the feature tree of Hall Booking System is shown in Fig. 3. Extensions of
feature diagram described in [11] have been used here.
Some variants are used by all the family members of the product line while other variants and some
values of some variants are only applicable for particular members.
Variants may have prerequisites and/or post requisites. The existing methods can express them but
situation becomes complex when dependencies increase.
When new information is added/deleted/modified, it may have impact on several others variants, so
we need an easy way to handle for large number of impacts.
All information like this can be represented using FODA or other methods but need extra annotation with
the model which will sometimes become complex and difficult to handle. The table approach that we
present here depicts all the information that are described by FODA as well as those that have just
mentioned above. This table, which is actually a categorization table, will help us selecting variants
during application engineering process. A part of the table is given here in Table 1, depicting some of Hall
Booking Systems variants, their type, values, sub domain, relationship as well as dependencies.
Table 1. Partial variant model of Hall Booking System
common characteristics and behavior of variants we arranged the variants in a tabular format. The table
contains the following information.
The column Variant shows the name of the variants which have some values and each variant is given a
unique number to refer it in order to locate the dependency. Variants are given name corresponding to the
function they are involved.
The column Variant Type indicates the type of variants. A variant is either Mandatory or Optional. A
Mandatory variant remains in all the products of the domain and hence it will be selected each time
during customization. On the other hand an Optional variant is not present in all the products of the
domain. They can be either selected or not during customization. The presence or absence of Optional
variants during customization depends on the product for which the customization is performed.
The possible values or choices of the each variant are depicted in the column Variant Value. The values
are numbered followed by their variant numbers in order to trace variant dependencies. The Sub
Domain column is used to designate the applicable product area of the particular value of the variant. If
any variant is present in all the products then the term All will be in the column, otherwise the name of
the applicable area is given. As some variants and their values are only applicable to certain products this
column will guide the selection process faster.
The column Relation among values indicates the relationship among the values of the variant. These
relationships are used to select one or more values from the listed values of the variant. There are two
types of relationship among the values Alternative and OR. Alternative means variant values are
mutually exclusive to each other, so that only one of them will be selected and if the relationship is OR
then it means that one or more values can be selected from the list.
The Dependency column shows whether the variant is dependent on any other variants or not. Here by
dependent we mean that if a variant B is dependent on a variant A then variant B will be selected only
when the variant A is selected. In this column the unique numbers of the variants or their values are used
to identify on which variant it depends.
Usually, there are some complex dependencies among variants, and feature diagrams cannot represent
them properly. Logic notations can be used to show the legal combination of variants in any given
member of product line. We used the notations given in [12]. In Table 2 we give a list of the types of
dependencies that we found useful to use in the dependency column of the table approach. The left hand
side of the table shows the notation to be placed in the dependency column of the variant and the right
hand column shows the meaning of that notation.
Table 2. Types of variant dependencies
By using the table, the customization process becomes very easy. The table shows all variants as well as
their types. Therefore, looking at the table at a glance it is easy to identify the variants which must be
present as well as those which need to be selected. The table shows the applicable sub domain (applicable
product) of each variant and their values. Hence, on the way of customizing any particular product it will
be very easy to select only those variants and values which are applicable to that product and those
variants which are not applicable can be discarded easily. The dependency information also helps in
customization steps. If a variant is to be selected for a product then the other variant(s) on which this one
depends will also be selected by just looking at the dependency column.
A decision table is made based on the table approach to guide the application engineer for a particular
product customization. A decision table is constructed based on the variant values. A brief description of
the construction of a decision table is given here. A decision table is derived from our tabular
variant model as follows:
For each variant we create a variable ranging over the possible values of the variant.
Where the inclusion or exclusion of variants depends on another variants value, these variants are
subordinated in the table.
For each decision, there is a name, brief description, range of values, and traceability number for
dependency tracing is given.
During domain modeling we can use the table which will assist variant customization process in a
convenient way,
When any particular sub domain is selected to customize from the generic model, the variants which
are applicable to the particular domain will be extracted from the table as well as their dependent
variants. These will relief the application engineer going through the long list of variants and finding
their dependencies
The required variants are then selected, instructed by the decision table .
A small part of the decision table is given in Table 3. In the table, each variant is placed in a column, its
description, possible choices and traces to the variant are shown in other columns. When the inclusion or
exclusion of a variant depends on another variant or its value(s) then that variant is placed in the
subordinate position showing the values for which it can be chosen. For example, Reservation Mode
variant has two possible values either Single or Block. So these two values are placed in the subordinate
position of the parent variant (Reservation Mode) in the decision table. Similarly when Block reservation
is to be considered then it needs to check its values (Multiple Room and Multiple Time) and these values
along with their other information will be also be subordinated. For each variant and for each of their
values, the decision table can have a corresponding entity.
By using the proposed variability model, it is now possible to derive any member product from the
system family model according to the users requirements. In the proposed variability model, all the
possible variants are added to the default models, which help the developer to select the proper variants
according to the users requirements. Suppose there is a need for a Hall Booking System for the university
purpose where the user wants to be notified by printed paper and there is no need to handle conflicts when
a reservation is not available. When the developer gets the above requirements, the required variants are
extracted from the variant model. As the required system is for the academic purpose, those variants
which are only for non-academic purposes like reservation charge are discarded. Using the variant
dependency information given in the variant model, other dependant variants are also extracted along
with the required variants. So the developer does not need to check all the dependencies of the system
family. This results a smaller variant table model as shown in Table 4.
Similarly, the decision table is also reduced containing only the decisions for the required features. By
using the decision table, the user can take decisions on variants. Suppose the user wants to reserve a hall
for multiple time slots. Using the dependency information of the decision table and the variant model, it is
clear that if this variant is required then there is a need to choose the reservation mode to Block.
Following this way the developer can select the proper variants according to the requirements and
consequently can derive the proper product model, from where the developer can develop the required
customised product in a suitable developing language.
10
Variant
Values of variant
V1.
V1.1 Single
Reservation Mode
V3.
V1.2 Block
V3.1 Multiple Room
Block Reservation
V4.
Notification
Relations
Applicable
Area
Dependency
All
None
All
V1.2
All
None
Alternativ
e
OR
3 Logic-based Representation
A feature model is a hierarchically arranged set of features. It represents all possible products of a
software product line in a single model. The relation between a parent (variation point) features and its
child features (variants) are categorized as Mandatory, Optional, Alternative, Optional Alternative, Or,
and Optional Or. The logical representation of feature models facilitates the development of decision
table in a formally sound way. We define six types of logical notation to represent all the parts in a feature
model using first-order logic. These notations are used to define all possible scenarios of a feature model.
The logical notions of these features are defined in Fig. 5.
A feature model (e.g. Fig. 3) can be considered as a graph consists of a set of sub-graphs. Each sub-graph
is created separately by defining a relationship between the variation point (denoted as vi) and the
variants (vi.j) by using the expressions shown in Fig. 5. The complexity of a graph construction lies in the
definition of dependencies among variants. When there is a relationship between cross-tree (or cross
hierarchy) variants (or variation points) we denote it as a dependency. Typically, dependencies are either
inclusion or exclusion: if there is a dependency between p and q, then if p is included then q must be
included (or excluded). Dependencies are drawn by dotted lines.
11
vi . j
v i ) and
cross hierarchy) variants (or variation points) is denoted as a dependency. There are two types of
dependencies considered in this paper, inclusion and exclusion: if there is a dependency between p and q,
then if p is included then q must be included (or excluded). Dependencies are drawn by dotted lines.
Scenario 1: If there is a require relation between variants
v2
is elected whenever
v1
v
v 1 , v 2 type ( v1 , variant ) type ( v 2 , variant ) require v 1 , v 2 select ( v 1) select (v 2)
vp
v 1 , v 2 type ( v1 , variation point ) type ( v 2 , variationpoint ) require v1 , v 2 select (v1 ) select (v 2 )
Where
type(vi )
selection of
vi
indicates
and
vi
require( )
select ( vi )
indicated the
12
rest of the rules definition. Due to this dependency rule the dependant variant, v2 here, will always be
selected if v1 is selected and such selection will not be affected by the type of relationship such as
Alternative, with their parent
Scenario 2: From Fig. 6(b), we derive the following rule,
Scenario 4: When there is an exclude relation between variants (and/or variation point) as shown in
Fig. 6(d), only one among them can be selected at a time.
Here v1 and v2 are variants in the left figure and variation point in the right part of the figure. In both
cases, as there is exclude relationship between them only one can be selected at a time. Here, we can
suggest that for such scenario the relationship among the variants or variation points must be Alternative
to keep the feature model well-formed. Similar to previous example, we define rules for such
dependencies.
v
v 1 , v 2 type ( v 1 , variant ) type ( v 2, variant ) exclude v 1 , v 2 select (v 1) notselect ( v 2)
vp
v 1 , v 2 type ( v 1 , variation p oint ) type(v 2 , variation point)exclude v 1 , v 2 select (v 1) notselect ( v 2)
Scenario 5: From Fig. 6(e) we derive the following rule,
v 1 , v 2 , x , y type ( x , vari ant ) type(v 1 , variation point)type ( v 2 , variation point ) exclude v vp ( x , v 2 ) sele
Scenario 6: The scenario in Fig 6(f) depicts the following rule,
vp
v 1 , v 2 , x , y type ( x , variant ) type( y , variant )variant ( v 1 , x ) variant ( v 2 , y ) common( y , yes) require
13
Figure 5.(a) Inconsistency checking; (b) False optional feature detection and (c) Dead feature detection
v1
and
v 2.1
v , v1
and
and
v 2.2
v2
are of
v 1.1
and
v 1.2
v 1.2 and variation point v 2 . As v 1.1 and v 1.2 are mandatory feature whenever
variant
are
v1
the same time and it introduces an inconsistency into the feature model.
False optional is a situation where a feature is declared as optional which does not need so. In Fig. 7(b),
v2
is False optional. There is a require dependency between the variant v1.2 and the variation point
v2. Here
v2 is selected. Although it is an optional feature it will be always selected, hence we call it as a false
optional feature. If the relation is an exclude relationv2 will never be selected
Dead feature is a feature that never appears in any legal product from a feature model. As shown in Fig.
7(c) due to exclude relation
v 2.1 will never be part of any valid product from the feature model.
14
sub-graphs.
G1 , G2
and
G3
variant dependencies are not yet considered in this case. Checking the validity of each sub-graph is not
enough for the validity of the whole model. Variant dependencies must also be checked as additional
constraints. We evaluate the dependencies of the selected variants and we get,
Dependency:
15
( T T ) (T T )=T
The truth (T) value of the dependencies ensures the validity of the product instance
Example 2: Suppose the selected variants are,
these input combination build a valid product we check the validity of the sub-graph
G1 , G2
and
Due to conflict within variant dependencies, the whole graph becomes invalid, which is due to an
incorrect selection of input.
sig FM {
features: set Name,
root: feature,
relation: set Relation,
form: Formula
}
sig Name{}
sig Relation{
parent: Name,
child: set Name,
type: Type
}
abstract sig Type{}
one sig Optional, Mandatory, OrFeature,
16
3.5 Examples
We show how the feature diagram in Fig. 8(a) can be constructed from the syntax and semantics defined
in previous section. The feature diagram consists of three sub-graphs. First we define the overall diagram
by using the sub-graphs and their relations and then define the parent-children relations.
one sig G extends FM{}
one sig c1,c2,c3 extends Relation{}
fact elements {
G.root = v
G.feature = G1 + G2 + G3
G.relation = c1 + c2 + c3
}
The parent-child relationship of v1, v2 and v3 as well as their types are defined as follows,
fact relations{
c1.type = Mandatory
c1.parent = v
c1.child = v1
c2.type = Mandatory
c2.parent = v
c2.child = v2
c3.type = Optional
c3.parent = v
c3.child = v3
}
By following the similar steps, each of the sub-graphs can be defined as well. For example, sub-graph G1
along with its child and their types are defined as follows,
one sig G1 extends FM{}
one sig r1 extends Relation{}
fact element{
G1.root = v1
G1.features = v1_1 + v1_2
G1.relation = r1
}
fact relations{
r1.type = Alternative
r1.parent = v1
r1.child = v1_1 + v1_2
}
The sub-graphs G2, G3 and their relations as well as types can also be defined in the same approach.
Alloy checks the consistency of the sub-graphs and variant dependencies and shows that a valid instance
is found. If we select another combination of features as in Example 2 in earlier section, an invalid
18
product would be created and hence in instance should be found. Alloy produce an error stating that no
instance is found from the selected features. Currently, we are performing various other analysis
operations mentioned in [15, 16].
4 Knowledge-based Representation
Various feature relations are modeled using OWL language constructs. By using OWL-DL we model six
types of relations, namely mandatory, optional, alternative, or, optional alternative and optional or. Two
additional constraints: requires and excludes are also modeled. Modeling feature models using OWL have
several advantages, such as facilitating feature model storing, sharing and distributing and assisting
cooperative designing.
First, OWL ontology is built for various nodes and edges in the feature model. The ontology is
constructed in a number of steps.
Step1: We identify the nodes (concepts and features) present in a feature diagram. Each node in the diagram is
modeled as an OWL class. Moreover, we assert that these classes are mutually disjoint. In OWL, all
classes are assumed to overlap unless it is otherwise stated that they are disjoint with each other using a
disjoint axiom. By default, we assume that features with different names are distinct.
Step 2: For each of these nodes in the diagram, we create a Rule class. This Rule class has two kinds of
conditions: firstly, a necessary and sufficient (NS, EquivalentClass) condition, using an existential
restriction to bind the Rule node to the corresponding feature node in the diagram; and secondly, a
number of (possibly 0) necessary (N, subClassOf) constraints later, serving two purposes:
To specify how each of its child features is related to this node, capturing the various relations between
features. To specify how this feature node is constrained by other features, in the form of requires,
excludes, Optional Alternative and Optional Or.
Step 3: The root concept and features in a feature diagram are interrelated by various feature relations,
represented by different edge types in the diagram. In our OWL model, for each of these edges, we create
an object-property. We assert that the range of the property is the respective feature class.
Table 5.Summary of OWL syntax
Notations
Explanation
Superclass of all OWL classes
A B
A is a subclass of B
A B
A B
Class intersection
A B
Class union
A B
Class equivalence
19
The OWL syntax used in this chapter is summarized in Table 5. For a parent feature A and for each of
its child features B1, B2. . ., Bn, the initial modeling produces the following ontology.
hasA ObjectProperty
ARule
hasAA
ARule hasAA
Bi
hasBi ObjectProperty
Bi Rule
hasBi Bi
Bi Rule hasBi Bi
A B i, for 1 i n
B i B j , for 1 i , j n i= j
Now we are ready to model the feature relations using the ontology. The general definition of each of
the four feature relations will be shown, based on the above feature ontology. The ontology will be
constructed incrementally to show the modeling of various feature relations and addition constraints
Mandatory
A mandatory feature is included if its parent feature is included. For each of the mandatory features
B 1 , B2 , ... , B n
someValuesFrom restriction on hasBi, stating that each instance of the rule class must have some instance of
Bi class for
has Bi . The following ontology fragment shows the modeling of mandatory feature set and
parent feature A.
ARule hasB i Bi
It can be seen fromFig. 3 that the root node has a mandatory child feature Reservation Mode, which is
itself a non-leaf node. We create two new classes (parent and child) for these two non-leaf nodes.
For parent feature:
HallBooking
HallBookingRule
hasHallBooking ObjectProperty
hasHallBookingHallBooking
HallBooking has HallBooking HallBooking
hasReservMode ObjectProperty
has ReservMode ReservMode
ReservMode Rule hasReservModeReservMode
HallBookingRule hasReservModeReservMode
(This line means that Reservation mode (ReservMode) is a mandatory child)
Optional
An optional feature may or may not be included in a diagram, if its parent is included. For each of the
optional features B1, B2, . . ., Bn of a parent feature A, no additional statement is required to model this
relationship. In that case they are denoted by,
Bi
BiRule
has BiObjectProperty
BiRule hasBiBi
Reservation Charge is an optional feature of Hall Booking and it may, or may not be included in a
configuration of Hall Booking System. As it is a non-leaf node, we create one new class ReservCharge for
Reservation Charge and one object-property hasReservCharge. The ontology is augmented as follows. Note
that no new restriction on HallBooking is added.
ReservCharge
ReservChargeRule
hasReservCharge ObjectProperty
ReservChargeRule hasReservCharge ReservCharge
Alternative
One and only one feature from a set of alternative features can be included, if their parent feature is
included in a configuration. Hence, for a set of alternative features Bi and Bj are two children of parent
feature A, we use disjunction of someValuesFrom restrictions over hasBi and hasBj to ensure that some
feature will be included. We use the complement of distributed disjunction of the conjunction of two
someValuesFrom restrictions to ensure that only one feature can be included. The Or symbol
Fig. 3 shows that features Block and Single are alternate features of Reservation mode. We model this
relation as follows.
ReservMode
ReservModeRule
hasReservModeObjectProperty
hasReservModeReservMode
ReservModeRule has ReservModeReservMode
Block
hasBlockObjectProperty
BlockRule
hasBlock Block
BlockRulehasBlockBlock
ReservModeRulehasBlockBlock
Single
hasSingleObjectProperty
SingleRule
hasSingle Single
SingleRulehasSingle Single
21
ReservModeRulehasSingle Single
RmRule ((hasBlockBlock) (hasSingleSingle))
RmRule (( has BlockBlock) (hasSingleSingle))
The last two restrictions ensure that one and only one feature from the set of alternative features can be
included.
Or
At least one from a set of available features is included, if the parent feature is included. For a set of or
features B1,B2,, Bn of a parent feature A, we need to use a disjunction of someValuesFrom restrictions to
model this relation.
hasReservCharge ObjectProperty
ReservChargeRule hasReservCharge ReservCharge
hasDeposit ObjectProperty
hasDepositDeposit
DepositRule hasDepositDeposit
ReservChargeRule hasDepositDeposit
hasB ObjectProperty
BRulehasBB
hasCObjectProperty
CRulehasCC
Optional Alternative
One feature from a set of alternative features may or may not be included if parent is included. Suppose A
is parent feature of child features B and C. We can write the OWL-DL representation as follow:
A
ARule
hasAObjectProperty
hasAA
ARulehasAA
B
hasBObjectProperty
BRule
BRulehasB B
C
hasCObjectProperty
CRule
CRulehasCC
ARule (( has BB) (hasC C))
ARule (( has BB) (hasC C))
Requires
A feature may depend on some other features; hence its presence in a feature configuration requires the
appearance of the others. For a given feature A and a set of features B1, B2. . ., Bn that A requires, besides
the NS condition that binds ARule to A, we make sure that each of the Bi features appears in a
configuration if A is present.
ARule hasBiBi
In Fig 3, if Fax feature requires Printed-Paper, then its OWL representation is as follows.
FaxRule
FaxRule hasFaxFax
Fax hasPrinted_PaperPrinted_Paper
Excludes
The presence of a feature may be inhibited by that of some other features. We say the appearance of a
feature in a configuration excludes the appearance of some other features. For a given feature A and a set
of features B1, B2,Bn that A excludes, we make sure, using the negation of someValuesFrom restriction
on hasBi property, that Arule does not have any Bi feature.
ARule ( hasBiBi)
We encoded the OWL-DL models of the Hall Booking System features into Protg [17] tool. Protg
gives an immediate feedback to the encoded logic by showing the corresponding feature graph ensuring
the preliminary correctness of the syntax as shown in Fig.9.
23
hasB B restriction to
prevent the reasoning engine from inferring the existence of this feature in the configuration.
If an instance C of a concept is derived from a feature diagram with root concept A and a set of features
B 1 , B2 , . . ., Bn , assuming that
B 1 , B2 , . . ., Bi
B i+1 ,. . . , Bn
do
C ARule
C ( has B j B j , for 1 j i) ( has B k Bk , for i<k n)
Suppose we have a configuration containing a concept instance E and some features of the feature
diagram. We call the instance node the class E.
E HallBookingRule
(hasT ax T ax )(hasRese rvCharge ReservCharge)
E
( hasBasicCharge BasicCharge)(hasReservMode ReservMode)
24
Let us consider a Requires relation between the features Discount and Block from Reservation
Charge and Reservation Mode respectively. A part of the figure is shown in Fig. 11, where the Requires
relation is shown by using a dotted line.
DiscountRule
DiscountRule hasDiscount Discount
25
E HallBooking
(hasReservCha rge ReservCharge)
E
( hasReservMode ReservMode )
( hasDiscount Discount )
( hasBlock Block )
5 Discussion
Successful development of software product line requires appropriate organization and management of
products requirements. A significant characteristic of developing product line is the management of the
variants. We have presented a unified approach to modeling variants of a product line. A variant model
has been presented in this chapter which explicitly represents all the variant related information
facilitating the generation of customized products from the domain model. The advantages of the tabular
method are its expressive power, ease of use, traceability, scalability, as well as support for separation of
concern. The tabular approach aloes offers some benefits of improving the variant handling process which
ease the customization process and reduce the complexities that arise due to handling of variants.
Modelling variants is considered as one the crucial factor for the successful deployment of software
product line. This chapter presented an approach to formalizing and verifying SPL feature models to be
able to create a customized product by using formal reasoning techniques. We provided formal semantics
of the feature models by using first-order logic and defined variant selection rules for various variant
scenarios and relationships. We also defined cross-tree variant dependencies. Examples are provided
describing various analysis operations, such as validity, inconsistency, dead feature detection etc. Such
formal definition supports automated decision making during product customization. The various analysis
operation suggested in [15, 16] are also addressed here. To overcome the hurdles of by-hand verification,
we encode our first-order logic representation into Alloy that automatically checks the consistency of
feature configuration and validity of product instances.
We presented a verification approach of product line model by using semantic web technology. OWL-DL
is used to represent feature models and configuration in a concise and unambiguous way. Features are
26
represented as OWL classes and relations as properties. We presented on-going work of consistency
checking using RACER. A through consistency checking is currently undergoing. The OWL-DL
verification of the feature models of system family gives confidence of our previously defined variability
model.
A knowledge-based approach to specifying and verifying feature models is presented in [13]. Comparing
to that presentation, our definition relies on first-order logic which can be directly applied in many
verification tools as in [19]. In contrast to other approaches [14, 20, 21, 22, 23, 24], our proposed method
defines across-graph variant dependencies as well as dependencies between variation point and variants.
Our particular interest is developing a tool to automatically generate customized product based on user
requirement as in [25].
While most approaches applied FOL, very few used semantic web and ontology to model and analyze
feature model. Similar to our approach, OWL-DL has also being used in [26, 27] to analyze feature
diagram. Along with modeling feature using OWL-DL both of them proposed additional tool support to
design feature models. Comparing to these approaches we not only use OWL-DL not check feature
consistency, but also plan to check both domain and product level feature configurations to check the
analysis operations suggested in [15].
References
[1] P. a. N. Clements, L., Software product lines: practices and patterns, illustrated ed.: Addison-Wesley, 2002.
[2] Parnas, D.L.: Software fundamentals. Addison-Wesley Longman Publishing Co.,Inc., Boston, MA, USA
(2001) 193213.
[3] A. Hein, M. Schlick, and R. Vinga-Martins, "Applying feature models in industrial settings," Proceedings of
the first conference on Software product lines : experience and research directions: experience and research
directions, Denver, Colorado, United States, 2000.
[4] Ripon, S.: A unified tabular method for modeling variants of software product line. ACM SIGSOFT Software
Engineering Notes 37(3) (2012) 17. In Pulvermuller, E., Speck, A., Coplien, J., Hondt, M.D., Meuter, W.D.,
eds.:
[5] Jackson, D.: Alloy: a lightweight object modelling notation. ACM Trans. Softw. Eng. Methodol. 11(2) (April
2002) 256290.
[6] Zhang, S., Shen,W., Ghenniwa, H.: A review of internet-based product information sharing and visualization.
Comput. Ind. 54(1) (May 2004) 115.
[7] Horrocks, I., Patel-Schneider, P.F., Harmelen, F.V.: From shiq and rdf to owl: The making of a web ontology
language. Journal of Web Semantics 1 (2003) 2003.
[8] Baader, F., Calvanese, D., Mc Guinness, D.L., Nardi, D., Patel-Schneider, P.F., eds.: The description logic
handbook: theory, implementation, and applications. Cambridge University Press, New York, NY, USA (2003).
[9] Kang, K.C., Cohen, S.G., Hess, J.A., Novak,W.E., Peterson, A.S.: Feature-oriented domain analysis (FODA)
feasibility study. Technical report, Carnegie-Mellon University Software Engineering Institute (November
1990).
[10] Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: Form: A feature-oriented reuse method (FORM) with
domain-specific reference architectures. Ann. Softw. Eng. 5 (January 1998) 143168.
[11] Czarnecki, K., Eisenecker, U.W.: Generative programming: methods, tools, and applications. ACM
Press/Addison-Wesley Publishing Co., New York, NY, USA (2000)
27
[12] Y. C. Cheong and S. Jarzabek, "Frame-based method for customizing generic software architectures,"
presented at the Proceedings of the 1999 symposium on Software reusability, Los Angeles, California, United
States, 1999.
[13] A. O. Elfaki, S. Phon-Amnuaisuk, and C. K. Ho. Knowledge based method to validate feature models. In S.
Thiel and K. Pohl, editors, SPLC (2), pages 217225. Lero Int. Science Centre, University of Limerick,
Ireland, 2008.
[14] M. Janota and J. Kiniry. Reasoning about feature models in higher-order logic. In SPLC, pages 1322. IEEE
Computer Society, 2007.
[15] D. Benavides, A. R. Cortes, P. Trinidad, and S. Segura. A survey on the automated analyses of feature models.
In JISBD, pages 367376, 2006.
[16] D. Benavides, S. Segura, and A. R. Cortes. Automated analysis of feature models 20 years later: A literature
review. Inf. Syst., 35(6):615636, 2010.
[17] Noy, N.F., Sintek, M., Decker, S., Crubezy, M., Fergerson, R.W., Musen, M.A.: Creating semantic web
contents with protege-2000. In: Protg-2000. IEEE Intelligent Systems (2001. (2001) 6071.
[18] Haarslev, V., Mller, R.: Racer user guide and reference manual - version 1.7.6 (2002).
[19] J. Sun, H. Zhang, and H. Wang. Formal semantics and verification for feature modeling. In Proceedings of the
10th IEEE International Conference on Engineering of Complex Computer Systems, ICECCS 05, pages 303
312, Washington, DC, USA, 2005. IEEE Computer Society.
[20] D. S. Batory. Feature models, grammars, and propositional formulas. In J. H. Obbink and K. Pohl, editors,
SPLC, volume 3714 of LNCS, pages 720. Springer, 2005.
[21] D. Benavides, P. Trinidad, and A. Ruiz-Cortes. Automated reasoning on feature models. In Proceedings of the
17th international conference on Advanced Information Systems Engineering, CAiSE05, pages 491503,
Berlin, Heidelberg, 2005. Springer-Verlag.
[22] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed
variants. In R. Gluck and M. R. Lowry, editors, GPCE, volume 3676 of LNCS, pages 422437. Springer, 2005
[23] M. Mannion. Using first-order logic for product line model validation. In Proceedings of the Second
International Conference on Software Product Lines, SPLC 2, pages 176187, London, UK, 2002. SpringerVerlag.
[24] W. Zhang, H. Zhao, and H. Mei. A Propositional Logic-Based Method for Verification of Feature Models. In J.
Davies, W. Schulte, and M. Barnett, editors, Formal Methods and Software Engineering, volume 3308 of
LNCS, chapter 16, pages 115130. Springer Berlin / Heidelberg, 2004
[25] P. Trinidad, D. Benavides, A. Ruiz-Cortes, S. Segura, and A. Jimenez. Fama framework. In Proceedings of the
2008 12th International Software Product Line Conference, SPLC 08, pages 359, Washington, DC, USA,
2008. IEEE Computer Society.
[26] Wang, H.H., Li, Y.F., Sun, J., Zhang, H., Pan, J.: Verifying feature models using owl. Web Semantics. 5(2)
(June 2007) 117129.
[27] Noorian, M., Ensan, A., Bagheri, E., Boley, H., Biletskiy, Y.: Feature model debugging based on description
28