SEKE 2012 Proceedings - Knowledge Systems Institute

It means that throughout the development process, we have
to identify and describe where the products created by the
product line may differ in terms of the features they provide,
the requirements they fulfill, or even in terms of the underlying
architecture [5]. This flexibility is called variability and it is the
basis for the software product line engineering since it
represents the difference in each product produced by the
Software Product Line.
Different models have been proposed for specifying
Software Product Line, features models proposed in Feature-
Oriented Domain Analysis (FODA) approach [6] is one of the
most used [7]. Product line scoping is also an important phase
in product line engineering to d ecide not only what products to
include in a product line but also whether or not an
organization should launch the product line [8]. One approach
for product line scoping is product m ap [9] for selecting a
subset of products to be created by the product line . The
inspection techniques proposed use feature models and product
map. These m odels are further discussed in the following
sections.
A. Feature Models
Feature models are hierarchi cal models that capture the
commonality and variability of a Product Line. This feature -
oriented concept is based on the emphasis placed by the
method on identifying those featur es a user commonly expects
in applications domain.
The feature concept used for modeling the feature models is
that it is a prom inent distinctive user-visible aspect, quality, or
characteristic of software system [6]. The purpose of the
feature model is to represent the general capabilities for the
applications in the domain.
Feature Models are created using m andatory, optional,
alternatives and or features. The m andatory features represent
the features, which must be c ontained in every product created
by the product line. The optional features represents the
features which can be contained or not in the prod uct from the
SPL. Alternative features repres ent an alternative betw een two
or more others features so th at only one of them must be
contained in products from the SPL. And or features represent
an alternative betw een two or m ore features in w hich at least
one of them must be contained in the products from the SPL.
The feature m odels also have constraints elem ents:
implication and exclusion. Th e implication notation im plies
that if one feature is selected , some other feature must be
selected as well. The exclusion constraint indicates that two
features must not be selected in the sam e product so they are
mutually exclusive.
B. Product Map
The selection of optional or alternative features is not m ade
arbitrarily. It is usually made based on a number of objective s
or concerns that the end-user (and customer) has [6]. The
product map [9] aims to complement the feature model by
specifying the products, which are compliant with the software
requirements.
The product map lists all features available in the y-axis and
the products specified by the requirements in the x-axis. Every
product in the x-axis matches a list of features according to the
software product line requirements. Then the software product
line only creates the products specified in the requirements.
III. SOFTWARE PRODUCT LINE INSPECTION TECHNIQUE
A Software Product Line creates a set of products sharing
common features and features which differs from product to
product. Therefore, it is im portant to assure the quality of their
models, as they specify several products. A mapping study [10]
was conducted to obtain evidence about quality assurance
techniques for SPL models. M apping studies [10] are a formal
process that uses a methodology to identify all research related
to a specific topic [10]. U nlike informal literature review s,
mapping studies uses a scientific rigorous approach to assert an
efficient survey of the current knowledge.
The databases used for this mapping study were the IEEE
Xplore, ACM Digital Library and Scopus. Our formal process,
as well as all selected studies, is described in a Technical
Report [11]. The initial search returned a total of 841 papers, as
described in Table I. After the first filter, in w hich the title and
abstract from the selected papers were analyzed, it has been
filtered to 90 papers. In the second filter, it w as also analyzed
the introduction and conclusion from papers selected after the
first filter, resulting a total of 27 papers about quality assurance
techniques for SPL models.
The data extracted presented that 23 (85% ) papers used
model checking techniques, 3 (11% ) used ontologies for
modeling and model checking and code inspections were
presented in 2 papers (7%). Although the benefits of inspection
techniques [3] and the need for inspections tailored for SPL [4],
no inspection technique for assuring quality for softw are
product line models was identified [11].
TABLE I.
Database
PAPERS SELECTED IN THE MAPPING STUDY
Papers
returned for
the 1 st filter
Papers
selected after
the 1 st filter
Papers
selected after
the 2 nd filter
IEEE Xplore 88 22 5
ACM Digital
Library
482 28 10
Scopus 271 40 12
We have proposed a set of checklist based techniques,
named Software Product Line Inspection Techniques (SPLIT),
for verifying feature models and product map in comparison
with themselves and the software requirem ents specification.
The software requirem ent specification needs to enum erate
functional and non-functional requirem ents and the products
created by the software product line and its constraints. An
overview of SPLIT is presented in Figure 1:
658