27.03.2014 Views

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

descriptions must also b e configured by eliminating the steps<br />

that are annotated with features that were not chosen.<br />

IV. RELATED WORK<br />

Compared to G2SPL [3], our work has two main<br />

differences: (i) it uses PLUSS scenarios to capture behavioral<br />

characteristics of the SPL, while G2SPL cannot capture the<br />

SPL’s behavior; (ii) our approach allows to ch oose a<br />

configuration based on the priority to the softgoals, while<br />

G2SPL does not provide such a mechanism.<br />

Asadi et al. [12] also proposed a GORE approach for SPL<br />

using i*. It u ses annotations on the feature model do relate<br />

goals and features. The advantage of this approach is that it has<br />

tool support, providing an automatic way to obtain the<br />

product’s features from selected goals. However, the FM is not<br />

obtained systematically from stakeholders’ goals, it is created<br />

separately and then annotated with goals. This approach does<br />

not capture the behavior of the SPL either.<br />

Santos et al. [13] proposed a bidirectional mapping between<br />

feature models and goal models in the PL-AOVgraph<br />

approach. Thus, not only the FM can be obtained from the goal<br />

model, as in G2SPL and GS2SPL, but the goal model can be<br />

derived from the feature model too. The bidirectional mapping<br />

has tool support, but it covers only the Domain Engineering<br />

requirements phase, i.e., it does not provide a way to configure<br />

products.<br />

Mussbacher et al. [14] proposed ASF (AoURN-based SPL<br />

Framework), a framework that integrates goal models, feature<br />

models and scenarios and is completely tool supported. The<br />

goal models are described in GRL (Goal-oriented Requirement<br />

Language), another i* extension, and is related to the FM<br />

through the feature impact model. Scenarios are described in<br />

UCM (Use Case Maps), a visual notation whose elements may<br />

be associated with GRL elements. However, this association<br />

must be defined by the Domain Engineer and there are no<br />

mapping rules defined on the framework. Goals and softgoals<br />

in GRL may have an “importance” attribute that allows<br />

stakeholders to indicate how important these elements are for<br />

them. This attribute is used during product configuration to<br />

prioritize the most important goals and softgoals. This<br />

represents an advantage compared to GS2SPL, since our<br />

approach prioritizes only softgoals.<br />

Despite the fact that all ASF artifacts may be associated<br />

with each other, they are created separately, i.e., it is n ot<br />

possible to systematically obtain one model from another.<br />

Besides, the elaboration of the feature impact model is,<br />

according to Mussbacher et al. [14], a complex task, since it<br />

consists of a goal graph for each feature, describing how a<br />

feature affects stakeholders’ goals.<br />

V. CONCLUSION AND FUTURE WORK<br />

This paper presented a GORE approach for SPL, called<br />

Goals and Scenarios to Software Product Line (GS2SPL).<br />

GS2SPL allows the domain engineer to generate feature<br />

models and use case scenarios from i* goal models. The benefit<br />

of this generation is that the most relevant features and use<br />

cases to the stakeholders’ goals are obtained in a systematic<br />

way. Another contribution of our approach is the inclusion of a<br />

configuration process that allows the clients to choose their<br />

product configuration on a higher abstraction level. Instead of<br />

choosing specific features, they can choose the goals they want<br />

to achieve. The configuration process also takes softgoals<br />

(NFRs) into account, providing a way to rank possible variants<br />

according to the softgoals’ priority given by the client.<br />

As future work, we plan to: (i) perform case studies in<br />

different domains to evaluate the strengths and weaknesses of<br />

GS2SPL; (ii) develop tool support for our approach; (iii)<br />

investigate how to identify feature model constraints from i*<br />

models; and (iv) investigate how to take feature interactions<br />

into account when generating use case scenarios.<br />

REFERENCES<br />

[1] A. Lamsweerde, “Goal-oriented requirements engineering: a guided<br />

tour,” in Proc. of t he 5 th IEEE International Requirements Engineering<br />

Conf. (RE’01), Washington, DC, USA, pp. 249-263, 2001.<br />

[2] C. Borba and C. Silva, “A comparison of goal-oriented approaches to<br />

model software product lines variability,” in LNCS, vol. 5833, pp.244-<br />

253, Springer-Verlag, 2009.<br />

[3] C. Silva, C. Borba, J. Castro, “A goal oriented approach to identify and<br />

configure feature models for software product lines,” in Proc. of the 14 th<br />

Workshop on Requirements Engineering (WER’11), Rio de Janeiro,<br />

Brazil, pp. 395-406, 2011.<br />

[4] N. Maiden, I. Alexander. Scenarios, stories, use cases: through the<br />

systems development life-cycle. 1 st ed., Wiley, 2004.<br />

[5] P. Clements and L. Northrop. Software product lines: practices and<br />

patterns. 1 st ed., Addison-Wesley, 2002.<br />

[6] K. Pohl, G. Böckle, F. van der Linden. Software product line<br />

engineering: foundations, principles, and techniques. 1 st ed., Springer,<br />

2005.<br />

[7] E. Yu, “Modeling strategic relationships for process reengineering,” in<br />

Social Modeling for Requirements Engineering, E. Yu, P. Giorgini, N.<br />

Maiden, J. Mylopoulos, 1 st ed., MIT Press, 2011, ch. 2, pp. 11-152.<br />

[8] E. Figueiredo et al., “Evolving software product lines with aspects: an<br />

empirical study on design stability,” in Proc. of the 30 th International<br />

Conference on Software Software Engineering (ICSE’08), Leipzig,<br />

Germany, pp. 261-270, 2008.<br />

[9] M. Eriksson, J. Börstler, K. Borg, “Managing requirements<br />

specifications for product lines – an approach and industry case study,”<br />

in Journal of <strong>Systems</strong> and Software, vol. 82, n. 3, pp. 435-447, 2009.<br />

[10] J. Castro, F. Alencar, V. Santander, C. Silva, “Integration of i* and<br />

oject-oriented models,” in Social Modeling for Requirements<br />

Engineering, E. Yu, P. Giorgini, N. Maiden, J. Mylopoulos, 1 st ed., MIT<br />

Press, 2011, ch. 13, pp. 457-483.<br />

[11] C. Lima, “E-SPL – a ap proach for requirements phase in domain<br />

engineering and application engineering with goal models,” (in<br />

Portuguese: “E-SPL - um a abordagem para a f ase de requisitos na<br />

engenharia de domínio e na engenharia de aplicação com modelos de<br />

objetivos”) Dissertation (MSc), Center of Informatics, UFPE, Brazil,<br />

2011.<br />

[12] M. Asadi, E. Bagheri, D. Gasevic, M. Hatala, B. Mohabbati, “Goaldriven<br />

software product line engineering,” in Proc. of th e 26 th ACM<br />

Symposium on Applied Computing (SAC’11), Taichung, Taiwan, pp.<br />

691-698, 2011.<br />

[13] L. Santos, L. Silva, T. Batista, “On the integration of the feature model<br />

and PL-AOVGraph,” in Proc. of the 2011 International Workshop on<br />

Early Aspects (EA’11), Porto de Galinhas, Brazil, pp. 31-36, 2011.<br />

[14] G. Mussbacher, J. Araújo, A. Moreira, D. Amyot, “AoURN-based<br />

modeling and analysis of software product lines,” in Soft ware Quality<br />

Journal (online first), 2011.<br />

656

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!