3. Método de identificação de interesses transversais em modelos PL-AOVgraph
3.1. Processo de identificação
Este método de identificação é baseado na análise fan-out dos relacionamentos entre os elementos. A análise fan-out, da mesma forma que a análise fan-in, é uma métrica de avaliação do acoplamento entre dois elementos. De modo geral, a análise
fan-in indica o número de elementos de entrada, ou seja, o número de elementos para os
quais um determinado elemento aponta. Enquanto que a análise fan-out indica o número de elementos de saída, ou seja, o número de elementos apontados por um determinado elemento.
No caso deste trabalho, os acoplamentos são os relacionamentos de contribuição entre os elementos. O relacionamento de contribuição representa a relação hierárquica entre os elementos e sua direção é de filho para pai, ou seja, para alcançar o pai são necessários os filhos. Dessa forma, aplicando os conceitos de fan-in e fan-out a este caso, pode-se dizer que a análise fan-in indica o número de filhos que um elemento tem enquanto que a análise fan-out indica o número de pais que um elemento tem.
Para facilitar a análise desses acoplamentos, utilizamos de uma matriz de adjacência que apresenta os relacionamentos de contribuição entre os elementos do modelo: o cruzamento da linha com a coluna identifica se há relacionamento de contribuição entre os elementos analisados. A partir dos dados dessa matriz, pode-se identificar e contabilizar os relacionamentos de contribuição dos elementos do modelo.
Nesse contexto, o processo de identificação consiste de 3 (três) principais etapas, como ilustrado na Figura 9. Um modelo de requisitos PL-AOVgraph é a entrada deste processo. A partir dele, é criada uma matriz de adjacência com os relacionamentos de contribuição entre os elementos. Em seguida, os interesses transversais podem ser identificados pela contabilização dos relacionamentos de contribuição originados de cada elemento. Em seguida, os interesses transversais podem ser especificados, considerando os dados da matriz e os dados do modelo de entrada. Enfim, o modelo PL- AOVgraph é atualizado pela adição (ou atualização) dos relacionamentos transversais identificados. Este processo é detalhado e exemplificado a seguir.
Figura 9: Processo de identificação e especificação de relacionamentos transversais
A primeira etapa do processo, como ilustrado na Figura 9, é a criação de uma matriz de adjacência, na qual são considerados os relacionamentos entre elementos. Esta atividade tem como entrada um modelo de requisitos PL-AOVgraph e a partir dos relacionamentos de contribuição entre os elementos é gerada uma matriz de adjacência. Essa matriz de adjacência é utilizada para realizar a identificação e especificação dos interesses transversais através de algumas heurísticas descritas em seguida.
A fim de exemplificar esta atividade, a Figura 10 mostra uma pequena parte da especificação PL-AOVgraph do estudo de caso CMS que foi criada pela autora deste trabalho, a partir das informações contidas em (Kienzle; Guelfi; Mustafiz, 2009). Nesta figura, há 2 (duas) principais características, representadas pela meta “Crisis resolved” e pela softmeta “Security”, bem como os relacionamentos de contribuição entre outras (sub) tarefas. “Authenticate [User]” é uma tarefa que contribui para a softmeta “Security” e para as tarefas “Manage [External Resource]” e “Manage [Internal
Resource]”, tais relacionamento são representados pelas referências das tarefas
Figura 10: Exemplo de especificação PL-AOVgraph do CMS
Baseado neste modelo PL-AOVgraph, a matriz de adjacência é criada, conforme mostra a Tabela 1. O cabeçalho e a coluna identificadora desta tabela mostram os elementos PL-AOVgraph da especificação CMS. O cruzamento da linha com a coluna indica se há relacionamento de contribuição entre os elementos, este relacionamento é identificado pelo “x” nas células internas da Tabela 1. Desse modo, a leitura da tabela a partir da linha, isto é, a leitura horizontal indica a direção dos relacionamentos de contribuição, por exemplo, as tarefas “Select [Employee]”, “Receive confirmation of
acceptance mission” e “Inform [Mission info]” contribuem para a tarefa “Assign [Internal Resource]”.
Tabela 1: Exemplo de matriz de adjacência
Uma vez que os relacionamentos entre os elementos foram identificados e adicionados à matriz, pode-se começar a segunda etapa do processo que é constituída da análise da matriz de adjacência para identificar os interesses transversais.
Esta análise consiste em avaliar os fenômenos de espalhamento e de entrelaçamento. E este fenômeno é identificado quando um elemento afeta (ou é afetado por) diversos outros elementos. Portanto, quanto mais um elemento contribui para outros, mais espalhado e entrelaçado este elemento é. Dessa forma, a identificação dos interesses transversais pode ser obtida pela contagem desses relacionamentos. Usando uma matriz de adjacência, no exemplo ilustrado na Tabela 1, pode-se rapidamente visualizar que “Authenticate [User]” contribui para 3 (três) outros elementos enquanto que os outros contribuem para apenas um.
Entretanto, não há uma quantidade mínima e pré-definida de relacionamentos de contribuição para que um elemento deva ser considerado interesse transversal. Entendemos que esta quantidade depende do contexto e tamanho do sistema, e assim varia de um sistema para outro. Dessa forma, é necessário que o analista intervenha no processo, configurando esse valor. Assim, considerando o exemplo da Tabela 1, se o analista configurar esse número como sendo 2 (dois) ou 3 (três), então pode-se inferir que a tarefa “Authenticate [User]” é um interesse transversal, enquanto que se o analista configurar este número como sendo maior que 3 (três), ele não seria considerado um interesse transversal neste modelo.
Uma vez que os interesses transversais foram identificados, é necessário que eles sejam representados por relacionamentos transversais, que é a terceira e última etapa do processo. Assim sendo, para especificar o relacionamento transversal, é imprescindível
definir os elementos que compõem este tipo de relacionamento: source, pointcut, advice e intertype declaration.
É válido ressaltar que se existirem relacionamentos transversais definidos na especificação de entrada, então eles podem, se necessário, ser atualizados com outros
pointcuts, advice ou intertype declarations. O processo aqui proposto não gera dois ou
mais relacionamentos transversais com o mesmo source, uma vez que cada relacionamento deve modularizar um concern para diminuir o espalhamento e/ou entrelaçamento.
O source é a origem do relacionamento transversal, logo ele é especificado como sendo o primeiro elemento pai do relacionamento do interesse transversal. No exemplo acima, foi identificado como interesse transversal pela análise da matriz (Tabela 1) a tarefa “Authenticate [User]”, desse modo, para definir o source do relacionamento é necessário analisar a especificação (Figura 10) e então identificar o primeiro elemento pai. Analisando essa especificação, percebe-se que a softmeta “Security” é o primeiro elemento pai, consequentemente, é o source do relacionamento transversal.
O pointcut indica os elementos que são afetados pelo interesse transversal, assim, no exemplo acima, as tarefas “Manage [External Resource]” e “Manage
[Internal Resource]” compõem os elementos do pointcut. O advice e a intertype declaration indicam os elementos que afetam outros elementos. Entretanto, o advice
altera a estrutura dinâmica do sistema, adicionando, assim, comportamentos ao pointcut. E a intertype declaration altera a estrutura estática do sistema, adicionando novos tipos de dados (attribute) ou novos elementos (element) ao sistema, modificando, assim, a hierarquia do sistema. No exemplo, é identificado apenas advice, composto, portanto, da tarefa “Authenticate [User]”.
É válido destacar que desde que cada relacionamento transversal acomoda muitas contribuições, então essas contribuições são substituídas pelo relacionamento transversal. Esta redução e modularização dos relacionamentos ajudam na rastreabilidade e na consistência dos elementos, pois cada relacionamento envolve apenas um concern, assim sendo, além de facilitar a localização de mudanças, ele representa uma determinada característica importante.
Enfim, concluídas essas etapas, uma nova especificação de requisitos é criada com a remoção de algumas contribuições e com a adição de alguns relacionamentos transversais. A Figura 11 mostra o relacionamento criado para representar que “Authenticate [User]” é um interesse transversal e ele contribui para as tarefas “Manage
Figura 11: Exemplo de relacionamento transversal
Nesse contexto, pode-se destacar como principais características deste método: analisar modelos de requisitos escritos em PL-AOVgraph, apoiando-se nos relacionamentos entre os requisitos; identificar interesses transversais tanto em requisitos funcionais quanto em requisitos não funcionais através da contabilização dos relacionamentos de contribuição entre os requisitos (fan-out); e, especificar os relacionamentos transversais a partir das informações contidas no modelo PL- AOVgraph e das informações apresentadas na matriz de adjacência. E ainda, vale ressaltar que o processo de identificação é composto por 3 (três) etapas, como evidenciado na Figura 9 .