SEKE 2012 Proceedings - Knowledge Systems Institute

cardinality. The heuristics suggests the construction of a table
(Table I) that keeps the traceability between features and
tasks/resources. This table is used to obtain the feature model.
TABLE I.
Element
TABLE OF TRACEABILITY BETWEEN FEATURES AND
TASKS/RESOURCES
Cardinality
Type
Value
Parent
Element
Feature
Add Photo Element [1..1] – Add Photo
Album Element [1..1] Add Photo Album
Store Photo Element [1..1] Add Photo Store Photo
Save Autom. Group Store Photo Save Autom.
Save by User Group Store Photo Save by User
Path Element [1..1] Store Photo Path
Photo Element [1..1] Store Photo Photo
Name Element [1..1] Save by User Name
According to the heuristics defined in this activity, optional
features are obtained from elements with cardinality [0..1],
while mandatory features are obtained from elements with
cardinality [1..1]. Elements involved in a means-end
relationship with cardinality become alternative features with
equivalent cardinality. The FM obtained from the SR model
depicted in Fig. 2 is shown in Fig. 3.
Figure 3. Feature model of MobileMedia
E. Feature Model Refinement
This is an optional activity to be executed if the FM needs
to be reorganized or if new features must be add ed, because
they were not present in the SR model. Reorganization is
required if the FM has repeated features, sub-features with
more than one parent or different features with the same
meaning. This activity can be performed as many times as the
domain engineer believes it is necessary. Our running example
is quite simple and did not require the execution of this activity.
F. Elaboration of Use Case Scenarios
The SPL use case scenarios are specified based on an
adaptation of the guidelines defined by Castro et al. [10]. This
activity obtains the PLUSS scenarios description for an SPL
from its SR model and feature model. The guidelines proposed
by Castro et al. in [10] are a mapping between i* models and
use case scenarios that are not specific for dealing with SPL
variability. We propose guidelines to map i*-c models to
PLUSS use case scenarios. As a result, some of the 10 previous
guidelines were removed; others were split into new ones.
In Step 1, all four guidelines were maintained, but a new
one was inserted (current Guideline 4) to deal with actors that
have only softgoal dependencies with the SPL actor. In Step 2,
the two previous guidelines were merged, since their subguidelines
were exactly the same. In Step 3, (i) a guideline was
inserted (current Guideline 7) to address PLUSS annotations;
(ii) the previous Guideline 8 was split into four (current
Guidelines 8, 9, 10, 11) because of the necessity to deal with
every possible cardinality in i*-c; (iii) the previous Guideline 9
(current Guideline 12) was reformulated to take into account
use cases derived from optional steps; and (iv) previous
Guideline 10 was removed because it was a recommendation to
draw a u se case diagram, but not a mapping guideline. The
guidelines we propose in GS2SPL approach are presented as
follows:
Step 1 – Discovering actors:
Guideline 1: Every i* actor is a candidate to be mapped
to a use case actor;
Guideline 2: The candidate i* actor should be external
to the intended software system; otherwise, it cannot be
mapped to a use case actor;
Guideline 3: The candidate i* actor should have at least
one dependency with the actor representing the SPL;
otherwise, it cannot be mapped to a use case actor;
Guideline 4: Analyze the dependencies between the
candidate i* actor and the actor that represents the SPL.
If all of them are s oftgoal dependencies, the i* actor
cannot be mapped to a use case actor;
Guideline 5: Actors in i*, related through the ISA
relationship, and mapped individually to use case
actors (applying guidelines 1, 2, 3 and 4), will be
related through the “generalization” relationship in the
use case diagram;
In our example, there is only one external actor, “User”,
and, according to the presented guidelines, it can be mapped to
a use case actor.
Step 2 – Discovering use cases for the actors:
Guideline 6: For each use case actor discovered in Step
1, analyze its dependencies with the SPL actor;
o Guideline 6.1: Goal dependencies – goals in i* can
be mapped to use cases;
o Guideline 6.2: Task dependencies – it should be
investigated if the task needs to be decomposed
into sub-tasks. If the task requires many steps to be
executed, then it can be mapped to a use case;
o
Guideline 6.3: Resource dependencies – it should
be investigated if the resource can only be
obtained after many interaction steps between the
discovered actor and the system-to-be. If so, the
dependency can be mapped to a use case;
653