Selv om målet er lovlig er det ikke sikkert det er lov å angripe det

Theme Abordagem Theme _{Clarke e Baniassad, 2005; Baniassad e Clarke, 2004} 2.2.2

EA-Miner Abordagem EA-Miner _{Chitchyan et al., 2006; Sampaio et al., 2005} 2.2.3 EROA/XML Uma Abordagem baseada em XML para Especificação e Composição de Interesses Aspectuais

Soeiro et al., 2006

2.2.4 EROA/Arcade Engenharia de Requisitos Orientada a Aspectos com Arcade _{Rashid et al., 2003; Rashid et al., 2002} 2.2.5

2.2.1 Separação Multidimensional de Interesses na Engenharia de

Requisitos (MDSoC - Multi-Dimensional Separation of Concerns

in Requirements Engineering)

Esta abordagem propõe que interesses devem ser decompostos de forma uniforme com relação a sua natureza funcional, não funcional ou transversal (Moreira et

al., 2005). Tratando todos os interesses da mesma forma, pode-se então escolher

qualquer conjunto de interesses como base para analisar a influência dos outros interesses sobre essa base.

Identificação, Classificação e Representação de Interesses. Esta atividade

leva em consideração que certos interesses, como por exemplo, “Mobilidade”, “Recuperação de Informação”, “Persistência”, entre outros aparecem frequentemente durante o desenvolvimento de software. Assim, os autores dividiram o espaço de interesses em dois: (i) o dos metainteresses, que consiste em um conjunto abstrato de interesses típicos de serem encontrados, como os que foram mencionados acima; e (ii) o dos interesses do sistema, que contempla os interesses específicos do software sob análise.

Para se utilizar esta abordagem, os requisitos do software devem ser analisados pelo engenheiro de software e categorizados com base nos interesses existentes no espaço de metainteresses, gerando assim os interesses do sistema. Para representação dos interesses, tanto os metainteresses quanto os do sistema, arquivos XML são utilizados.

Na Listagem 2.1 – (A) encontra-se a definição do metainteresse “Mobilidade (Mobility)_{”. Essa definição inclui uma breve descrição do interesse, alguns exemplos de} uso do mesmo, derivados de experiências prévias de utilização desse interesse, e os metainteresses que podem relacionar-se com ele.

<?xml version="1.0" ?>

<MetaConcern name="Mobility">

<Description>The quality of moving freely </Description> <Examples>Wireless networks, Mobile phones</Examples>

<Relationships> Availability, Portability, Context </Relationships> </MetaConcern>

(A)

<?xml version="1.0" ?> <Concern name="Mobility">

<Requirement id="1">The system will be accessed on the move.</Requirement> </Concern>

(B)

Listagem 2.1. Interesse “Mobilidade (Mobility)” representado no espaço dos

metainteresses (A) e no espaço dos interesses do sistema (B) (adaptado de Moreira et al., 2005).

A Listagem 2.1 _{– (B) ilustra a especificação do interesse “Mobilidade (Mobility)”,} com base no documento de requisitos de um software de guia turístico sensível ao contexto apresentado por Moreira et al. (2005). Neste caso, o engenheiro de software deve especificar os requisitos do software relacionados ao interesse em questão.

Composição de Interesses. Após a identificação e representação dos interesses do software, regras de composição são definidas para se especificar como um determinado interesse influencia outros requisitos ou interesses do software. As regras de composição também são especificadas por meio de arquivos XML. Na Listagem 2.2 é apresentado um exemplo de regra de composição na qual o interesse “Mobilidade (Mobility)” afeta todos os requisitos do interesse “Recuperação de Informação (Information Retrieval)” e o requisito de identificador “1” do interesse “Navegação (Navigation)”.

<?xml version="1.0" ?> <Composition>

<Requirement concern="Mobility" id="all"> <Constraint action="affect" operator="on"> ...

<Requirement concern="Navigation" id="1" />

<Requirement concern="InformationRetrieval" id="all" /> </Constraint>

...

</Requirement> </Composition>

Listagem 2.2. Regra de composição para o interesse _{“Mobilidade (Mobility)”}

Detecção e Análise de Conflitos. Esta atividade é realizada a partir da

observação das interações de um interesse com os outros interesses do software. Para se identificar os conflitos existentes entre dois interesses C1 e C2 de um software, deve-

se analisar a Interseção de Composição SC1∩ SC2.

SC1 ∩ SC2 corresponde ao conjunto de interesses cujos requisitos estão

entrelaçados com C1 e C2, simultaneamente. Por exemplo, na Listagem 2.2, nota-se que

o interesse “Mobilidade (Mobility)” afeta o requisito “1” do interesse “Navegação (Navigation)”. Supondo que o interesse “Recuperação de Informação (Information

Retrieval)_{” também afete esse requisito, então a interseção de composição SC}Recuperação de Informação∩ SCMobilidade consiste no conjunto {“Navegação”}.

A análise dos conflitos ocorre com base no tipo de contribuição que um interesse pode exercer sobre outro. Essas contribuições podem ser negativas (-), positivas (+) ou neutras. Uma matriz de contribuição é construída, de forma que cada célula apresenta o tipo da contribuição (+ ou -) dos interesses em questão com relação aos interesses do conjunto de interseções de composição localizado dentro da célula. Uma célula vazia denota a não existência de relacionamento entre os interesses.

Com relação à análise de conflitos _{entre os interesses de “Recuperação de} Informação (Information Retrieval)” e “Mobilidade (Mobility)”, tem-se o seguinte: “quanto mais o visitante se movimenta, maiores serão as dificuldades dele em recuperar informações no software”. Isso significa que “Mobilidade (Mobility)” contribui negativamente para “Recuperação de Informação (Information Retrieval)” com relação à “Navegação (Navigation)”. A contribuição na direção oposta também é negativa, uma vez que quanto mais complexa é a informação que precisa ser recuperada, menos móvel o software poderá ser, uma vez que algumas redes sem fio possuem tamanho de banda limitado. A Figura 2.1 ilustra a matriz de contribuição obtida a partir da análise do cenário anterior.

Recuperação de

Informação Mobilidade

Recuperação de Informação _{{Navegação}} _

Mobilidade _{{Navegação}} _

Figura 2.1. Exemplo de uma matriz de contribuição entre os interesses “Mobilidade” e “Recuperação de Informação” (adaptado de Moreira et al., 2005).

Como o efeito cumulativo da “Mobilidade” e “Recuperação de Informação” sobre “Navegação” é negativo, então há necessidade de se realizar uma análise, com o intuito de resolver o conflito existente. Os autores desta abordagem propõem a atribuição de pesos aos interesses que contribuem negativamente para outros interesses. Cada peso é um número real no intervalo [0..1] e representa a prioridade de um interesse com

relação aos outros. Esses valores são dados pelo engenheiro de software, de acordo com a importância de cada interesse em relação aos demais.

Pontos fortes e fracos. Como pontos fortes da abordagem MDSoC, tem-se

que: (i) trata-se de uma abordagem para EROA que lida com interesses funcionais e não funcionais sob uma mesma perspectiva, o que pode favorecer a identificação de ITs relacionados a requisitos funcionais do software; (ii) propõe um arquivo XML (template) para documentação de interesses, destacando suas propriedades e relacionamentos com outros interesses; e (ii) lida com todas as principais atividades para EROA, apresentadas no Capítulo 1 desta tese.

Como limitações ou pontos fracos, tem-se que: (i) a criação e aplicação das regras de composição propostas parecem ser onerosas e propensas a erros; (ii) não há diretrizes que auxiliem os engenheiros de software durante a realização das atividades da abordagens, tornando o resultado dessas atividades fortemente dependente da experiência desses profissionais; e (iii) o template proposto pelos autores não deixa claro quais são os tipos de relacionamentos existentes entre diferentes interesses do software, como por exemplo, dependência, composição, contribuição, entre outros.