Você está na página 1de 4

Uma Comparao entre Tcnicas de Modelagem de Requisitos

Orientados a Objetivos e a Aspectos


Dorgival Netto1, Mychelline Henrique1, Carla Silva2
1

Universidade Federal da Paraba (UFPB) - Centro de Cincias Aplicadas e Educao


2
Universidade Federal de Pernambuco (UFPE) Centro de Informtica
{dorgival.netto, mychelline.henrique}@dce.ufpb.br, ctlls@cin.ufpe.br

Abstract. Goal-Oriented Requirements Engineering (GORE) approaches can be


used in the engineering of Software Product Lines (SPL). Some GORE and aspectoriented approaches have been proposed to model the variability of requirements
and to best modularize the crosscutting concerns that can compromise the
maintainability and understanding of the SPL artifacts. This paper presents a
comparison between the approaches PL-AoVgraph (Aspect Oriented Product Line
V-Graph) and AoGRL (Aspect Oriented Requirements Language Goal - AoGRL)
using as evaluation criteria the characteristics that a notation to model variability
in SPL must have.
Resumo. Abordagens de Engenharia de Requisitos Orientada a Objetivos (do
ingls, Goal-Oriented Requirements Engineering ou GORE) podem ser usadas na
engenharia de Linhas de Produtos de Software (LPS). Algumas abordagens GORE
e orientadas a aspectos foram propostas para modelar a variabilidade de
requisitos e melhor modularizar os interesses transversais (do ingls, crosscuting
concerns) que podem comprometer a manutenabilidade e o entendimento dos
artefatos da LPS. Este artigo apresenta uma comparao entre as abordagens PLAOVgraph (do ingls, Product Line Aspect Oriented V-Graph) e AoGRL (do ingls,
Aspect Oriented Goal Requirements Language - AoGRL) usando como critrios de
avaliao as caractersticas que uma notao de modelagem de variabilidade em
LPS deve ter.

1. Introduo
A Engenharia de Requisitos (ER) cobre todas as atividades envolvidas na descoberta,
documentao e manuteno de um conjunto de requisitos para um determinado sistema
[Kotonya 1998]. A ER tanto pode ser aplicada para desenvolver produtos de software nicos,
como para desenvolver Linhas de Produtos de Software (LPS) [Clements and Northrop 2002]
Uma LPS, tambm chamada de famlia de produtos, um conjunto de sistemas de software
que compartilham um conjunto comum e gerenciado de features para satisfazer necessidades
especficas de um segmento particular de mercado [Clements and Northrop 2002]. Uma
feature pode ser vista como uma propriedade de sistema ou funcionalidade que relevante
para alguns stakeholders e usada para capturar features comuns e variveis entre produtos de
uma mesma famlia [Czarnecki and Eisenecker 2000].
As caractersticas de uma LPS precisam ser documentadas explicitamente para
possibilitar o reuso estratgico dos seus artefatos. Atualmente na ER para LPS, os modelos de
features so utilizados para capturar similaridades e variabilidades de famlias de produtos
[Kang et al. 1990]. Entretanto, um grande desafio estabelecer um relacionamento entre as
features de um produto de software e os objetivos dos stakeholders [Silva et al. 2011]. Neste
contexto, torna-se claro que abordagens de Engenharia de Requisitos Orientada a Objetivos
podem ser usadas de forma efetiva para capturar tanto os objetivos dos stakeholders como os
requisitos do sistema, de modo que o software a ser desenvolvido corresponda ao que

realmente os stakeholders desejam [Lamsweerde 2001]. Em particular, na Engenharia de


Linhas de Produtos de Software, muitas abordagens orientadas a objetivos foram propostas
visando capturar features de uma LPS utilizando modelos mais significativos, para manter o
rastreamento entre as features do sistema e suas motivaes, bem como para justificar a
configurao de alternativas de produto para a realizao dos objetivos dos stakeholders
[Silva et al. 2008]. No entanto, a especificao de features no-triviais misturam a
informao das variantes da LPS e da configurao dos produtos nos seus artefatos e pode
causar o espalhamento dos interesses relativos s features. Estes interesses so, portanto,
considerados transversais e podem comprometer a manutenabilidade e o entendimento dos
artefatos da LPS [Bonifcio and Borba 2009]. Para minimizar estes problemas, vrias
abordagens foram propostas para usar mecanismos da orientao a aspectos [Filman et al.
2005], a fim de melhor modularizar a especificao de interesses transversais em tcnicas de
modelagem de requisitos orientados a objetivos [Alencar et al. 2010; Santos et al. 2011;
Mussbacher et al. 2008]. Neste artigo, utilizaremos os critrios de avaliao de notaes de
modelagem de variabilidade em LPS definidos por Djebbi et al (2006), para comparar o PLAOVgraph e o AoGRL, que so duas tcnicas de modelagem de requisitos orientados a
objetivos e aspectos para representar variabilidade de LPS.
Alm desta seo introdutria, este artigo dividido na seo 2, que apresenta as
tcnicas de modelagem de requisitos orientadas a objetivos e aspectos comparadas. A seo 3
apresenta os critrios de comparao utilizados neste trabalho. A seo 4 apresenta o
resultado da comparao e a seo 5 apresenta as consideraes deste e os trabalhos futuros.

2. Viso Geral das Tcnicas Utilizadas


A tcnica PL-AoVGraph [Santos et al. 2011], uma extenso da linguagem AoVGraph, para
modelar LPS e prope um mapeamento bi-direcional com o modelo de features. Para
automatizar este mapeamento, existe uma ferramenta chamada ReqSys, baseada no Eclipse.
Esta extenso acrescentou quatro propriedades aos modelos AoVGraph, so elas: isFeature,
TypeFeature,
groupFeature
e
cardinalidade
(cardinalityMin,
cardinalityMax,
cardinalityGroupMin, cardinalityGroupMax). A propriedade isFeature indica se um objetivo
(goal), objetivo flexvel (softgoal) ou tarefa (task) representam uma feature da LPS. A
propriedade TypeFeature indica o tipo de elemento intencional (goal, softgoal ou task) que
originou a feature. A groupFeature indica se os elementos so agrupados e, por ltimo, a
cardinalidade que pode existir nos elementos ou nos grupos de elementos. De acordo com
Silva (2011), os relacionamentos existentes na linguagem PL-AoVGraph so: AND (feature
obrigatria), OR (opcional), Excl-OR (alternativa) e Inc-OR (ou-inclusivo).
A AoGRL uma extenso orientada a aspectos da GRL (do ingls, Goal
Requirements Language ou GRL) [Mussbacher et al. 2008]. A AoGRL permite a
representao de variabilidade em LPS, por meio de conceitos da orientao a aspectos, e
suportada pela ferramenta case jUCMNav1, tambm baseada no Eclipse.

3. Critrios Usados na Avaliao


A seo anterior apresentou brevemente as tcnicas PL-AoVGraph e AoGRL, que sero
avaliadas para determinar o nvel cobertura das caractersticas necessrias para linguagens de
modelagem de variabilidade em LPS propostas por [Djebbi et al. 2006] e detalhadas a seguir:
legibilidade diz que a linguagem deve possuir uma notao visual simples de fcil
compreenso, deve permitir modelar a parte comum e varivel de uma linha de produto;
simplicidade e expressividade indica que a linguagem deve conter o nmero mnimo de
objetos, atender as necessidades do usurio e o diagrama construdo no deve precisar de
nenhuma informao adicional para ser compreendido; a linguagem deve permitir a distino
1

Disponvel na internet em: http://www.ohloh.net/p/11712

entre os tipos de variabilidade; a linguagem deve permitir especificar os pontos de


variao e suas caractersticas, auxiliando a tomar decises sobre sua seleo, especificao;
escalabilidade indica que a linguagem deve permitir a modelagem de sistemas de grande
porte; a linguagem deve ter o suporte de alguma ferramenta CASE para a criao de
diagramas; A linguagem deve ser unificada em todo o ciclo de desenvolvimento de produtos
da linha, oferecendo meios para assegurar a rastreabilidade em todas as fases do
desenvolvimento; A notao deve partilhar de uma linguagem padronizada para evitar
interpretaes divergentes sobre o sistema que foi modelado (ambiguidade); a linguagem
deve permitir representar dependncias entre as partes variveis de uma LPS, isto ,
pode haver features dependentes entre si.
Djebbi et al. (2006) tambm props mais dois critrios de comparao,: apoio a
evoluo da linha de produtos e flexibilidade em ajustar-se s necessidades especficas de
cada empresa. Estes critrios no puderam ser utilizados na comparao porque seria preciso
aplic-los a diferentes projetos e empresas para que as tcnicas pudessem ser avaliadas.

4. Resultado da Avaliao
De acordo com os critrios citados na seo anterior, elaboramos uma anlise comparativa
entre as tcnicas AoGRL e PL-AoVGraph. Ao final das comparaes, temos a elaborao de
um quadro avaliativo (Tabela 1), com o propsito de fornecer uma base conceitual comum de
comparao e contrastar diferentes maneiras de modelar a variabilidade de requisitos em
LPS. Os nveis de suporte de cada tcnica com relao aos critrios utilizados so
representados por um ++ representando total suporte para o critrio avaliado, um +- que
representa suporte parcial aos critrios que no so atendidos satisfatoriamente e, um -representa ausncia de suporte.
Para representar as caractersticas semelhantes de um LPS, a notao AoGRL usa o
Base Model, enquanto que as caractersticas variveis so representadas atravs do Advice
Graph. Na notao PL-AoVGraph as variaes da LPS so representadas atravs do uso dos
relacionamentos de decomposio OR, Inc-OR e Excl-OR. Os modelos AoGRL estabelecem
a rastreabilidade entre os modelos de objetivo e cenrio, alm de dar suporte a anlise de
impacto das variabilidades sobre os objetivos dos stakeholders e sobre os objetivos gerais do
sistema. As propriedades de pontos de variao so identificadas atravs de um Pointcut
Graph que identifica o local no Base Model no qual a variabilidade acontece e esta, por sua
vez, representada pelo Advice Graph. A notao PL-AoVGraph representa a cardinalidade
nos relacionamentos AND (obrigatria) e OR (opcional). Alm disso, distino entre os tipos
de variabilidade representada pelos relacionamentos AND, OR, Inc-OR e Excl-OR. Os
elementos de um modelo PL-AoVGraph podem ser rastreados para elementos do modelo de
features. A notao PL-AoVGraph representa as dependncias entre partes variveis da LPS
relacionando features que representam requisitos funcionais a features que representam
requisitos no-funcionais.

Critrios

Legibilidade

Simplicidade e
Expressividade

Distino entre os
tipos de
variabilidade

Especificar os
Pontos de
Variao

Escalabilidade

Suporte a
ferramenta CASE

Unificao

Padronizao

Representar
dependncias
entre as partes
variveis de uma
LPS

Tabela 1. Critrios de comparao entre as tcnicas AOGRL e PL-AoVGraph

PL-AoVGraph
AoGRL

++
++

++
+-

++
+-

++
+-

++-

++
++

++
++

+++

+--

5. Consideraes e Trabalhos Futuros


Neste artigo ns analisamos duas tcnicas de modelagem de requisitos orientados a objetivos
e aspectos de acordo com os critrios de avaliao de notaes para modelagem de
variabilidade de LPS definidos em [Djebbi et al. 2006]. Com a realizao desta comparao,
observamos que o PL-AoVGraph d suporte a mais critrios do que a tcnica AoGRL. Como
trabalhos futuros, ser includa a tcnica i* Aspectual [Alencaret al. 2010] na comparao e
pretende-se investigar como uma das tcnicas analisadas pode ser integrada com uma tcnica
de especificao de cenrios aspectuais e com o modelo de features, para adaptar a
abordagem de Guedes et al. (2011), que atualmente no contempla separao de interesses
transversais.

6. Referncias
Alencar, F., Castro, J., Lucena, M., Santos, E., Silva, C., Arajo, J., and Moreira, A. (2010)
Towards Modular i* Models. In: Requirement Engineering Track, at 25th ACM
Symposium on Applied Computing (SAC), Sierre, Switzerland: ACM Press, pp. 292-297.
Bonifcio, R. and Borba, P. (2009) Modeling Scenario Variability as Crosscutting
Mechanisms. In: International Conference os Aspect-Oriented Software Development
(AOSD09), Charlottesville, Virginia, USA, March 26,.
Clements, P., Northrop, L. (2002) Software Product Lines: Practices and Patterns. AddisonWesley.
Czarnecki, K., Eisenecker, U. W. (2000) Generative Programming: Methods, Tools, and
Applications, ACM Press/Addison-Wesley Publishing Co.
Djebbi, O. and Salinesi, C. (2006) Criteria for Comparing Requirements Variability
Modeling Notations for Product Lines. In Fourth International Workshop on
Comparative Evaluation in Requirements Engineering (CERE '06), pp. 20-35.
Filman, R., Elrad, T., Clarke, S. and Aksit, M. (2005) Aspect- Oriented Software
Development, Addison-Wesley.
Guedes, G., Silva, C., Castro, J., Soares, M., Dermeval, D., Souza, C. (2012) GS2SPL:
Goals and Scenarios to Software Product Lines. In: The 24th Intl. Conf. on Software
Engineering and Knowledge Engineering (SEKE12), Redwood City, San Francisco Ba.
Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A. (1990) Feature-Oriented Domain
Analysis (FODA) Feasibility Study. Software Engineering Institute, Technical report,
CMU/SEI-90-TR-021.
Kotonya. G. and Sommerville, I. (1998) Requirements Engineering: Processes and
Techniques. John Wiley.
Lamsweerde, A. (2001) Goal-Oriented Requirements Engineering: A Guided Tour. In: 5th
IEEE International Symposium on Requirements Engineering (RE'01), Toronto, Canada.
Mussbacher, G., Amyot, D., Arajo, J., Moreira, A. (2008) Modeling software product lines
with AoURN. In: AOSD workshop on Early aspects. Brussels, Belgium. ACM..
Santos, L., Silva L., Batista, T. (2011) On the Integration of the Feature Model and PLAOVGraph, In: AOSD workshop on Early aspects. Porto de Galinhas, Brazil, ACM.
Silva, C., Alencar, F., Arajo, J., Moreira, A., Castro, J. (2008) Tailoring an Aspectual
Goal-Oriented Approach to Model Features. In: 20th Intl. Conf. on Software
Engineering and Knowledge Engineering (SEKE'08), San Francisco Bay, USA.
Silva, C., Borba, C., Castro, J. (2011) A Goal Oriented Approach to Identify and Configure
Feature Models for Software Product Lines. In: Workshop on Requirements Engineering
(WER), Rio de Janeiro, Brasil.

Você também pode gostar