J. Software Engineering & Applications, 2009, 2: 248-258
doi:10.4236/jsea.2009.24032 Published Online November 2009 (http://www.SciRP.org/journal/jsea)
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based
Modeling of Software Product Lines
Stéphane S. SOMÉ, Pauline ANTHONYSAMY
SITE, University of Ottawa, Ottawa, Canada.
Email: ssome@site.uottawa.ca
Received May 29th, 2009; revised June 22nd, 2009; accepted June 27th, 2009.
ABSTRACT
Software Product Line Development advocates software reuse by modeling common and variable artefacts separately
across members of a family of products. Aspect-Oriented Software Development aims at separation of concerns with
“aspects” to increase modularity, reusability, maintainability and ease of evolution. In this paper, we apply an as-
pect-oriented use case modeling approach to product line system modeling. A use case specification captures stake-
holders concerns as interactions between a system and its actors. We adapt our previous work with the introduction of
avariability relationship for the expression of va riabilities. This relationship is used to model variable and common
behaviours across a family of products as use cases. A variability composition mechanism enables building of executa-
ble behaviour models for each member of a product line family by integrating common elements with the applicable
variable elements.
Keywords: Product Lines, Use Cases, Aspects, Requirements Modeling
1. Introduction
The importance of a Software Product Line (SPL)
emerged from the field of software reuse when develop-
ers realized that reusing development artefacts such as
requirements, designs, and components across different
members of a product family significantly reduces cost,
effort and time. According to Clements et al. [1], a soft-
ware product line is defined as “a set of software inten-
sive systems sharing common, managed set of features
that satisfy specific needs of a particular market segm ent
and that are developed from a common set of core assets
in a prescribed way”. However, effectiveness of a soft-
ware product line does not solely depend on reuse capa-
bility but also on how commonalities and variabilities of
a product line are managed and modeled from the re-
quirements phase to the implementation phase.
Use cases are widely used to model functional re-
quirements in traditional as well as product line systems.
A use case specification captures stakeholders concerns
as interactions between a system and its actors. Various
extensions to traditional use case modeling have been
proposed for the expression of variability and common-
ality. For instance, Ecklund et al. [2] proposed change
case to specify anticipated changes that may impact a
software product line. Change cases provide an “impact
link” that creates traceability to use cases whose imple-
mentations might be affected. In [3], Jacobson et al.
proposed variation points and abstract use cases to
model variabilities and commonalities with the UML
extend” and “generalization” relations. Whereas,
Gomma [4], introduced UML stereotypes “kernel”, “al-
ternatives” and “optional” to distinguish common and
variable use case specifications in software product lines.
Similarly, John and Muthig [5] proposed stereotype
variant” and the marking of sections of use case dia-
grams as optional to model variabilities. As for use case
descriptions, they advocate using XML tags ‘variant’
‘/variant’ to mark optional and alternative steps (and
scenarios).
In our previous work [6], we proposed an approach to
support use cased based requirements engineering. This
approach is supported by a tool called Use Case Editor,
(UCEd) [7]. UCEd is a use case modeling tool that takes
a set of related use cases written in a restricted natural
language and automatically generate executable State
Charts that integrates the partial behaviours defined by
these use cases. A domain model is used for syntactical
analysis of use cases and as a basis for state model gen-
eration from the use cases. We then extended our ap-
proach to support modelling aspects in use case specifi-
cations [8]. We introduced an “aspect” relation for
crosscutting requirements and derived a composition
mechanism for the generation of a global behaviour
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines 249
model integrating use cases with crosscutting concerns.
In this paper, we apply this aspect-oriented use case
modeling approach to product line systems specification.
A number of recent works have demonstrated that ap-
plying Aspect-Oriented Software Development (AOSD)
to SPL provides an improved mechanism to encapsulate
and model variabilities and commonalities throughout
the entire software lifecycle [911]. We model variabili-
ties and crosscutting commonalities as use cases and link
them with a “variability” relation. The “variability” rela-
tion is a specialization of the “aspect” relation. The ap-
proach allows variabilities and commonalities to be bet-
ter encapsulated and modularized. An aspect composi-
tion mechanism enables building of executable behaviour
models for each member of a product line family by in-
tegrating common elements with the applicable variable
elements.
The remainder of this paper is organized as follows.
Section 2 presents some background material on use case
modeling and presents our approach on modeling the
concerns with “aspect” relation. In section 3, we present
our argument on modeling variability and commonalities
in a product line by adapting the approach presented in
section 2 and describe variability compositions in terms
of Petri net formalism. We then position our work rela-
tively to close works in Section 4 and finally, section 5
concludes the paper and discusses some future works.
2. Use Case Modeling
A use case is defined as “the specification of a set of ac-
tions performed by a system (or subsystem), which yields
an observable result that is, typically, of value for one or
more actors or other stakeholders of the system.” [12]. In
this section, we briefly review the UML use case rela-
tionships and our “aspect” relationship introduced in [8]
for crosscutting concerns.
2.1 UML Use Case Modeling
A UML use case model includes use cases, actors and
relationships. There are three types of relationships be-
tween use cases – include , extend and generalization. An
include relationship ucbase
× ucinc represents the inclusion
of use case ucinc as a sub-process of use case ucbase (base
use case). An extend relationship ucext × econd × epoints
× ucbase represents an extension of a base use case, ucbase
by an extension use case, ucext. Behaviors described in
the extension use case are included at specific places in
the base use case called extension points, epoints. Each
extension is realized under a specific condition known as,
econd. Whereas, a generalization relationship defines an
inheritance relation between an abstract use case and a
Figure 1. UML use case diagram for a microwave oven
more specific use cases. Figure 1 shows a UML use case
diagram for a Microwave System (single system).
Use case diagrams represent abstract overview of a
system. Each use case is specified in the form of descrip-
tion of interactions (as natural language text) between a
user and the system. In order to support automated syn-
thesis of state models from use cases, we formalized use
case description by defining an abstract syntax, a con-
crete syntax based on natural language and by providing
Petri nets based semantics to use cases [13].
Figure 2 shows an example of a use case. A
semi-formal natural language* is used for operations and
conditions in use case steps. The UCEd tool uses a do-
main model where domain entities including operations
are defined to validate the use cases [6]. The domain
model serves as a high-level class model that captures
domain concepts and their relationships. Use case execu-
tion semantics are expressed using the Petri nets formal-
ism [14] and an algorithm described in [13] generates
Petri nets from use cases as an intermediate model for
UML State Charts.
2.2 Aspect-Oriented Use Case Modeling
Aspects-oriented software development aims at provid-
ing software developers techniques and tools to better
manage crosscutting concerns. A crosscutting concern is
typically scattered among several other concerns. Cross-
cutting concerns needs to be identified and effectively
handled from the beginning of the development lifecycle
(i.e. requirements engineering). Jacobson and Ng [15]
noticed a close relation between use cases and aspects as
each use case typically crosscuts a set of components and
usually involves crosscutting concerns such as synchro-
nization, accuracy, access control and more. Other ap-
proaches that were proposed for aspect-oriented model-
ing of use cases include [16,17]. In our aspect-oriented
use case modeling approach, crosscutting concerns de-
fined as advice use cases are linked to affected concerns
using an “aspect” relationship [8]. Differently to the
UML relationships, the “aspect” relationship cardinality
*Operations are specified as active sentences and conditions are in the
form of predicative sentences. Further reference to the semi-formal
natural lan
g
ua
g
e can be found in
[
6, 13
]
.
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines
250
is one to many. We defined AspectJ [18] constructs in
use case terms and adopted a symmetric model where all
concerns (including crosscutting concerns) may be ex-
tended as opposed to AspectJ asymmetric model.
Formally, an “aspect” relation defined as ucadv
×
acond × apcuts × baseUCs links the advice use case,
ucadv to the set of base use cases baseUCs according to
pointcut expressions apcuts when condition acond is
fulfilled. As mentioned previously, the cardinality of
aspect” relation is one to many since crosscutting con-
cerns typically influences several use cases. The set of an
“aspect” relationship target use cases is identified using
parameterization based on use case description elements
such as name, title, primary actors, goals, post-conditions
etc. Advice use cases that capture crosscutting require-
ments are defined in the same form as normal use cases.
However, we do not require that advice use cases strictly
adhere to use cases well-formness rules as stated in the
UML specification [12]. An advice use cases may only
have some of a use case sections. We also allow advice
use cases to be initiated by the system and to describe
incomplete interactions. The linking of advice use cases
with affected base use cases is based on syntactical
matching of joinpoints (potential occurrence of a cross-
cutting concern in a base use case) and pointcut expres-
sions. Any use case description element i.e. steps, opera-
tions, alternatives, extension points, etc is a possible
joinpoint. Pointcuts are parameterized pattern-based ex-
pressions that match joinpoints.
Additionally, a pointcut specifies how advice use cases
are weaved at the joinpoints. Parameterization is essen-
tial in pointcut expressions since the number of target
joinpoints can be large, complex and unpredictable. For
instance a pointcut specified as “step 1, 2” refers to step
one and two of the use case and “step *” refers to all the
steps in the use case. Similarly, pointcut “operations Mi-
crowave System *” refers to all operations of entity “Mi-
crowave System” and operations “*opens*” matches all
operations that contains the word “open” as part of the
operation name. Three types of advice weaving are tradi-
tionally defined in AOP: before, after and around. We
consider the same composition types with an additional
type for concurrent composition (concurrent). Below is
a brief description of each composition type:
before: crosscutting requirements are applied before
a joinpoint
after: crosscutting requirements are applied after a
joinpoint
around: crosscutting requirements are applied in-
stead of a particular joinpoint (wrapping)
concurrent: crosscutting requirements are applied
concurrently with a joinpoint (in parallel)
Figure 3 shows UCEd representation of the Micro-
wave Oven use case model with <<aspect>> relations.
The model includes one advice use case “Safety”. The
target use cases of the <<aspect>> relation from use
case “Safety” are specified as a wildcard “*”. “Safety”
use case is therefore applied to the all other use cases in
the model but itself (an advice use case is always ex-
cluded from its set of related use cases to avoid infinite
inclusion). The “Safety” advice use case is weaved based
on operation pointcut “after operations * presses Start
*” (defined as a children of the relation).
Finally, we defined aspect composition at the Petri net
level [8]. Behaviours defined in advice use cases are
weaved with the affected base use cases according to
pointcut expressions. A global behaviour model is ob-
tained by integrating all crosscutting concerns and base
use cases. Resulting Petri net models may be transformed
Title: Cook Food
Primary Actor: User
Goal: Allows User to cook, heat food
Precondition: Microwave oven is idle
Post-condition: Microwave oven has cooked the food
Steps:
1.The User opens the oven door
2.The User puts the food in the oven
3.The User closes the oven door
4.The User presses the Cooking Time button
5.The Microwave System prompts the User for the cooking time
6.The User enters a cooking time on the numeric keypad and
presses Start button
7.The Microwave System starts cooking the food
8.The Microwave System continually cooks and displays the cook-
ing time remaining
9.The Timer elapses and notifies the Microwave System
10.The Microwave System stops cooking the food and displays the
end message
11.The User opens the oven door
12.The User removes the food from the oven
13.The User closes the door
14.The Microwave System clears the display
Alternatives:
6.a.The Cooking time is zero
6.a.1.The Microwave System notifies the User of an error
Figure 2. Details of use cases “Cook Food”
Figure 3. UCEd representation use cases with “aspect” relations
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines 251
to UML State Charts and used as prototypes for require-
ments validation by simulation in UCEd [13].
3. Adapting Aspect-Oriented Use Case
Modeling to Product Lines
A product line is a set of products that share a common
set of characteristics and yet differ from each other based
on a set of variabilities. Product Line Engineering (PLE)
is about exploiting commonalities across product line
systems while managing variabilities in order to improve
reusability (of software artifacts such as requirements,
models, components etc.), reduce time to market, cost
and improve product quality. Commonalities are features
that are common to a set of products and variabilities are
features that products may optionally have in a product
family. Variabilities influence software systems in the
similar manner as crosscutting concerns [9–11,19]. For
instance, variability “x” may be implemented several
times and over different products across a product family.
According to [19], aspects and variability are orthogonal
concepts, which are independent of the core system and
can be combined with it when needed.
In this section, we adapt our aspect-oriented use case
modeling approach [8] to variabilities and commonalities.
We introduce a “variability” relation to model variabili-
ties and crosscutting commonalities in a product line
system. The “variability” relation is a specialization of
the “aspect” relation. It has similar characteristics as
“aspect” relation but with some differences. Similar to
crosscutting concerns, variabilities and crosscutting
commonalities are specified as advice use cases and
weaved into base use cases according to the different
types of pointcut expressions. Our objectives in adapting
aspect-oriented use case modeling to product lines speci-
fication include better encapsulation and modularity of
variabilities and commonalities. Aspect-orientation al-
lows variabilities and crosscutting commonalities to be
modeled separately thus, improves readability as well as
system evolution. By implementing the approach as part
of the UCEd toolset, we also aim at providing traceabil-
ity between products and features and take advantage of
UCEd simulation capabilities for product design and
validation.
We illustrate our approach with a product-line version
of the microwave system [4].The product line consists of
microwave ovens that come with features ranging from
basic to advanced features. A basic microwave oven sys-
tem has input buttons for selecting Cooking Time, Start,
and Cancel, as well as a numeric keypad. It also has a
display to show remaining cooking time. Additionally,
the oven has a microwave-heating element for cooking
food, a weight sensor to detect if there is an object in the
oven. Optional features for more-advanced microwaves
include a beeper to indicate when cooking are done, a
light that is switched on when the door is open and when
food is being cooked, and a turntable.
3.1 “Variability” Relation
The “variability” relation is a “specialization” of “as-
pect” relation for modeling variabilities and crosscutting
commonalities in a product line system. The “variabil-
ity” relation links variabilities and crosscutting common-
alities to affected base use cases and specifies pointcuts.
More formally, a “variability” relationship ucvar × plcond
× vpcuts × baseUCs specifies that variabilities defined as
an advice use case ucvar are weaved to the set of base use
cases baseUCs according to pointcut expressions vpcuts
when condition plcond is fulfilled. Condition, plcond
specifies whether a given member of the product line
provides the functionality described by the advice use
case ucvar. Thus, the functionality is provided when
plcond is true; whereas if the condition is false, then
functionality is not provided. Similar to the “aspect”
relation, the cardinality of the “variability” relation is
one to many. This is a reflection of the fact that variabili-
ties and crosscutting commonalities affect several use
cases in a product line model. The one-to-many cardinal-
ity allows several base use case to be conveniently linked
to a single variability. The set of target use cases is iden-
tified using parameterization in a similar way as the
“aspect” relation. For instance, the targets of an “vari-
ability” relation specified as “*cook* are all use cases in
the use case model which names contains the word
“cook”, i.e. “Cook Food” and “Interrupt Cooking” in the
use case model in Figure 1. Parameterization is not lim-
ited to use case names but may also be used for descrip-
tion elements such as “primary actors”, “goals”,
pre-conditions” and “post-conditions ”. For instance,
“Primary Actor User” matches all use cases with “User”
as the primary actor. The parameterization allows
changes to use case models and product evolution inde-
pendently of variabilities, e.g. when a new variability
option is added to a product family, changes to the exist-
ing model can be avoided. Furthermore, UCEd “tree”
representation (refer to Figure 7) helps model variabili-
ties and commonalities within a software product family
in a clearer manner.
3.2 Composition Mechanism
Similar to crosscutting concerns, we define composition
mechanism for product lines at the Petri net level, where
advice use cases (variabilities) are weaved with affected
base use cases based on pointcut expressions. Differently
to composition mechanism for crosscutting concerns,
where a global behavior model from use cases integrat-
ing all independently defined concerns is generated, we
generate a Petri net for a particular product within a
product line.
A Petri net is a triple [P, T, F] with: P a finite set of
places, T a finite set of transitions and
F
(
P
×T )∪(T×P)
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines
Copyright © 2009 SciRes JSEA
252
a flow relation. Places are represented in the graphical
description of a Petri net, as circles, transitions as boxes
and the flow relation corresponds to arrows. Figure 4
shows how advice use cases (variabilities) are weaved
according to the different types of pointcuts. Use cases
are mapped to Petri nets such that each reference to use
case description elements (operations, step, etc) corre-
sponds to a transition in the Petri Net model [13]. To
ease our discussion, we model the composition mecha-
nism based on pointcut expressions formed with opera-
tion joinpoints (op). In Figure 4, a1, a2, a3 …are sequence
of events in the advice use cases (variabilities) and tran-
sition corresponding to the operation joinpoint, op in the
Petri net derived from the base use case is colored black.
Notice that differently to the general situation in [8],
variability” conditions (plcond) are not included in the
composition for variabilities. Only relevant advice se-
quences are weaved at the corresponding operations
joinpoints. Similar composition mechanisms are used for
other types of joinpoints (i.e. steps, alternatives, exten-
sion points); with transition op replaced by the corre-
sponding elements.
Figure 4. Weaving based on different types of operation, op
inconsistencies that may occur and correct them accord-
ingly.
3.3 Modeling Variability in UCEd
Use case “Cook Food” in Figure 2 captures a common
functionality of products in the microwave oven product
line. We use feature modeling [20] to represent the
high-level view of the Microwave Oven product family.
Optional and alternative features describe variabilities in
a product line and determine the characteristics of a
given member of the product family. Optional features
are variabilities that are required by some but not all
members of a product family and alternative features are
variabilities that are in different versions and are required
by different members of the product line. These alterna-
tive variabilities are usually mutually exclusive. Figure 5
shows variabilities of the microwave oven product line as
a feature model. Each microwave oven may include
mandatory alternative and optional variabilities. The
mandatory alternative variabilities are a weight sensor
that is either Boolean or analog, a display unit that is
Several advice use cases (variabilities) can refer to the
same joinpoint. In that case, the advice use cases are se-
quentially ordered based on the type of pointcuts. Before
advices are applied first and then after advices. The be-
haviour described in an around advices substitutes the
behaviour described by a specific operation or step in the
base use case based on the “variability” relations condi-
tion. Lastly, concurrent advices are executed in parallel
with joinpoints and around advices. Several pointcuts of
the same type are applied in a non-deterministic manner.
For instance, in a situation where several before pointcuts
refer to a same joinpoint, the corresponding advice use
cases would be randomly weaved one after the other and
before the joinpoint. Although, this is not an optimal
resolution technique, UCEd allows the modeler to vali-
date and simulate resulting Petri nets to uncover any
Figure 5. Feature model for microwave oven product line
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines 253
one-line or multi-line, a one-level or multi-level heating
element. The optional variabilities are a light, a turntable
and a beeper.
We model variabilities as advice use cases and link
them to commonalities with “variability” relations. As
crosscutting concerns, variabilities are attached with
conditions and pointcut expressions.
The attached condition specifies whether a given
member of the product line provides the functionality
described by the particular advice use case. Figure 7
shows UCEd representation of the commonalities and
variabilities of the Microwave product line system. Use
case “Cook Food” represents commonalities while, vari-
abilities are attached with the “variability” relation and
are linked to all other use cases using wildcards ‘*’. Each
variable option is attached with a “variability” relation
condition stating that the option is selected and a pointcut
expression that specifies where the variable option is
weaved. For instance, consider variability “One-Line
Display” in Figure 7. The variability may affect all the
other use cases in the model when condition “One
Line Display option is selected” holds and it is weaved
before step 1 of affected use cases. There can be multiple
pointcut expressions attached to a single “variability”
relation. For instance, in Figure 6 the “Light” option is
weaved according to pointcuts “concurrent operations
User opens *” and “concurrent operations Microwave
System starts *”.
UCEd uses a ”tree” representation for use case models
such that properties attached to a relation appears as
children of that relation. This results in a representation
where, variations in the product line are clearly distin-
guishable and identifiable. UCEd allows all variabilities
in a product family to be modeled at the same time. Spe-
cific variabilities can be selected to form distinct mem-
bers of the product family during composition.
Figure 6. UCEd use case integration tool
3.4 Product Generation
In order to generate a Petri net for a particular product
within a product line, we need to specify which set of
options apply. UCEd includes an integration tool to en-
able the selection of relevant features. Figure 6, illus-
trates the UCEd use case integration tool. Use cases
listed in the integration tool are populated based on the
“variability” relationship. Variable options that are se-
lected are weaved with the common options and the cor-
responding Petri nets are generated. For instance, Table 1
shows the different feature sets for microwave oven
models A and B.
Figure 6 shows the feature set selection for Model A in
UCEd. The model consists of a Boolean weight sensor,
one-line display panel, one-level heating element and a
beeper as an optional feature. Figure 10 shows the ad-
vices use cases (variabilities) for model A and B.
Figure 8 shows the Petri net obtained from the compo-
sition of the features in Model A while Figure 9 shows
the Petri net obtained from the composition of the fea-
tures in Model B.
Notice that <<variability>> conditions are not in-
cluded in the generated Petri nets. Disabled variabilities
are simply ignored from the resulting model. This allows
the derivation of Petri nets specific to each member of a
product family.
Table 2 shows how the different composition types are
used for variabilities. The weaving of variability behav-
iors occurs after, before, around or concurrent to use
case description elements such as operations, steps, ex-
tension points etc. Optional and alternative variabilities
are weaved with after, before, or concurrent composition
types. For instance, in Figure 7, the “Boolean Weight”
variability is weaved after operation s User puts * and the
“One-Line Display” option is weaved before step 1 of
use case “Cook Food”. While, the around type can be
used to substitute behaviors in commonalities with new
behaviors. For instance, suppose that step 8 in use case
“Cook Food” is expressed as follows: “The Microwave
System continually cooks and displays the cooking time
remaining with a one-line display panel”. An arou nd
composition type can be used to replace the one-line dis-
play panel to with multi-line display panel. We consider
the concurrent composition as an essential composition
type for use case modeling and to model variabilities and
commonalities within a software product family (refer
section 3.2) since it allows several operations (or use
cases) to execute in parallel.
Table 1. Feature set for microwave ovens Model A and B
Model A Model B
Boolean Weight
One-Line Display
One-Level Heating
Beeper
Boolean Weight
Multi-Line Display
One-Level Heating
Turntable
Beeper
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines
254
UC
UC
UC
UC
UC
Va
VaC
VaP
Va
VaC
VaP
Va
VaC
VaP
Va
VaC
VaP
Cook Food
Boolean Weight
Boolean Weight −> *
Boolean Weight option is selected
after operation User puts *
Analog Weight
Analog Weight −>*
Analog Weight option is selected
after operation User puts *
One − Line Display
One − Line Display −> *
One − Line Display option is selected
before step 1
Multi − Line Display
Multi − Line Display −> *
Multi − Line Display option is selected
before step 1
Figure 7. UCEd representation of variabilities with “variability” relations
p0 p1
B1 1
p2
2
p3
A1
p4
p5
c1
p7
A1.a.1
p6
¬c1
A2
p8
p10
p9
3
4
p11
5
p12
6
p13
c2
p14
6.a.1
¬c2
p15
D1
p16
7
p17
p18
8
p19
9
10
p20
p21
E1
p22
11
p23
12
p24
13
14
p25
Figure 8. Petri net model for microwave oven Model A. We
use corresponding step numbe rs as labels for transitions. c1
is condition “No item is present” and c2 is condition
“Cooking time is zero”
Figure 9. Petri net model for microwave oven Model B
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines 255
Title: Boolean Weight
Goal: To check that item is present in the oven
Steps:
A1.The Microwave System checks for items in the oven
A2.IF an item is present THEN the Weight Sensor indicates to the
Microwave System that an item is present
Alternatives:
A1.a.No item is present
A1.a.1.The Weight Sensor indicates to the Microwave System
that no item is present
Title: One-Line Display
Goal: To display messages and cooking time
Steps:
B1.The Microwave System enables one-line display panel
Title: Multi-Line Display
Goal: To display messages and cooking time
Steps:
C1.The Microwave System enables multi-line display panel
Title: One-Level Heating
Goal: To heat food
Steps:
D1.The Microwave System enables one-level heating capability
Title: Beeper
Goal: To indicate user when cooking stops
Steps:
E1.The Microwave System activates the beeper when cooking stops
Title: Turntable
Goal: To rotate food while cooking in progress
Steps:
F1.The Microwave System rotates for the duration of cooking
Figure 10. Advice use cases “Boolean Weight”, “One-Line
Display”, “Multi-Line Display”, “One-Level Heating”,
“Beeper” and “Turntable”
Table 2. Composition types
Compositions
After
Weave behavior after a use case description ele-
ment
Before Weave behavior before a use case description element
Concur-
rent Weave variable behavior in parallel with a use case
description element
Around Substitute a use case description element with variable
behavior
Some inconsistencies that may result from the combi-
nation of variabilities and commonalities can be identi-
fied using Petri nets analysis techniques integrated to
UCEd [8]. UCEd also implements an algorithm for State
Charts generation from Petri nets [13].
Figure 11 illustrates the UCEd generated State Chart
for Model A with the weaved variabilities in bold.
UCEd allows simulation of the resulting State Charts
as prototypes. It is thus possible to validate specific
product member’s characteristics within a product family.
Furthermore, test cases can be derived for early valida-
tions of specific member of a product family.
4. Related Work
In [4], Gomma presents a UML-based software design
Figure 11. State chart for microwave oven Model A
method for software product lines called PLUS (Product
Line UML-Based Software Engineering). The PLUS
method extends the UML-based modeling approaches
that are usually used for single systems to address soft-
ware product lines. The objective of PLUS is to explic-
itly model commonalities and variabilities in a software
product line. The method includes three stages: software
product line requirements modeling, software product
line analysis modeling and software product line design
modeling. Firstly, during requirements modeling, kernel,
optional and alternative use cases are developed to define
the functional requirements of a system. The approach
introduces UML stereotypes “kernel”, “alternatives”
and “optional” to distinguish common and variable use
case specifications in software product lines. Kernel use
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines
256
cases describe functionalities that are common to all
members of a software product line, whereas optional
and alternative use cases describe variable functionalities
which are specific to only certain members of a product
line family. The approach also uses variation points to
describe the location in a use case where a change can
take place. Variation points are defined in a variation
point section within a use case. Each identifies a line
number where variability can be introduced or a condi-
tional “extend” or “include” relationship. A feature
model is then developed to capture the product line
commonalities and variabilities and to describe how they
relate to the use case models. During the analysis model-
ing, while static models are developed for defining kernel,
optional and variant classes and their relationships, dy-
namic models which include state charts and interaction
models are also developed. The state charts define the
state dependent aspect of a product line and the interac-
tion models describe the dynamic interaction between the
objects that participate in each kernel, optional and al-
ternative use case. Finally, during the design modeling
stage, the component-based software architecture for the
product line is developed. A similarity between our ap-
proach and the PLUS method is that use cases serve to
capture requirements for product line systems. However,
there are several differences between our work and the
PLUS method. Our scope is limited to requirement
specification while PLUS aims to address the whole de-
velopment cycle. Another distinction between our work
and PLUS concerns the way variation points are speci-
fied within variable use cases. Variation points are ex-
plicitly expressed in [4] and traditional use case relation-
ships (“extend” and “include”) are used to link variabili-
ties with commonalities. This creates a strong depend-
ency between variable and kernel (base) use cases which
limit flexibility and modularity. A similar approach,
where variation points are explicitly specified in base use
cases and “extend” or “generalization” relations are used
to link variabilities, is used in [3]. By modeling variabili-
ties as aspects and by using parameterized pattern based
pointcuts, we avoid the dependency problem and allow
the independent modeling of variabilities and commonal-
ities. Unlike [3,4], we also propose a composition
mechanism that allows the derivation of an executable
behaviour model for each member of a product line fam-
ily automatically integrating common elements with the
applicable variable elements.
John and Muthig [5] describe how commonality and
variabilities can be integrated and described in use case
diagrams and textual use case descriptions. The approach
allows modeling of variabilities by introducing a new
type of use case stereotyped “variant”. Entire sections of
use case diagrams may also be marked as variable and
XML tags ‘variant’ ‘/variant’ may be used to mark op-
tional and alternative steps (and scenarios) in use case
descriptions. The approach in [5] is very similar to
Gomma's approach [4]; in that both extend the traditional
use case modeling approach to accommodate modeling
of commonality and variability is software product lines.
The approach illustrates how a particular single-system
use case can be extended to capture product line infor-
mation, especially variabilities. However, while defining
variabilities with a use case stereotyped as “variant” is
an effective way to separate variable behaviours from the
common behaviours in a product line, it forces require-
ments engineers to again adapt to a new type of use case.
Furthermore, using XML tags ‘variant’ ‘/variant’ to
mark optional and alternative steps (and scenarios)
within use case specifications causes significant clutter-
ing and thereby reduces readability. In our approach,
variabilities and commonalities are modeled as normal
use cases. We introduce a “variability” relation that links
the selected variabilities to the base use cases based on
pointcut expressions. The application of aspect- orienta-
tion allows variabilities and commonalities to be sepa-
rately modeled and thus improves readability and main-
tainability. An additional advantage of our approach over
[5] is that it allows the automated derivation of an ex-
ecutable specification for each product starting from tex-
tual use cases.
Our approach can also be seen as related to approaches
that focus on the application of aspects to product lines
modeling in general. There has been a significant interest
in the AOSD community emphasizing the relations be-
tween variability and commonality in a software product
line with aspects at the requirements engineering stage.
Aspect-Oriented Software Product Lines (AOSPL) [21] is
part of AOSD which focuses on early aspects in product
lines. Various approaches suggest that variabilities in
software product lines be modeled in the same manner as
crosscutting concerns. For example Saleh and Gomaa
[10] suggest grouping optional and alternative source
code based on features in a variable source code file.
This variable source file corresponds to an aspect file.
Desired features can be selected and checked for consis-
tency with a prototype tool which then are automatically
integrated and compiled with the kernel source code to
generate an executable member of a product line.
Loughran et al. [9] use aspect-oriented techniques with
natural language processing to facilitate requirements
analysis and concern identification for the derivation of
suitable feature-oriented models for implementation.
This approach is implemented in a tool called NAPLES.
The tool takes textual requirements, deduces concerns,
aspects, feature commonalities and variabilities to ease
implementation. Siy et al. [11] present an approach to
separate functional requirements as viewpoints and
non-functional requirements into aspects similar to AR-
CADE [22]. Their approach includes parameterization of
requirements and a composition mechanism.
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines 257
Our approach is similar to [9–11] by the application of
AOSD to product lines. A major distinction is that we
model crosscutting requirements and variabilities using
use cases in textual form. Use cases enable the applica-
tion of aspect-orientation early in the development life-
cycle and thus, prevent crosscutting requirements from
being overlooked.
5. Discussion & Conclusion
In this paper, we presented an approach for use case
based modeling of software product line systems. We
introduced a “variability” relation; a specialization of an
“aspect” relation proposed for modeling crosscutting
concerns [8]. Use case description elements are used as
joinpoints and variable requirements are weaved with
common requirements based on specified pointcut ex-
pressions. Selected variabilities and commonalities are
composed and transformed into Petri net models as a step
toward UML State Charts generation. The whole ap-
proach is automated and tool supported by adding exten-
sions to UCEd, an existing use case-modeling tool.
UCEd includes facilities for simulation of generated state
charts and test generation. The simulation of a product
model enables early validation of specific product mem-
bers in the product family.
We noted some limitations to our proposed approach.
For instance, some of the steps and operations required to
be re-written in order to match them with appropriate
pointcut expressions and ensure correct composition. For
example, in our Microwave Oven example the “Analog
Weight” advice use case is weaved after operations User
puts *. The modeler should verify the base use case to
make sure that the “Analog Weight” advice is only
weaved at the relevant places and there are no other op-
erations that would match the specified pointcut. We also
found that not all variabilities could be modeled easily.
Examples of such variabilities are “One-Line Display
Unit” and “Display Languages” [4]. These variabilities
are more of initialization type. Therefore, multiple
weaving at different locations is not appropriate. Thus,
we cater a workaround in that; these variabilities are ini-
tialized before the execution of affected base use cases.
For instance, “One-Line Display Unit” is weaved before
step 1 of use case “Cook Food”. Another potential prob-
lem is the scalability and complexity of resulting Petri
net models when a great number of variability options
are composed together for a specific product in a product
family. This may make it harder to read and understand
the resulting models and leave only simulation as valida-
tion approach.
In our future work, we plan to apply our approach to
more case studies and investigate further ways of model-
ing variabilities and commonalities for software product
lines in UCEd. We also plan to explore other composi-
tion types (besides before, after, around and concurrent)
and define a more detailed joinpoint structure.
REFERENCES
[1] P. Clements and L. Northrop, “Software product lines:
Practices and patterns,” Addison-Wesley Longman Pub-
lishing Co., Inc., Boston, MA, USA, 2001.
[2] E. Ecklund, L. Delcambre, and M. Freiling, “Change
cases-Use cases that identify future requirements,” Pro-
ceedings of OOPSLA 96, San Jose, Ca, pp. 342358,
October 1996.
[3] I. Jacobson, M. Griss, and P. Jonsson, “Software re-
use–Architecture,” Process and Organization for Business
success, Addison-Wesley, 1997.
[4] H. Gomaa, “Designing software product lines with
UML–From use cases to pattern-based software architec-
tures,” Addison-Wesley, 2004.
[5] I. John, and D. Muthig, “Product line modeling with ge-
neric use cases,” SPLC-2 Workshop on Techniques for
Exploiting Commonality Through Variability Manage-
ment, Second Software Product Line Conference, San
Diego, USA, August 2002.
[6] S. Somé, “Supporting use cases based requirements en-
gineering,” Information and Software Technology, Vol.
48(1), pp. 43–58, 2006.
[7] Use Case Editor (UCEd) toolset,
http://www.site.uott-awa.ca/~ssome/UseCaseEditorUCE
d.html.
[8] S. S. Somé and P. Anthonysamy, “An approach for as-
pect-oriented use case modeling,” Workshop on Early
Aspects at ICSE 2008: Aspect-Oriented Requirements
Engineering and Architecture Design, May 2008.
[9] N. Loughran, A. Sampaio, and A. Rashid, “From re-
quirements documents to feature models for aspect ori-
ented product line implementation,” Workshop on MDD
in Product Lines at MODELS, 2005.
[10] M. Saleh and H. Gomaa, “Separation of concerns in
software product line engineering,” In Proceedings of the
2005 Workshop on Modeling and Analysis of concerns in
Software. St. Louis, Missouri, 2005.
[11] H. Siy, P. Aryal, V. Winter, and M. Zand, “Aspectual
support for specifying requirements in software product
Lines,” Workshop on Early Aspects at ICSE. Minneapolis,
USA, May 2007.
[12] OMG: UML 2.1.2 Superstructure Object Management
Group, 2007.
[13] S. S. Somé, “Petri nets based formalization of textual use
cases,” Technical Report TR-2007-11, SITE, University
of Ottawa, 2007.
[14] C. A. Petri, “Communication with Automata,” PhD thesis,
Technische Universitat Darmstadt, 1962.
[15] I. Jacobson and P. W. Ng, “Aspect-oriented software
development with use cases,” Addison Wesley, 2005.
[16] J. Araújo and A. M. D. Moreira, “An aspectual use case
driven approach,” In VIII Jornadas Ingeniería del Soft-
ware y Bases deDatos (JISBD 2003), pp. 463468, 2003.
Copyright © 2009 SciRes JSEA
An Aspect-Oriented Approach for Use Case Based Modeling of Software Product Lines
Copyright © 2009 SciRes JSEA
258
[17] R. Chitchyan, A. Rashid, P. Rayson, and R. Waters, “Se-
mantics-based composition for aspect-oriented require-
ments engineering,” In: AOSD ’07: Proceedings of the 6th
International conference on Aspect-oriented software de-
velopment, ACM, pp. 36–48, 2007.
[18] AspectJ Project, http://www.eclipse.org/aspectj/.
[19] R. Stoiber, S. Meier, and M. Glinz, “Visualizing product
line domain variability by aspect-oriented modeling,”
Proceedings of the 2nd International Workshop on Re-
quirements Engineering Visualization (REV'07), in con-
junction with RE'07. New Delhi, India.
[20] M. Griss, J. Favaro, and M. d’Alessandro, “Integrating
feature modeling with the RSEB,” Proceedings of Fifth
International Conference on Software Reuse, Victoria,
B.C., 1998.
[21] Aspects and Software Product Lines (EA-SPLC),
http://trese.cs.utwente.nl/workshops/early-aspects-SPLC2
005/.
[22] A. Rashid, A. Moreira, and J. Araújo, “Modularization
and composition of aspectual requirements,” In Proc. of
the 2nd International Conference on Aspect-Oriented
Software Development (AOSD’03), Boston, MA, pp.
11–20, March 2003.