Specification of Products and Product Lines

Ariel Gonzalez Carlos Luna

Universidad Nacional de Rio Cuarto Universidad ORT
Rio Cuarto, Argentina Montevideo, Uruguay
[email protected] [email protected]

The study of variability in software development has become increasingly important in recent years.
A common mechanism to represent the variability in a product line is by means of feature models.
However, the relationship between these models and UML design models is not straightforward.
UML statecharts are extended introducing variability in their main components, so that the behavior
of product lines can be specified. The contribution of this work is the proposal of a rule-based ap-
proach that defines a transformation strategy from extended statecharts to concrete UML statecharts.
This is accomplished via the use of feature models, in order to describe the common and variant com-
ponents, in such a way that, starting from different feature configurations and applying the rule-based
method, concrete state machines corresponding to different products of a line can be obtained.

1 Introduction
A product line (PL), also called system family, is a set of software 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, 2, 3].
To develop a system family as opposed to developing a set of isolated systems has important advan-
tages. One of these is the possibility of building a kernel that includes common features, from which
desired products can be easily built as extensions. By adding distinguishing characteristics (variability)
to such a kernel, different products can be obtained [3, 4, 5, 6, 7, 8]. For example, today we observe
in the market a significant number of different types of mobile phones (MPs) that share a core of basic
features and differ in other more specific characteristics: availability of a digital camera, internet access,
mp3 player, among others.
The UML language [9] provides a graphical notation and has become the standard for modeling
different aspects of software systems. Statecharts and interaction diagrams are part of the set of tools
that UML provide so that the system behavior can be specified, which are specially suitable for the
software design phase. Statecharts are used to specify the behavior of the instances of a class (intra-
component behaviour), and therefore constitute an appropriate mechanism for describing the behavior of
certain problems by means of a graphical representation. In the latest version of UML 2.0, the statecharts
do not offer operators and/or sublanguages for specifying system families.
In this paper we propose an extension of UML statecharts for modeling PLs. We used feature models
so that both common and variant functionality of a system family can be described [10, 8], and we
incorporate variability in the essential components of the statecharts, in such a way that, starting from
different configurations of a feature model, concrete statecharts corresponding to different products of
a PL can be generated applying a rule-based method. The approach defines the transformation strategy
from extended statecharts to concrete UML statecharts.
The rest of the work is organized as follows. In section 2 and 3 we briefly introduce statecharts and
feature models, respectively. Section 4 presents an extension of statecharts with variant elements, which

M. Fernandez (Ed.): 9th Int. Workshop on Reduction Strategies

c A. Gonzalez & C. Luna
in Rewriting and Programming (WRS’09) This work is licensed under the
EPTCS 15, 2010, pp. 44–55, doi:10.4204/EPTCS.15.4 Creative Commons Attribution License.
A. Gonzalez & C. Luna 45

together with the use of feature models allow specifying PLs. In section 5 we detail the mechanisms
for obtaining products of a PL from distinct configurations of a feature model, via the use of rules and
a transformation strategy. Related work is discussed in section 6 and finally, we conclude and discuss
possible further work in section 7. We exemplify the proposed work by developing part of a case study
based on mobile phone technology. A preliminary version of this work is [11]. As opposed to [11], this
paper presents a rule-based approach. We define an application strategy for the rules in a proper manner,
in such a way that inconsistencies are avoided in the statechart obtained. The rules are organized in a
sequence of rule sets, in which each rule set can be considered as a layer. Within a rule set, the rules may
be applied in a non-deterministic order [12]. We also formalized and added rules that in [11] are omitted
or only described informally.

2 Statecharts
UML StateCharts (SCs) constitute a well-known specification language for modeling the dynamic system
behavior. SCs were introduced by D. Harel [13] and later incorporated in different versions of the UML
with some variations. In this section, we present definitions of SCs based on [14]. For additional details,
the reader is referred to [11, 14].
SCs consist essentially of states and transitions between states. The main feature of SCs is that states
can be refined, defining in this way a state hierarchy. A state decomposition can be sequential or parallel.
In the first case, a state is decomposed into an automata (Or-state). The second case is supported by a
complex statechart composed of several active sub-statecharts (And-state), running simultaneously.
Let S, T R, Π and A(Π ⊆ A) be countable sets of state names, transition names, events and actions of a
SC, respectively. Also, let us define s ∈ S as either a basic term of the form s = [n] (Simple-state), as a term
Or of the form s = [n, (s1 , ..., sk ), l, T ] (Or-state), or as a term And of the form s = [n, (s1 , ..., sk )] (And-
state), where name(s) =de f n is the name of the state s. Here (s1 , ..., sk ) are the subterms (substates) of s,
also denoted by sub est(s) =de f (s1 , ..., sk ). Likewise, inicial(s) =de f s1 is the initial state of s, T ⊆ T R is
the set of internal transitions of s, and l the active state index of s. A transition is represented as a tuple t =
(t 0 , so , e, c, α, sd , ht), where name(t) =de f t 0 is the transition name, source(t) =de f so and target(t) =de f sd
are called source and target of t, respectively, ev(t) =de f e the trigger event, cond(t) =de f c the trigger
condition, and acc(t) =de f α is the sequence of actions that are carried out when a transition is triggered.
In addition, hist(t) =de f ht is the history type of the target state of t [14]. The graphical notation used in
the transitions is t : e, c/α.

3 Feature Models
Feature Models (FMs) are used to describe properties or functionalities of a domain. A functionality
is a distinctive characteristic of a product or object, and depending of the context it may refer to, it is
a requirement or component inside an architecture, and even code pieces, among others. FMs allow
us to describe both commonalities and differences of all products of a PL and to establish relationships
between common and variant features of the line. There are multiple notations for describing FMs. In
this work we will use the proposal of Czarnecki [10].
A tree structure instance is a FM configuration (FMConf) that describes the model and that respects
the semantics of their relations. That is, a FM allows one to identify common and variant features
between products of a PL, while a FM configuration characterizes the functionalities of a specific product.
Formally, the concepts of FMs are defined as follows:
46 Specification of Products and Product Lines

Definition 1. A FM is defined as a tree structure represented by a tuple (Funcs, f0 , Mand, Opt, Alt,
Or-rel), where Funcs is a set of functionalities of a domain (nodes of the tree), f0 ∈ Funcs is the root
functionality of the tree and, Mand, Opt, Alt, Or-rel ⊆ Funcs × (γ(Funcs) − {0}) / the mandatory, op-
tional, alternative and disjunct relations of the model, respectively. If (f,sf)∈ Mand ∪ Opt, #sf = 1.
Definition 2. A FM configuration corresponding to a FM (Funcs, f0 , Mand, Opt, Alt, Or-rel) is a
tree (F, R) where F is the set of nodes and R the set of edges; F ⊆ Funcs and R ⊆ {(f,sf)∈ F×(γ(F)−{0}) /
| ∃ sf’ ∈ γ(Funcs): sf ⊆ sf’ ∧ (f,sf’) ∈ Mand ∪ Opt ∪ Alt ∪ Or-rel}. Moreover, the following conditions
must be fulfilled by (F, R): (1) f0 ∈ F; (2) for every (f,sf) ∈ Mand: if f ∈ F then (f,sf) ∈ R; (3) if (f,sf)
∈ Alt ∧ f ∈ F then ∃! sf’∈ γ(F): sf’⊆sf ∧ (f,sf’) ∈ R ∧ #sf’=1; (4) if (f, sf) ∈ Or-rel ∧ f ∈ F then ∃!
sf’∈ γ(F): sf’⊆sf ∧ (f,sf’) ∈ R ∧ #sf’≥1.
Definition 3. The kernel N of a FM (Funcs, f0 , Mand, Opt, Alt, Or-rel) is the set of functionalities,
which are present in all configurations, inductively characterized by the following rules: (1) f0 ∈ N; (2)
if f1 ∈ N ∧ ( f 1, { f 2}) ∈ Mand then f2 ∈ N.

4 SCs with Variabilities

In this section we extend the SCs with optional (variant) elements and later on we establish the binding
between these elements with functionalities of a FM, in order to model the behavior of a PL. We will call
our proposed extended machines StateCharts∗ (SCs∗ ).

4.1 Graphical Representation of a SC∗

The representation of the optional elements that extend the system kernel in a SC∗ are depicted in figure 1.
We use dashed lines to graphically denote both optional states as well as transitions.

Figure 1: Optional state and Optional transition.

4.2 Abstract Syntax of a SC∗

Let S∗ , T R∗ , Π∗ and A∗ be set of states, transitions, events and actions of a SC∗ , respectively. Now
the terms that define a state have an additional component Sop ∈ {optional, no optional} that we will
call StateType(s), which indicates whether the state s is optional or not. Similarly, we add component
top ∈ {optional, no optional} to the transitions, and we denote it by TransType(t). We also define the
following sets of SCs∗ optional elements: SOp ⊆ S∗ , T Op ⊆ T R∗ and VarElem = SOp ∪ T Op.
We will refer to states directly by their names, when these are unique for every state in all the SC∗ ;
otherwise, we will use the dot (.) as separator between state and substate names. A transition name is
built by the trigger event name followed by source and target state names, respectively.

4.3 Case study: MPs

We considered here a family of MPs which share some functionalities, such as, for example, the capacity
of reproducing monophonic sounds and vibration. Optionally, we could incorporate into the kernel of
A. Gonzalez & C. Luna 47

functionalities the capacity to make calls by means of quick-marked, to write text messages, to adminis-
ter multimedia contents, and combinations of these, such as messages with multimedia content (images,
polyphonic sounds and videos). In order to exhibit an example in the development of this article, we
formulate in figure 3 a FM, using the notation proposed by Czarnecki, that relates the involved function-
alities in the partially described MP of figure 2.

4.4 Relation between FMs and SCs∗

FMs and SCs∗ are complementary. Both model different aspects of a system and in our proposal, will
not be treated independently, since SC∗ elements model behaviors of present functionalities in the FM.
In general, a functionality is described by more than one SC∗ element. Due to this, we define a function
Imp, which represents the association between the SC∗ variant elements and the functionalities of the
FM. This way we establish what variant elements of the SC∗ implement the characteristics of the system
described in the FM. Given a FM (Funcs, f0 , Mand, Opt, Alt, Or-rel) and a SC∗ (S∗ , T R∗ , Π∗ and
A∗ ), the type of function Imp is as follows: Imp : Funcs → Set(VarElem), where VarElem is the set
SOp ∪ T Op, SOp ⊆ S∗ and T Op ⊆ T R∗ .
Taking into account that the mandatory functionalities are always present in all products of the line,
it is not necessary to define the SC∗ syntactic elements that these implement. However, it is necessary to
do it for those functionalities that cannot belong to FM configuration. Imp will be then a partial function
defined on FM elements which do not belong to the kernel. Therefore, the behavior of a PL is defined by
a FM, a SC∗ , and a function of implementation that binds them.
Example 1. Taking the FM of figure 3 and the SC∗ of case study of figure 2, we define SC∗ elements
that implements functionalities of MP as follows:
Imp(Polyphonic Sounds) = {SelectPolSound, TRightMultimediaType-SelectPolSound, ToChoosePol
Sound, TRightSoundType, ToChoosePolSound, TLeftToChoosePolSound-SoundType, TRightToChoo
sePolSound-PhoneFuncionality, ...}; Imp(Multimedia) = {Multimedia, AdmMultimedia, TRight
Multimedia.Selecct-SelectContact} ∪ Imp(Images) ∪ Imp(Polyphonic Sounds) ∪ Imp(Videos);
Imp(MessagesAdm) = {MessagesCenter, TMessage-MainDisplay-IncomingMess, TMessage-MainDis
play-MessagesCenter, TLeft-MessagesCenter-MainDisplay, TRight-OptionsMenu-MessagesCen
ter} ∪ Imp(Alarm New Messages); Imp(Alarm New Messages) = {MessagesState, TMessageMainDis
play-IncomingMess}.

5 Instantiation of StateCharts with Variabilities

A FM configuration defines a product given a set of selected characteristics. Given a FM configuration
and the SC∗ corresponding to the FM (linked via a function Imp), we define an instantiation function that
returns a SC, which specifies the defined product behavior, Inst : SC∗ × FMCon f → SC.
We eliminate of the SC∗ both states and transitions which implement functionalities not present in
FM configuration, via the use of the function Imp defined in the previous section. The direct elimination
of states as well as transitions of the SC∗ is not trivial. The suppression of SC∗ components without es-
tablishing a control can return inconsistent results, such as, for example, unreachable states or transitions
without target. A control and rebuild mechanism of SCs starting from a SC∗ is defined in such a way that
a concrete product is obtained.
In section 5.1 we present the cases and rules of rebuilding that constitute the base of the instantiation
method which we included in section 5.2. Later, in section 5.3 we analyze our case study: MPs.
48 Specification of Products and Product Lines

Figure 2: SC∗ of MPs.

Figure 3: FM of SC∗ of figure 2.

A. Gonzalez & C. Luna 49

5.1 Cases and Rebuilding Rules

Case 1. When a state is deleted
Case 1.1. When a simple state is deleted
If a simple state s = [E] is deleted, then their entry and exit optional transitions are deleted, while the
mandatory transitions are composed using the following rebuilding method.
Let E ∈ SOp be the state to eliminate, A1 , ..., An predecessor states of E (i.e., states from which there
are non-optional transitions with target E: tAE 1 , ..., tAE n ), and S1 , ..., Sm successor states of E (i.e., target
states of non-optional transitions with source E: tES 1 , ..., tES m ). When the variant state E is deleted, all
entry and exit transitions linked to E are deleted. Simultaneously, new transitions are generated by the
composition of the non-optional entry transitions (tAE 1 , ..., tAE n ) with the non-optional exit transitions
(tES 1 , ..., tES m ).

Figure 4: Resulting SC∗ after the deletion of the optional state.

The composition of two transitions t1 = (t1 , so1 , e1 , c1 , α1 , sd1 , ht1 , no optional) and t2 = (t2 , so2 ,
e2 , c2 , α2 , sd2 , ht2 , no optional) define a new transition as follows: comp(t1, t2) = (t12 , so1 , e1 :: e2 ,
c1 ∧ c2 , α1 :: a2 , sd2 , ht2 , no optional), where :: is the sequential composition of events and actions, and
∧ the conjunction of conditions. Both operations must be associative in order to make the instantiation
method deterministic.
Let sc = (S∗ , T R∗ , Π∗ , A∗ ) be SC∗ (in future, we will omit the components Π∗ y A∗ ), we define the
set of entry and exit non-optional transitions pairs of a state E of sc as follows:
Te s (E) = {(te ,ts ) ∈ T R∗ ×T R∗ | target(te ) = E ∧ source(ts ) = E ∧ TransType(te ) = TransType(ts ) =
no optional}.
The result of eliminating an optional Simple-state E of sc corresponds to the following SC∗ :
Delete simple state(E, (S∗ , T R∗ )) = (S∗ − {E}, T R∗ ∪ {comp(te , ts )| (te ,ts ) ∈ Te s (E)} − {t ∈ T R∗ |t ∈
Domain(Te s (E)) ∨ t ∈ Range(T e s(E))} − {t ∈ T R∗ | TransType(t) = optional ∧ (source(t) = E ∨
target(t) = E)}) We call this rule Delete simple state(E, (S∗ , T R∗ )). Figure 4 shows the result of their
application.
Case 1.2. When a Or-state is deleted
If an Or-state s = [E, (s1 , ..., sk ), l, T ] is deleted, then their entry and exit optional transitions are
deleted, while the mandatory transitions are composed using the following rebuilding method.
The proposal consists of applying the previous transition composition method of case 1.1 on E,
considering certain conditions and affectations to SC∗ . Let sc = (S∗ , T R∗ ) be a SC∗ , we previously
define the set of all the entry and exit non-optional transition pairs of an Or-state E of sc∗ as follows:
Te s (E) = {(te ,ts ) ∈ T R∗ ×T R∗ |target(te ) ∈ sub states(E)∧ source(ts ) ∈ sub states(E)∧ TransType(te )
= TransType(ts ) = no optional}
We establish that each entry transition to E is composed with one exit transition if the source state of
the exit transition is reached from the target state of the entry transition. We define Reachable(E, A) as
50 Specification of Products and Product Lines

the set of reachable substates of E from the substate A. Formally, we define TCompe s (E) = {(te ,ts ) ∈
T e s(E)| source(ts ) ∈ Reachable(E,target(te ))} as the set of transition pairs that must be composed by
means of case 1.1, previous modification of these transitions as is indicated as follows. For each entry
transition te ∈ Domain(TCompe s (E)) its target state is now E, i.e., target(te ) = E. Also, for each exit
transition ts ∈ Range(TCompe s (E)), source(ts ) = E. The result of eliminating the optional Or-state E
of sc∗ corresponds to the SC∗ following:
Delete Or state(E, (S∗ , T R∗ )) = (S∗ − ({E} ∪ sub states(E)), T R∗ ∪ {comp(change target(te , E),
change source(ts , E))| (te ,ts ) ∈ TCompe s (E)} − {t ∈ T R∗ |source(t) ∈ ({E} ∪ sub states(E)) ∨target(t)
∈ ({E} ∪ sub states(E))})
change target(t,E) change the target of transition t, such that target(t)=E. Likewise, change source(t,
E) change the source of transition t, such that source(t)=E. We call this rule Delete Or state(E, (S∗ ,
TR∗ )).
Case 1.3. When an And-state is deleted
If an optional And-state E is deleted, then their entry and exit optional transitions are deleted, while
the mandatory transitions are composed using a similar rebuilding method to case 1.2.
Two possible relations of dependency or synchronization between parallel states exist. One of them
refers to the occurrence of an event that produces the trigger of two or more transitions belonging to each
one of the parallel substates. The second relation corresponds to using conditions of type ‘in E’ (see case
2.2). The latter forces to redefine the concept of reachability, since it is not valid to apply the previous
definition of reachability in a way independent in each one of the orthogonal states.
Let E be an And-state with n orthogonal states. We define now Reachable(E, (E1 , E2 , ..., En )) as
the set of n-tuples of reachable states from (E1 , E2 , ..., En ). In this way, maintaining the definition of
Te s (E) of the previous case and redefining TCompe s (E), it is possible to solve the method of transition
elimination and composition (Delete And state) in an analogous form to case 1.2.
TCompe s (E) = {(te ,ts ) ∈ Te s (E)|(∃ n-tupla init, n-tuple end ∈ (S∗ ×S∗ ×...×S∗ )n | n-tupla end ∈
Reachable(E, n-tupla init)∧(∃i, j1 ≤ i, j ≤ n|n-tupla end[i] = source(ts )∧n-tupla init[ j] = target(te )∧
cond(ts )))}, being n the amount of orthogonal states. We call to this rule Delete And state (E, (S∗ , TR∗ )).

Case 2. Consequences of the elimination of a state

Some situations can appear as a consequence of applying the cases described previously, which must
be considered in order to reestablish the SC. These situations are analyzed in the following cases.
Case 2.1. When an initial state is deleted
If an initial state of a state E = [s, (s1 , ..., sk ), l, T ] is eliminated, then anyone of their successors
that belongs to E becomes the new initial substate, i.e. if ∃ t,t = (tname , s1 , e, c, α, snew initial , ht) ∈
T |snew initial ∈ (s2 , ..., sk ) then initial 0 (E) = snew initial . We call this rule Delete Initial state(E, (S∗ , TR∗ )).
Case 2.2. When some substate in a parallel decomposition is deleted
The conditions of transitions in a parallel decomposition of type ‘in E’ are deleted when the state
E is eliminated via some FM configuration, i.e. if E is deleted and t = (tname , so , e, c, α, sd , ht) ∈
T R| ‘in E’∈ c, then t 0 = (tname , so , e, delete expresion in condition(‘inE’, c), α, sd , ht), where the func-
tion delete expresion in condition(expr, c) eliminates the logic subexpression of c. We call this rule
Delete condition(E, (S∗ , TR∗ )).

Case 3. When a transition is deleted

If a transition t of a SC∗ disappears, it does not produce alterations in the SC∗ .We call this rule
Delete transition(t, (S∗ , TR∗ )).
A. Gonzalez & C. Luna 51

Case 4. Changing the optional elements to non optional elements

This rule will be used in the reduction strategy, in order to make part of the final product all optional
elements remainders. That is to say, ∀s ∈ SOp∗ , StateType(s0 ) = non optional. In a same way, ∀t ∈
T R∗ , TransType(t 0 ) = non optional. We call this rule Changing optional to non optional(S∗ , TR∗ ).

5.2 Instantiation Method

Given a FM and its configuration, we will call NSF the set of non-selected functionalities of the model
as consequence of the configuration. Formally, for the FM f m = (Funcs, f0 , Mand, Opt, Alt, Or-rel)
and a configuration con f f m = (F, R) of fm, NSF = Funcs − F. We define also the set of non-selected
components(NSC) by the configuration con f f m of SC∗ sc, which will not be part of the resulting SC, as
follows: NSC(con f f m , sc) = {x ∈ VarElem|∃ fi ∈ NSF : x ∈ Imp( fi ) ∧ ¬∃ fi0 ∈ F : fi0 6= fi ∧ x ∈ Imp( fi0 )},
with VarElem e Imp defined for sc according to section 4.4. This is, the states and transitions that do
not implement selected functionalities by a configuration will be excluded, through the rules, from the
behavior of resulting SC.

5.2.1 Application Strategy

The rules should be executed in a certain order for the result to be deterministic. We will assume that
rules are organized in rule sets, which are then organized in a sequence of rule sets in which each rule
set can be considered as a layer [12]. Within a rule set, rules maybe applied in a non-deterministic order.
Syntactically we express layers of rule sets as shown in the following example: given three rules p1, p2,
and p3, ({p1, p2}, p3 ↓) specifies two layers. The first one contains p1, p2, and the second contains p3.
This means that first any rule in the first layer is applied, and then the one in the second layer is applied.
The symbol p ↓ denotes that the rule p ↓ is iterated until it cannot be applied anymore.
The order of application of the rules will determine the order of selection of the elements in NSC
(conf f m , sc). Let sc ∈ SC∗ , f mc ∈ FMCon f , and E,t ∈ NSC( f mc, sc). We establish the following
application order of rules:
SR = ({Delete Initial state(E, sc), Delete condition(E, sc)} ↓;
{Delete simple state(E, sc), Delete Or state(E, sc), Delete And state(E, sc)} ↓;
Delete transition(t, sc) ↓; Changing optional to non optional(sc))
The strategy should be applied only once. It is important to consider that the application of a rule
produces the elimination of elements in NSC( f mc, sc). The strategy is completed when NSC( f mc, sc) =
0.
/ Note that the implementation of the first two rules does not eliminate states, but only change initial
states and deleting conditions like ‘in E’. Later the affected states will be eliminated by the successor
rules. The rule Changing optional to non optional(sc) convert optional elements, which remain in sc,
to non optional elements.

5.2.2 Termination and Deterministic Implementation

Termination and confluence problems can occur whenever a rule-based approach is used. As termination
and confluence are fundamental for the correctness of a model transformation, systematically validating
these properties is a main prerequisite for successful practical applications, such as transformations in
the MDA context, for example.
In our context, the property of termination is clear, given that rules are applied on elements of
NSC(fmc, sc), and these are eliminated in each application until NSC( f mc, sc) = 0/ . Therefore the
52 Specification of Products and Product Lines

strategy is terminating because the rules decrease components of the statecharts (either states or transi-
tions).
In general, confluence means that, when there is a choice of applying different rules, the choice does
not affect the result. The role of the first two rules is to avoid ill-formed statecharts. The main rule is
Delete simple state(E, sc), since Delete Or state(E, sc) and Delete And state(E, sc) are based on this.
Note that Delete simple state(E, sc) does not produce ill-formed statecharts (see case 1.1).
r (r1 , r2 )
The application of a rule r on a SC∗ is denoted by sc∗i → sc∗i+1 , and sc∗i → sc∗i+2 denotes the
application of r1 y r2 in that order.
Lemma 1. (Applying two rules.) Let r1 , r2 ∈ {Delete simple state(E, sc), Delete Or state(E, sc), Delete
And state(E, sc)} be two rules to be applied to states E1 and E2 ∈ NSC( f mc, sc), respectively.
(r1 , r2 ) (r2 , r1 )
sc∗i → sc∗j ∧ sc∗i → sct∗ ⇒ sc∗j = sct∗ .

Proof. Let E1 and E2 ∈ NSC( f mc, sc) be the states to eliminate. We consider both independent if there
is no transition which connects, in this case it is clear that the elimination in any order produces the
same SC. The opposite case is discussed. Let tE1 = (tE1 , so1 , a1 , c1 , α1 , E1 , ht1 , non optional), tE1 E2 =
(tE1 E2 , E1 , a12 , c12 , α12 , E12 , ht12 , non optional) and tE2 = (tE2 , E2 , a2 , c2 , α2 , sd2 , ht2 , non optional) be
entry and exit transitions of E1 and E2 . On the one hand, we assume that the rule Delete simple state(E1 ,
sc) is applied before rule Delete simple state(E2 , sc), i.e. tE1 is composed with tE1 E2 and after compose
with tE2 .
comp(comp(tE1 , tE1 E2 ),tE2 ) = tE1 (E1 E2 ) E2 = (tE1 (E1 E2 ) E2 , so1 , (a1 :: a12 ) :: a2 , (c1 ∧c12 )∧c2 , (α1 ::
α12 ) :: α2 , sd2 , ht2 , non optional).
On the other hand, if we assume now the inverse application of both rules, we can see that the
resulting composition has the same result as the previous case. Given that the operators ∧ and :: are
associative: comp(comp(tE1 , tE1 E2 ), tE2 ) = comp(tE1 , comp(tE1 E2 , tE2 )).
The rules Delete Or state and Delete And state are based on the rule Delete simple state, therefore
we may consider E1 and E2 (see above) as compound states.

Let SC∗ , R y SR be a rule-based rewriting system on Statecharts (RS-SC), where R is the set of rules
defined in section 5.1 and SR the implementation strategy on the rules of R. Let ValSeq SR be the set of
all valid sequences of applications.
An RS-SC execution starting from a SC∗ (sc∗ ) is a sequence s of rule applications of R such that
s
s ∈ ValSeq SR . We denote it by sc∗ → sc, where sc ∈ SC is a concrete statechart.
Theorem 1. (Confluence.) Two distinct executions of RS-SC generate the same statechart.
s s
sc∗ →
1
sc ∧ sc∗ →
2
sc0 ⇒ sc = sc0 .

Proof. The proof is given by the following:

Both executions, s1 and s2 , have the same length, since the number of applications of rules is equal to
#NSC. Moreover, the set of rules of sequence s1 is equal to set of sequence s2 , therefore s1 is a permu-
tation of s2 . Since the rules Delete Initial state, Delete condition and Changing optional to non op-
tional of SR are clearly deterministic and do not remove states or transitions, we focus only on the
subsequences of s1 (sub s1 ) and s2 (sub s2 ) which include rules Delete simple state, Delete Or state
and Delete And state.
Since sub s2 is a permutation of sub s1 , the proof follows immediately from Lemma 1 by swap rules
in any of sequences.
A. Gonzalez & C. Luna 53

5.3 Instantiation of the Case study: MPs

The FM of figure 3 can be configured to characterize different MPs, according to the specification of the
case study of section 4.3. Next, we present a configuration of a MP of figure 2 and we proceed towards
obtaining the corresponding SC (the MP wanted), according to the application order of rules defined in
section 5.2.
A MP with neither the support for the management of polyphonic sounds nor the capacity of alerting
the user when new messages enter in the incoming mailbox, is defined by the configuration con f f m =
(F, R) of the FM of figure 3, where:
F = {MP, Display, Contacts, MessagesAdm, Multimedia, Images, Videos, Quick-Marking, Ringer in f unc
tions}, and
R = {(MP, {Multimedia}), (MP, {MessagesAdm}), (MP, {Quick-Marking}), (MP, {Display}), (MP, {Con
tacts}), (MP, {Ringer in f unctions}), (Multimedia, {Images}), (Multimedia, {Videos})}.
Taking the previous configuration and the function Imp described in example 1 of section 4.4, the
sets NSF and NSC(con f f m , sc) are defined as follows:
NSF = {PolyphonicSounds, AlarmNewMessages}, and
NSC(con f f m , sc) = {SelectPolSound, TRightMultimediaType-SelectPolSound, ToChoosePolSou
nd, TRightSoundType-ToChoosePolSound, TLeftToChoosePolSound-SoundType, TRightToChoosePo
lSound-PhoneFuncionality, MessagesState, TMessage-MainDisplay-IncomingMess}.
In accordance with the strategy defined in section 5.2, must apply the rules in the following order:
Delete condition(MessagesState, sc) → Delete simple state(SelectPolSound, sc) → Delete simple state(To
ChoosePolSound, sc) → Delete transition(T RightMultimedia-Type-SelectPolSound, sc) → Delete transition(
T RightSoundType-ToChoosePolSound, sc) → Delete transition(T Le f tToChoosePolSound-SoundType, sc) →
Delete transition(T RightToChoosePolSound-PhoneFuncionality, sc) → Delete transition(T Message-MainDis
play-IncomingMess, sc) → Changing optional to non optional(sc).
The resulting SC is observed in figure 5.

6 Related Works
A variety of existing approaches propose the incorporation of variability in software systems and in par-
ticular on PLs. One of these is the one designed by Jacobson [15], whose weaknesses have been analyzed
by several authors. Von der Maen [4] proposes the use of a graphical notation with new relations. John
and Muthig [16] suggest the application of use case templates, although they do not distinguish between
optional, alternative or obligatory variants. However, Halman and Pohl propose in [17] to make use of
UML 2 package merge, based on [6], as a tool for the variability representation and configuration in PLs.
As opposed to the mentioned proposals, our solution is centered in one behavior specification model of
a PL, as are the SCs, introducing a clearly defined formal sustenance.
Also, to define PLs and to characterize their different products we use FMs, which admit a formal
definition and allow us to configure the functional characteristics of a line. An alternative approach to this
paper is developed in parallel by other members of the research project in which this work is subsumed.
In [18] the authors, in a formal framework, define functions that associate SCs (not components of SCs,
as in our case) to functionalities of a FM, and analyze forms of combination between different SCs
which specify possible variants of a PL. Whereas under our method the behavior of a product into a
PL is obtained basically by a selection process, in [18] the focus is oriented towards a process of SC
combinations.
54 Specification of Products and Product Lines

Figure 5: SC for a MP without polyphonic sounds and without alert of new messages.

7 Conclusion and Further Work

Most of the techniques of Model Driven Development make use of UML. In particular, the SCs of UML
constitute a mechanism for specifying systems behavior by means of a graphical representation. In this
work, we presented an extension of UML SCs by incorporating variability in their essential components
to specify PLs. The variability is introduced in the SCs distinguishing optional and non-optional states as
well as optional and non-optional transitions. A PL is specified with a SC∗ , a FM, and a formal relation
(an implementation function) that binds both models. Using FMs to describe the common and variant
functionalities and applying a rule-based instantiation method, concrete SCs corresponding to different
PLs can be obtained. The approach defines the transformation strategy from extended SCs to standard
UML SCs. We develop partial examples of a case study based on mobile phone technology, whose full
version is not included in this article due to space restrictions.
Given the fact that UML and SCs have become very successful languages for analysis and design in
A. Gonzalez & C. Luna 55

the very short run, we are confident that the results of this work can be successfully applied to the real
problems of the software industry. It is a timely contribution to an authentic and actual problem.
As part of our plans for future work, we are interested in an extension of SCs which allows us to
completely cover the UML 2.0 SCs and analyze variabilities, not only the ones considered in this paper,
but in all of their components. Also, we will make an attempt to provide a formal semantics for the
extension. This semantics is an essential preliminary step towards both the automatic code generation
and the validation of complex software systems.

References
[1] P. Clements, L. Northrop. Software Product Lines: Practices and Patterns. SEI Series in Software Engineer-
ing, Addison-Wesley. 2002.
[2] H. Gomaa: Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Archi-
tectures. The Addison-Wesley Object Technology Series, 2004.
[3] K. Kang, J. Lee, and P. Donohoe. Feature-Oriented Product Line Engineering. IEEE Soft., 19(4):58-65, 2002.
[4] T. von der Maßen, H. Lichter. Modeling Variability by UML Use Case Diagrams. In Proc. of the International
Workshop on Requirements Engineering for Product Lines (REPL’02), 2002.
[5] G. Halmans, K. Pohl. Communicating the Variability of a Software-Product Family to Customers. Journal of
Software and Systems Modeling 2, 1 2003, 15–36.
[6] A. Zito, Z. Diskin, and J. Dingel. Package merge in UML 2: Practice vs. theory? In O. Nierstrasz, J. Whittle,
D. Harel, and G. Reggio, editors, MoDELS/UML 2006, October 2006.
[7] M. Clauß. Generic modeling using Uml extensions for variability. In Workshop on Domain Specific Visual
Languages at OOPSLA 2001, 2001.
[8] K Czarnecki, M. Antkiewicz. Mapping Features to models: a template approach based on superimposed
variants. In Proc. GPCE’05, LNCS 3676, Springer, pp. 422-437.
[9] Object Management Group: OMG Unified Modeling Language Specification Version 2.0, 2004. Available at
http://www.uml.org.
[10] K. Czarnecki and U.W. Eisenecker. Generative Programming: Methods, Techniques, and Applications.
Addison-Wesley, 2000.
[11] C. Luna, A. González. Behavior Specification of Product Lines via Feature Models and UML Statecharts
with Variabilities. In Proc. of SCCC’08, Chile, IEEE CS Press. pp. 32-41, 2008.
[12] Jochen M. Küster. Definition and validation of model transformations. Journal of Software and Systems
Modeling, 5(3) 233-259, 2006.
[13] D. Harel: Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8: 231-
274,1987.
[14] M. von der Beeck. A structured operational semantics for UML-statecharts. Software and System Modeling,
1(2):130-141, 2002.
[15] I. Jacobson, M. Griss and P. Jonsson . Software Reuse. Architecture, Process and Organization for Business
Success. ACM Press. Addison Wesley Longman. 1997.
[16] John, I., Muthig, D.: Tailoring Use Cases for Product Line Modeling. In Proc. of the International Workshop
on Requirements Engineering for Product Lines (REPL’02), 2002.
[17] M. Laguna, B. González-Baixauli, O. López. Gestión de la Variabilidad en Lı́neas de Productos. In Proc. of
CLEI07, Costa Rica, Octubre de 2007.
[18] N. Szasz and P. Vilanova. Statecharts and Variabilities. In proc. of the Second International Workshop on
Variability Modelling of Software-intensive Systems, Essen, Germany, 2008.