Regras Complementares

As Tabelas 4 e 5 apresentam as regras de mapeamento de PL-AOVgraph para Modelo de Features e de Modelo de Features para PL-AOVgraph, respectivamente, que permitem solucionar as restrições 1 e 2, descritas na seção 3.2.3. As regras foram enumeradas dando continuidade à numeração das regras apresentadas nas Tabelas 2 e 3, respectivamente.

Regra Descrição

10 O tipo de cada elemento PL-AOVgraph é indicado no conteúdo de uma anotação, que é adicionada a cada feature.

11

Intertype declarations do tipo element se tornam features, que são adicionadas à feature correspondente ao source do relacionamento transversal. Estas features ainda possuem uma anotação indicando que esta foi originada a partir de um intertype declaration do tipo element, seguido do tipo do elemento PL-AOVgraph (task, goal, softgoal), por exemplo: Intertype Declaration (element: task).

12

Intertype declarations do tipo attribute se tornam features, que são adicionadas à feature correspondente ao source do relacionamento transversal. Estas features não possuem cardinalidade nem a anotação que indica o tipo do elemento PL-AOVgraph. O valor do intertype declaration attribute será o nome da feature e o atributo será indicado no conteúdo de uma anotação com o seguinte formato: Intertype Declaration (attribute: Nome_do_Atributo).

13 Se um pointcut possui um operando com a primitiva substitute, a feature correspondente ao operando recebe uma anotação indicando a primitiva e as features que poderão a substituir.

14

Advices before ou after são mapeados para features de referência, conforme a quantidade de operandos include do pointcut afetado pelo advice, ou para anotações, conforme a quantidade de operandos substitute do pointcut afetado pelo advice. No primeiro caso, as features de referência são adicionadas as features pais das correspondentes aos operandos include e possuem uma anotação indicando o tipo do advice, ex: advice: after. No segundo caso, as anotações, que indicam as features que podem substituir e o tipo do advice, são adicionadas as features pais das correspondentes aos operandos substitute.

Tabela 4. Regras complementares para o mapeamento de PL-AOVgraph para Modelo de Features

Regra Descrição

9 Se uma feature possuir anotação e no conteúdo da anotação houver o tipo do elemento PL-AOVgraph (task, goal, softgoal), será gerado um elemento conforme o especificado na anotação.

10 Se uma feature possui uma anotação que contém as palavras “Intertype Declaration” e “element”, será mapeada para um intertype declaration do tipo element.

11

Se uma feature possui uma anotação que contém as palavras “Intertype Declaration” e “attribute”, será mapeada para um intertype declaration do tipo attribute, cujo valor corresponde ao nome da feature e o atributo consta no conteúdo da anotação.

12 Se uma feature possuir uma anotação que contenha a palavra “substitute” será mapeada para um operando com primitiva substitute.

13

Se uma feature de referência possuir uma anotação que contenha a palavra “advice” seguida por “before” ou “after”, esta será mapeada para um advice conforme o tipo indicado na anotação e os pointcuts serão seus irmãos. Se uma feature possui uma anotação que contenha as palavras “substitute” e “advice” seguida por “before” ou “after”, a feature declarada na anotação será mapeada para um advice conforme o tipo indicado na anotação e os pointcuts serão seus filhos.

14 Se for identificado um pointcut que possua mais de um operando e que é afetado por um advice before ou after, será utilizado o operador or entre seus operandos.

As regras 9 (Tabela 4) e 10 (Tabela 5) foram apresentadas em Santos (2011b) com o objetivo de eliminar a restrição 1 do mapeamento proposto por Santos (2010).

Na Figura 20 podemos observar um trecho da especificação PL-AOVgraph de Smart Home, que é transformado em um Modelo de Features, que por sua vez é transformado novamente em PL-AOVgraph. Comparando as especificações podemos ver que ambas são idênticas. Isso só é possível porque cada feature recebeu uma anotação indicando se corresponde a uma task, goal ou softgoal. Assim, ao realizar o mapeamento de Modelo de Features para PL-AOvgraph a anotação é verificada, gerando um elemento conforme o tipo indicado na anotação, em vez de gerar apenas tasks por default.

Figura 20. Mapeamento entre tipos de elementos PL-AOVgraph e anotações no Modelo de Features As demais regras das Tabelas 4 e 5 propõem-se a solucionar a restrição 2 do mapeamento apresentado por Santos (2010).

A Figura 21 demonstra a utilização das regras 11 (Tabela 4) e 10 (Tabela 5). Vale salientar que tanto a especificação PL-AOVgraph quanto o Modelo de Features apresentados nesta figura, contém apenas os elementos necessários para a exemplificação das regras, sendo, portanto, uma versão parcial do original. Um dos elementos omitidos no Modelo de Features foram as anotações referentes ao tipo do elemento PL-AOVgraph, deixando apenas as que realmente eram relevantes para a demonstração.

Na parte superior desta figura encontramos a descrição PL-AOVgraph de um relacionamento transversal que possui um intertype declaration do tipo element (linhas 5 a 7). Transformando este relacionamento em Modelo de Features, conforme a regra 11 da Tabela 4, vemos que o intertype declaration element, que neste caso é “Reposition Authentication Device” (linha 6), se torna uma feature que possui uma anotação no seguinte formato: Intertype Declaration (element: tipo_do_elemento_PLAOVgraph). Uma vez que “Reposition

Authentication Device” é uma task, a anotação neste caso é: Intertype Declaration (element: task). A feature “Reposition Authentication Device” é adicionada a feature correspondente ao source do relacionamento (linha 2), que neste caso é “Accessibility”. Ela também é chamada como referência por cada operando include do pointcut PC1 (linhas 3 e 4).

Figura 21. Mapeamento entre Intertype Declarations Element e Features

Na transformação inversa, de acordo com a regra 10 da Tabela 5, observamos que a feature “Reposition Authentication Device” possui uma anotação que indica que a mesma corresponde a um intertype declaration do tipo element. Assim, em PL-AOVgraph é gerado o intertype declaration element que inclui a task “Reposition Authentication Device” com contribuição and (linha 6). O tipo do elemento foi identificado a partir da anotação, que contém a palavra “task”, e a contribuição a partir do relacionamento mandatório. Uma vez que “Reposition Authentication Device” é referenciada quatro vezes no Modelo de Features, os elementos PL-AOVgraph correspondentes as features que fazem estas referências se tornam operandos include. O source do relacionamento transversal é o elemento correspondente a feature pai de “Reposition Authentication Device”, que neste caso é a softgoal “Accessibility”.

A Figura 22 demonstra a utilização das regras 12 e 13 da Tabela 4 e 11 e 12 da Tabela 5. Nesta figura também foram omitidas algumas anotações referentes aos tipos de elementos PL-AOVgraph. Na parte superior da figura temos um relacionamento transversal em PL-

AOVgraph que inclui um operando com a primitiva substitute (linha 3) e um intertype declaration do tipo attribute (linhas 4 a 6). Todo intertype declaration do tipo attribute é formado por duas partes: atributo e valor. No caso do intertype declaration descrito na linha 5, o atributo corresponde a “Keypad Type” e o valor a “Embossed keys”.

Ao transformar este relacionamento transversal em Modelo de Features, podemos ver que o intertype declaration attribute “Keypad Type = Embossed keys” (linha 5) se torna uma feature, conforme a regra 12 da Tabela 4, de forma que o campo valor (Embossed keys) é mapeado para o nome da feature e o campo atributo é registrado em uma anotação no seguinte formato: Intertype Declaration (attribute: Nome_do_Atributo). Quanto à questão da primitiva substitute, obedecendo à regra 13 da Tabela 4, a feature correspondente ao operando substitute “Keypad” recebe uma anotação no seguinte formato: substitute: Nome_das_Features_que_podem_substituir. Como o intertype declaration attribute é quem afeta o pointcut PC1, a feature que pode substituir “Keypad” é “Embossed keys”.

Figura 22. Mapeamento envolvendo Intertype Declarations Attribute, Operandos Substitute e Features Na transformação inversa, segundo a regra 11 da Tabela 5, observamos que a feature “Embossed keys” possui uma anotação que indica que a mesma corresponde a um intertype declaration do tipo attribute. Assim, em PL-AOVgraph é gerado o intertype declaration attribute, de forma que o campo atributo é obtido a partir do conteúdo da anotação e o campo valor é extraído do nome da feature. Uma vez que a feature “Keypad” possui uma anotação

substitute que inclui a feature “Embossed keys” o elemento PL-AOVgraph correspondente a esta feature se torna um operando substitute, de acordo com a regra 12 da Tabela 5. O source do relacionamento transversal é o elemento correspondente a feature pai de “Embossed keys”, que neste caso é a softgoal “Accessibility”.

A Figura 23 demonstra a utilização das regras 14 (Tabela 4), 13 e 14 (Tabela 5). Nesta figura também foram omitidas algumas anotações referentes aos tipos de elementos PL- AOVgraph. Na parte superior da figura temos um relacionamento transversal em PL- AOVgraph que inclui um pointcut que possui dois operandos interligados pelo operador or (linha 3) e um advice before (linha 4 a 6). Transformando este relacionamento em Modelo de Features, conforme a regra 14 da Tabela 4, vemos que o advice before “Close Window” (linha 5), se torna uma feature que é adicionada à feature correspondente ao source do relacionamento (linha 2), “Windows Management”. Uma vez que o advice é do tipo before, a feature “Close Window” deve ser chamada como referência pelo pai das features correspondentes a cada operando include do pointcut PC1 (linha 3), que neste caso é “Regulate Thermostat”. Esta feature de referência deve conter uma anotação no seguinte formato: advice: before.

Figura 23. Mapeamento envolvendo Advices Before ou After e Features de Referência

Na transformação inversa, de acordo com a regra 13 da Tabela 5, observamos que a feature de referência “Close Window” possui uma anotação que indica que a mesma corresponde a um advice do tipo before. Assim, em PL-AOVgraph é gerado o advice before que inclui a task_ref “Close Window” com contribuição and (linha 5). O tipo do elemento foi identificado a partir da anotação “task_ref”, e a contribuição a partir do relacionamento

mandatório. Uma vez que “Close Window” representa um advice before, os elementos PL- AOVgraph correspondentes aos filhos da feature que referencia “Close Window” (Regulate Thermostat) se tornam operandos include, neste caso “Heat” e “Refrigerate”. Segundo a regra 14 da Tabela 5, o operador utilizado entre os operandos neste caso é or, pois se trata de um pointcut afetado por um advice before. O source do relacionamento transversal é o elemento correspondente a feature pai de “Close Window”, neste caso a task “Windows Management”.

Vale salientar que para que as transformações aconteçam de forma correta é imprescindível que as anotações no Modelo de Features obedeçam às sintaxes definidas nas regras.

Quanto às restrições 3 e 4, descritas na seção 3.2.3, uma possível solução seria adotar à abordagem utilizada no Framework para Identificação de Similaridades e Variabilidades em Documentos de Requisitos (Alférez et al, 2008). Este framework faz parte de um de nossos trabalhos relacionados e é apresentado na seção 7.1. A abordagem se baseia na hipótese de que features são grupos coesos de requisitos. Dessa forma, os requisitos semanticamente similares são agrupados formando uma feature, com isso o número de features é reduzido, solucionando o problema apresentado na restrição 3. Além disso, este framework também possui uma etapa de nomeação, onde cada feature é nomeada com base nos requisitos que ela se propõe a satisfazer, embora em (Alférez et al, 2008) esta etapa não tenha sido totalmente implementada. De fato, se agruparmos requisitos para formar uma feature, é possível usar os mesmos critérios utilizados no agrupamento para atribuir um nome ao grupo. Dessa forma, as features teriam nomes mais adequados, o que solucionaria a restrição 4.