http://www.mercubuana.ac.id
Advanced Science and Technology Letters
Vol.28 (NT 2013), pp.19-24
http://dx.doi.org/10.14257/astl.2013.28.05
Constructing Domain
Feature Models Based on
the i*
Framework
Yifei Zhang1, Dongjin Yu1 and Wei
Wu2
1 School
2
of Computer, Hangzhou Dianzi
University, Hangzhou, China
Zhejiang Provincial Key Laboratory of
Network Technology and Information
Security,
Hangzhou, China
yudj@hdu.edu.cn, ww@topcheer.cn
Abstract. In recent years, a range of
approaches that map the goal models to
the feature models are proposed in order
to construct the traceability of commonality and variability during the
Software Product Line Engineering. However, these approaches can only map part
of elements. How to map the
dependencies among actors to feature
models is still left as an open problem. In
this paper, we adopt the standard goaloriented
requirements
engineering
framework, i.e., the i* framework, for
constructing the domain feature model.
We propose the mapping rules and also
the algorithm of mapping dependencies
among actors to feature models. The
experiment shows that our approach is
practical.
Keywords: goal-oriented approach;
i*framework; software product line;
feature model; application product
customization
1 Introduction
In
the
process
of
software
development based on Software
Product Line (SPL), the feature, as a
cohesive
set
of
individual
requirements, is used to describe the
domain commonality and variability
[1] [2]. Although the feature
expresses a user capability of a
software system, it cannot describe
non-system (environment) factor and
quality characteristic [3]. Moreover,
since the feature model is just a
http://www.mercubuana.ac.id
Advanced Science and Technology Letters Vol.28 (NT 2013)
approaches can only map part of elements. To map the dependencies among actors to
the feature models is still left as an open problem. In addition, there is lack of essential
associations among the feature models which are constructed by different actors. In
this paper, we adopt the i* framework to construct the domain feature model. We
propose the rules and the algorithm used to map dependencies among the actors to the
more complete feature models. Besides, we initiate to customize the application products using the i* model evaluation approach [6] [7] during the application engineering
phase. By using our approach, the reason of selecting the specific features to customize an application product can be clearly elucidated.
The rest of the paper is organized as follows. After Section 2 presents the mapping
rules between the i* framework and the feature model, Section 3 describes in detail
the whole process to construct the domain feature model based on the i* framework.
The case studies are given in Section 4. Finally, the last section concludes the paper
and outlines the future work.
2 Rules Mapping between the i* Framework and the Feature Model
Diverse combinations of the goal models and feature models are shown in different
structural types where some corresponding traceability may exist. We conclude 7
rules mapping between the i* framework and the feature models, which are shown in
Fig. 1.
3 Constructing the Domain Feature Model Based on the i*
Framework
In this section, we provide an automatic algorithm of constructing initial domain feature model based on the i*framework, which could be then adjusted to form the final
domain feature model.
3.1 Constructing the initial domain feature model
The i* framework may contain several actors that are expressed as types of software
system and environment, each of them interacting with others to achieve the goals.
First of all, we should sequentially select the actor expressing the software system as
the mapping object because features cannot depict non-system (environment) factor.
Based on [8], we propose the algorithm for constructing the feature tree model by
mapping dependencies among actors. Firstly, we select an actor randomly and generate a collection that contains all the elements which possess dependencies. Then, by
applying the rules given above, we map the dependency elements and links to the
feature fragments in order to associate features belonging to different feature trees.
Thus, an initial domain feature model can be formed after all actors are treated in this
way.
20 Copyright © 2013 SERSC
Advanced Science and Technology Letters
t1g1g1g1
X
g2 t3 s 4 t2 t3 t2 t3 t2 t3
f1f1
f 2
f1f1
f 2
f 3
f 2
f 3
f 2
f 3
(a) (b) (c) (d)
a c tor a c tor
t1
D
r 2 Dt 3
a c tor a c tor
t 1 D r 2Dg 3
Opposite Contributions of
the Same Extent
actor a c tor
p 1
D
p 2
D
p 3
S1
a c tor a c tor
g
1
r
D
2
D
t
3
p
1
p
2
f 1
f 2
(
LEGEND
Resource-Configure
f3f1
e
Actor and
Actor Boundary
Task−Decomposition
link
)
GoalTask
(
f
)
f 1
f 3
(
g
f 2
)
Resource Softgoal Placeholder Non-system Elements Are Indicated
byDotted Shapes
Means−ends link D Dependency X Inclusion Relationship OfMeans−ends Links
Mandatory ___________
Optional
And Or Alternative
mapping link
Requires Excludes
feature group feature group feature group
Vol.28 (NT 2013)
Fig. 1. Rules mapping between the i* framework and the feature model 3.2 Adjusting the
initial domain feature model
After constructing initial domain feature model, we should further adjust the initial
domain feature model according to our own experience and understanding in the domain. The initial domain feature model merely contains the feature trees which do not
have a common root node. Therefore, we regard the whole system as the root node
and merge each feature tree as its child respectively. In addition, we modify the features’ names in order to make them more illustrative, and meantime remove the redundant features if necessary.
4 Case studies
Our proposed approach is successfully applied in the Hearing-aids Sales and Distribution Software Product Line (HSDSPL), whose i* model is described in Fig. 2.
Copyright © 2013 SERSC 21
Advanced Science and Technology Letters Vol.28 (NT 2013)
Se l l H e a r i n g A i d s
A f f i l i a t i o n
S y s t e m
H e a d q u a r t e r s s y s t e m
G o o d s
P r o c e s s
O r d e r
R e s e r va t i o n
Management
R e s e r va t i
on Method
O n li n e
quickness
By Phone
M a n a g e
O r de r
C us tom e r
S ati s f acti on
Q u e r y
& M o d i f y
O rd e r
O r d e r
G o o d s
H a n d l
P l a c e e t h e
O r d e r A r r i v als
Q u e ry
M a n a g e
C h a r g e
C h a r g e
C h a rg e t h e
CustomizeO r d i n a r y
G o o d s
d
E d i t
O r d e r
I n p u t
O r d i n a ry
O r d e r
G o o d s
I n f o
I n p u t
Save
Customize
dOrder
Convenience
I n p u t b y
p r o m p t In p u t
M an ua l l y
b o x
Choos e Model of
the Cus tom i zed
O r d i n a r y
G o o d s
Commit
C l i e n t
Info
reusability
X
A d d
C l i e n t
Recall
Registered
Client
H e a r i n g a i d s B e
C h o s e n
O rd e r t h e
Customized
Mi n Di s c ount
Be Controlled
t h e
Customized
P r o h i b i t S
Ha ndle
u b m i t t i n g
Specially
O r d e r
Legend
Order Check&
Updat e
i n v e n t o ry
Pa ssRetu rn
P ri nt B ar
c ode
C l i e n t
I n f o
Input Info of the
Customized
Verify
S p e c i al
D i s c o un t
X
P ri nt
O r d er
B u s i n e s s O
p e r a t i o n
Check
Det a ils
O r d e r
P rinti ng
M o d i f y
Client Sign in
S h i p
Veri fi ng
V e r i f y
O r d e r
R e s e r ve t h e
C u s t om i z e d
B
s
r
o
u
s
d
o
y a c c e
o r i e ( O
i n a r y G
d s )
Get the
Customized
Actor
G o al T a s k
Resource Softgoa
Actor Boundary
Task−Decomposition
link
Means−ends link
Dependency
Non-system Elements Are Indicated by
Dotted Shapes
Make Contribution Help Contribution
Break ContributionX Inclusion Relationship Of Means−ends Links
Fig. 2. The i* model of HSDSPL
There are three actors representing the division system, the headquarters system
and the client respectively. Since Actor Client is a non-system element, it cannot be
mapped in the feature model. Actor Division is responsible for selling hearing-aids
and accessories supplied by the headquarters, whereas Actor Headquarters is responsible for the production of hearing-aids and accessories. During the actual operation,
the divisions send orders to the headquarters. After the orders are examined and confirmed, the headquarters produces and delivers the customized goods or just delivers
the off-the-shelf goods directly to divisions. The domain feature model corresponding
to Fig. 2 based on our approach is shown in Fig. 3.
22 Copyright © 2013 SERSC
Advanced Science and Technology Letters
Vol.28 (NT 2013)
Legend
Feature MandatoryOptional Requires Excludes
HSDSPL
Manage
Reservation
Client
Reserve
Sign in
P l a c e
O r d e r
E d i t
O r d e r
Handle the
Arrivals Query
Operate
Input
Input
C u s t o m i z e d Save
Ordinary
Or der
O r d e r
G o o d s
I n f o
C l i e n t
I n f o
Input by
prompt box
Add
Clien t
Q u e r y
& M o d i f y
O r d e r
Order G
o o d s
Alternative
feature group
Ma n a g e
C h a r ge
Ma n a ge Or der
Ma n a g e
Met h od
Reser ve
On lin e
Resource-Configure
Charge
the Customized
Print
And
feature group
P r o c e s s
O r d e r
Charge
OrdinarySh ip
Goods
P r i n t
O r d e r
V e r i f y
O r d e r
Print
Bar code
Order Be
Choose Model of C o r r e c t e d
the Customized
Pay
Deposit
V e r i f yi n g
Check& Update
Inventory
Modify
Commit
O r
feature group
Verify
Special
Discount
Check
Details
Pass
Retur n
Control Min
Discount
Handle
Recall
Regi st er ed P r o h i b i t S p e c i a l l y
Submitting
Clien t
Order
Apply for
Discount
Fig. 3. The domain feature model of HSDSPL
5 Conclusions
In this paper, we adopt the i* framework to construct domain feature model. We propose the algorithm to map the dependencies among actors to feature models. Besides,
we initiate to customize an application product using the i* model evaluation during
the application engineering phase.
Sometimes, the softgoal dependencies among actors involve other softgoals, and are
shown in different situations. To the best of our knowledge, however, it’s difficult to
propose rules mapping softgoal dependencies among actors. We intend to further
study the approach and propose a more complete solution in the future. In addition,
combining our approach with the scenario method for feature dependencies study to
guide the architectural design is also on the list of our future work.
Acknowledgments. The work is supported by the Key Science and Technology Project of Zhejiang (No. 2012C11026-3, No. 2008C11099-1) and the open project foundation of Zhejiang Provincial Key Laboratory of Network Technology and Information Security. The authors would also like to thank anonymous reviewers who
made valuable suggestions to improve the quality of the paper.
Copyright © 2013 SERSC 23
http://www.mercubuana.ac.id
Advanced Science and Technology Letters Vol.28 (NT 2013)
References
1.K.Pohl, G.Böckle, and Frank van der Linden: Software Product Line Engineering Foundations, Principles, and Techniques. Springer Verlag, Heidelberg (2005)
2.Kang, K.C., Lee, J., and Donohoe, P.: Feature-Oriented Product Line Engineering. IEEE
Software 19, pp. 58-65 (2002)
3.W. Zhang, H. Mei, and H. Zhao: Feature-driven Requirement Dependency Analysis and Highlevel Software Design. In Requirements Engineering, vol. 11, no. 3, pp. 205-220 (2006)
4.Yu. Towards modeling and reasoning support for early-phase requirements engineering. In
Proceedings of the IEEE International Symposium on Requirement Engineering, pp. 226– 235.
IEEE Computer Society (1997)
5.E. Yu and J. Mylopoulos: Understanding why in software process modeling, analysis, and
design. In Proc. 16th Intl. Conf. on Soft. Eng., May 16-21, pp. 159–168 (1994).
6.Horkoff, J.: Using i* modeling for evaluation, Master Thesis, University of Toronto, Department of Computer Science (2007)
7.Horkoff, J., Yu, E.: Evaluating Goal Achievement in Enterprise Modeling: An Interactive
Procedure and Experiences. In: The Practice of Enterprise Modeling. Springer, pp. 145160
(2009)
8.Yu, Y., Leite, J. C. S. D. P., La pouchnian, A. and Mylopoulos, J.: Configuring features with
stakeholder goals. In: Proc. ACM Symp. on Applied Computing , pp. 645-649 (2008)
24 Copyright © 2013 SERSC