UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
Dissertação de Mestrado
Identificando Interesses Transversais em Modelos de
Requisitos PL-AOVgraph
Maíra de Faria Barros Medeiros
MAÍRA DE FARIA BARROS MEDEIROS
Identificando Interesses Transversais em Modelos de
Requisitos PL-AOVgraph
Dissertação de Mestrado submetida ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para obtenção do título de Mestre em Sistemas e Computação.
Profª. Drª. Lyrene Fernandes da Silva Orientadora
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET.
Medeiros, Maíra de Faria Barros.
Identificando interesses transversais em modelos de requisitos PL-AOVgraph / Maíra de Faria Barros Medeiros. - Natal, 2013.
91 f.: il.
Orientadora: Profa. Dra. Lyrene Fernandes da Silva.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Engenharia de software – Dissertação. 2. Engenharia de requisitos –
Dissertação. 3. Identificação de interesses transversais – Dissertação. 4. Interesses transversais – Dissertação. 5. PL-AOVgraph - Dissertação. I. Silva, Lyrene Fernandes da. II. Título.
MAÍRA DE FARIA BARROS MEDEIROS
Identificando Interesses Transversais em Modelos de
Requisitos PL-AOVgraph
Esta Dissertação de Mestrado foi julgada adequada para a obtenção do título de mestre em Sistemas e Computação e aprovado em sua forma final pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte.
_______________________________________________________________ Prof.ª Dr.ª Lyrene Fernandes da Silva - UFRN
Orientadora
_______________________________________________________________ Prof. Dr. David Boris Paul Déharbe - UFRN
Coordenador do Programa
Banca Examinadora
_______________________________________________________________ Presidente: Prof.ª Dr.ª Lyrene Fernandes da Silva
_______________________________________________________________ Examinador: Prof.ª Dr.ª Márcia Jacyntha Nunes Rodrigues Lucena
_______________________________________________________________ Examinador: Prof. Dr. Julio Cesar Sampaio do Prado Leite
Agradecimentos
Primeiramente, agradeço a Deus por ter me dado forças e iluminando meu caminho para eu chegar até aqui. Por me capacitar e me conduzir em toda minha trajetória.
À minha orientadora Lyrene pelas oportunidades, ensinamentos, disponibilidade e dedicação dispensados no auxilio à concretização desse trabalho.
Aos meus pais, Flávia e Júnior, que sempre me apoiaram em todos os momentos. Reconheço que sem as palavras de confiança e de incentivo de vocês eu não teria chegado até aqui. Ao meu irmão, Lucas, por estar ao meu lado todos os dias.
Aos meus avós, tios e primos pelo carinho, apoio e incentivo. Às minhas madrinhas, mães, avós de coração, Tetê e Nega, por estar sempre torcendo e rezando para que meus objetivos sejam alcançados.
Aos meus amigos pelo carinho, paciência e disponibilidade.
A todos os meus colegas e amigos de mestrado, em especial a Larissa, Ana Luisa, Lidiane e Daniel pela amizade, incentivo e contribuições.
À instituição UFRN e seus professores pelo ensino, aprendizado e amadurecimento quanto pessoa e profissional.
Ao CNPQ pelo apoio financeiro despendido a este trabalho.
Resumo
A ocorrência de problemas relacionados aos fenômenos de espalhamento e entrelaçamento, tal como a dificuldade de manutenção do sistema, é cada vez mais frequente. Uma tentativa de resolver este problema está relacionada à identificação de interesses transversais. Para maximizar seus benefícios, a identificação deve ser realizada desde as etapas iniciais do processo de desenvolvimento, porém alguns trabalhos relatam que isto não tem sido feito na maioria dos casos, tornando o desenvolvimento do sistema suscetível à ocorrência de erros e propensos à refatorações em fases posteriores. Esta situação afeta diretamente à qualidade e o custo do sistema. PL-AOVgraph é uma linguagem de modelagem de requisitos orientada a metas que oferece suporte para representação dos relacionamentos entre requisitos e provê separação de interesses transversais através da representação de relacionamentos transversais. Diante disso, esse trabalho apresenta um método semi-automático para identificação de interesses transversais em especificações de requisitos escritas em PL-AOVgraph. Uma matriz de adjacência é utilizada para a identificação dos relacionamentos de contribuição entre os elementos. A identificação de interesses transversais é baseada na análise fan-out dos relacionamentos de contribuição a partir
das informações da matriz de adjacência. Quando identificados, os relacionamentos transversais são criados. Esse método está implementado como um novo módulo da ferramenta ReqSys-MDD.
Abstract
The occurrence of problems related to the scattering and tangling phenomenon, such as the difficulty to do system maintenance, increasingly frequent. One way to solve this problem is related to the crosscutting concerns identification. To maximize its benefits, the identification must be performed from early stages of development process, but some works have reported that this has not been done in most of cases, making the system development susceptible to the errors incidence and prone to the refactoring later. This situation affects directly to the quality and cost of the system. PL-AOVgraph is a goal-oriented requirements modeling language which offers support to the relationships representation among requirements and provides separation of crosscutting concerns by crosscutting relationships representation. Therefore, this work presents a semi-automatic method to crosscutting concern identification in requirements specifications written in PL-AOVgraph. An adjacency matrix is used to identify the contributions relationships among the elements. The crosscutting concern identification is based in fan-out analysis of contribution relationships from the informations of adjacency matrix. When identified, the crosscutting relationships are created. And also, this method is implemented as a new module of ReqSys-MDD tool.
Sumário
1. Introdução ... 12
1.1. Motivação ... 13
1.2. Objetivos ... 14
1.3. Estrutura do Trabalho ... 15
2. Fundamentação Teórica ... 16
2.1. Interesse Transversal ... 16
2.2. PL-AOVgraph ... 17
2.3. Identificação de Interesses transversais ... 21
2.3.1. Abordagens que processam documentos de requisitos textuais ... 23
2.3.1.1. Theme/Doc ... 23
2.3.1.2. DISCERN ... 24
2.3.1.3. Early-AIM ... 25
2.3.1.4. CCCINPL(Crosscutting Concern Identification using NLP) ... 26
2.3.2. Abordagens que processam modelos específicos ... 28
2.3.2.1. Identificação de interesses transversais em modelos UML ... 28
2.3.2.2. Identificando interesses transversais em modelos i* ... 30
2.3.2.3. Identificando interesses transversais em modelos V-graph ... 31
3. Método de identificação de interesses transversais em modelos PL-AOVgraph ... 33
3.1. Processo de identificação ... 33
3.2. Implementação do método de identificação na ferramenta ReqSys-MDD ... 38
3.2.1 Arquitetura de ReqSys-MDD ... 38
3.2.2. Algoritmo de identificação ... 41
3.2.3. Projeto detalhado ... 44
4. Estudo de Caso ... 48
4.1. Objetivo ... 48
4.2. Questões de pesquisa ... 48
4.3. Etapas do estudo de caso ... 49
4.3.1. 1ª etapa: Identificação e especificação manual ... 50
4.3.2. 2ª etapa: Identificação e especificação usando ReqSys-MDD ... 50
4.3.3. 3ª etapa: Comparação ... 51
4.4. Análise dos dados ... 57
5. Trabalhos Relacionados ... 61
6. Conclusão ... 64
6.1. Contribuições ... 64
6.2. Trabalhos Futuros ... 65
Referências ... 66
Anexo A – Especificação ESP1... 68
Anexo B – Especificação ESP2 ... 74
Apêndice A – Classe IdentificaCT.java ... 80
Lista de Figuras
Figura 1: Elementos e relacionamentos de PL-AOVgraph (representação gráfica) ... 17
Figura 2: Relacionamentos de contribuição em PL-AOVgraph no modo gráfico ... 19
Figura 3: Relacionamentos de contribuição em PL-AOVgraph no modo textual ... 20
Figura 4: Relacionamento transversal no modo textual de PL-AOVgraph ... 20
Figura 5: Visão geral do método DISCERN ... 24
Figura 6: Método Early-AIM ... 25
Figura 7: Processo da abordagem ... 29
Figura 8: Processo de identificação de interesses transversais em modelos V-graph .... 32
Figura 9: Processo de identificação e especificação de relacionamentos transversais ... 34
Figura 10: Exemplo de especificação PL-AOVgraph do CMS ... 35
Figura 11: Exemplo de relacionamento transversal ... 38
Figura 12: Arquitetura de ReqSys-MDD... 39
Figura 13: Fluxo da identificação de interesses transversais em ReqSys-MDD ... 40
Figura 14: Interface da ferramenta ReqSys-MDD ... 41
Figura 15: Diagrama de atividades da identificação e especificação de relacionamentos transversais ... 42
Figura 16: Pacote “identificacao” de ReqSys-MDD ... 45
Figura 17: Pacote “reqsysmdd” de ReqSys-MDD ... 46
Figura 18: Fragmento do arquivo “plugin.xml” de ReqSys-MDD ... 47
Figura 19: Relacionamento Transversal originado 1 (a) Manual (ESP1); (b) ReqSys-MDD (ESP3) ... 53
Figura 20: Relacionamento Transversal 2 (a) Manual (ESP1); (b) ReqSys-MDD (ESP3) ... 54
Figura 21: Relacionamento transversal 3 (a) Manual (ESP1); (b) ReqSys-MDD (ESP3) ... 55
Figura 22: Relacionamento transversal 4 (a) Manual (ESP1); (b) ReqSys-MDD (ESP3) ... 56
Lista de Tabelas
Tabela 1: Exemplo de matriz de adjacência ... 36
Tabela 2: Resumo da especificação do relacionamento transversal ... 44
Tabela 3: Quantidade de elementos levantados pelo estudo de caso ... 51
Tabela 4: Interesses Transversais Identificados pelo estudo de caso ... 52
1. Introdução
Embora a engenharia de software tenha obtido notáveis avanços, ainda se busca soluções para o aprimoramento dos sistemas de software produzidos, bem como a redução dos custos de produção. O desenvolvimento de software, de forma geral, não é uma tarefa trivial, pois é preciso lidar com alterações nos requisitos e nas tecnologias utilizadas, fatores que influenciam tanto a qualidade quanto o custo do produto (Sommerville, 2007). Uma das formas, apontadas na literatura, de reagir rapidamente a mudanças, buscando o aumento da qualidade, produtividade e diminuição dos custos do software é a prática do reuso (Atkinson et al, 2002).
Assim, novos paradigmas surgem como candidatos à solução dos problemas em questão utilizando-se de modularização para a prática do reuso, dentre os quais destaca-se o Dedestaca-senvolvimento de Software Orientado a Aspectos (DSOA) (Filman et al, 2005).
A modularização permite o reuso de todas as formas de experiências, incluindo produtos, processos e documentação. Foi baseado neste cenário de reaproveitamento que surgiu a ideia de Linha de Produto de Software (LPS). A LPS permite a reutilização não só de código, mas de outros artefatos, tais como requisitos e arquitetura, baseados em linhas de produção industriais (Berg et al, 2005).
O DSOA surgiu como uma alternativa para a modularização de sistemas, apoiado na separação de concerns. Adicionalmente, separação de concerns designa que
cada módulo do software deve tratar apenas de um assunto. Pode-se, então, enfocar esse módulo sem considerar outros módulos do sistema. Desse modo, pode-se compreender cada parte do sistema pelo conhecimento do seu assunto, sem necessitar entender outros módulos. Assim, quando é necessário realizar mudanças, elas estão localizadas em uma pequena parte do sistema (Sommerville, 2007).
A modularização no DSOA é obtida com o encapsulamento dos interesses transversais através de abstrações específicas, por exemplo, os aspectos. De forma geral, interesses transversais são partes do sistema que estão fortemente relacionadas, entrelaçadas ou sobrepostas, influenciando ou restringindo umas às outras, tornando o sistema complexo e difícil de analisar (Silva, 2006).
sistemas. Esse estudo nas fases iniciais do processo de desenvolvimento é chamado de
Early-Aspects.
Nesse cenário, a engenharia de requisitos orientada a aspectos propõe métodos e técnicas para identificar, separar e compor interesses transversais de sistemas de software a partir de seus artefatos de requisitos. A identificação dos interesses transversais no inicio do ciclo de vida do software é uma atividade essencial, pois proporciona alguns benefícios, entre eles a melhoria na rastreabilidade, na manutenção e na evolução dos requisitos, na modularização, na qualidade e nos custos do sistema (Rosenhainer, 2004).
No contexto de engenharia de requisitos orientada a aspectos existem diversas abordagens de identificação, modelagem e análise. Dentre elas, PL-AOVgraph (Product Line - Aspect Oriented Vgraph) é uma linguagem de modelagem de requisitos orientada a metas que dá suporte a descrição de informações de variabilidade e transversais. Alguns trabalhos relacionados à PL-AOVgraph, como Santos (2010) e Santos (2012), propõem a automatização do mapeamento bidirecional entre PL-AOVgraph e modelo de features. Entretanto, embora existam heurísticas gerais para se identificar interesses
transversais em modelos AOVgraph (Silva, 2006), que podem ser aplicadas também à PL-AOVgraph, não há trabalhos que proponham técnicas e ferramentas para realizar essa identificação de maneira automática ou semi-automática, sendo então esse o foco do trabalho aqui proposto.
1.1.
Motivação
Rosenhainer (2004) afirma que a identificação de interesses transversais ainda tem sido negligenciada em grande parte dos projetos de software, apesar de todas as vantagens proporcionadas pela execução dessa atividade nas fases iniciais do desenvolvimento. E ainda, supõe que isto pode ser motivado devido essa atividade ser uma atividade tediosa, já que envolve a análise minuciosa de documentos longos.
No caso de modelos PL-AOVgraph, a identificação de interesses transversais é realizada de forma ad hoc, baseada em algumas heurísticas gerais, tais como quantidade
de relacionamentos de entrada (fan-in), e/ou a possibilidade de reuso de um
determinado concern (Silva, 2006). Ficando a cargo do analista a decisão subjetiva de
modelar alguns requisitos como transversais ou não. E mais, mesmo decidindo modelar um determinado concern como transversal, o analista pode fazer isso de forma
incompleta, não modularizando tal concern da forma mais apropriada.
transversais identificados, restando para o analista realizar pequenos ajustes, isto é, identificar outros interesses transversais que a ferramenta não foi capaz de identificar. Dessa forma, almeja-se permitir que as atividades de identificar e escrever os relacionamentos transversais sejam realizados com menos dificuldade.
A ferramenta ReqSys-MDD (Santos, 2012) que valida especificações de requisitos e realiza transformações automáticas bidirecionais entre modelo PL-AOVgraph e modelo de features é um plug-in do Eclipse e foi estendida para dar apoio
ao método proposto neste trabalho. Dessa forma, reusamos algumas funcionalidades da ReqSys-MDD, tais como o editor de especificações e as transformações de modelo para texto e de texto para modelo (xText e Acceleo, respectivamente), permitindo ainda que os trabalhos que envolvem PL-AOVgraph estejam integrados, tornando a ferramenta mais rica.
E ainda, como proposta deste método é identificar interesses transversais em modelos de requisitos PL-AOVgraph, é possível, em trabalhos futuros, adicioná-lo à ferramenta do projeto MaRiPLA (Mapping Requirements to Product Line Architecture)
(Coelho, 2011), que realiza a transformação automática de modelos, de uma especificação PL-AOVgraph para uma especificação PL-AspectualACME, e evoluí-la até que as transformações cheguem ao código, mantendo a consistência entre todos os modelos envolvidos. Dessa forma, as fases iniciais do processo de desenvolvimento seriam automatizadas.
1.2. Objetivos
Este trabalho tem como objetivo principal definir um método semi-automático para a identificação de interesses transversais em descrições de requisitos em PL-AOVgraph. Esse método foi inserido na ferramenta ReqSys-MDD. A razão para isso é o reuso de algumas funcionalidades dessa ferramenta, tais como, a validação do documento de entrada e das transformações de modelo para texto e de texto para modelo. Para a implementação do método proposto por este trabalho foi utilizado o ambiente de desenvolvimento Eclipse juntamente com a linguagem Java.
Os objetivos específicos deste trabalho são:
Definição de heurísticas de identificação de interesses transversais usadas no método proposto;
1.3. Estrutura do Trabalho
Este trabalho é composto por 6 (seis) Capítulos e está estruturado da seguinte forma: o Capítulo 2 apresenta os conceitos intrínsecos à interesse transversal, PL-AOVgraph e identificação de interesses transversais, bem como as abordagem de identificação existentes que serviram de fonte de inspiração para definição do método aqui proposto; o Capítulo 3 apresenta nossa proposta de método para identificação de interesses transversais em especificações PL-AOVgraph, bem como os detalhes de sua implementação; o Capítulo 4 apresenta o estudo de caso realizado com o sistema Crisis Management System (CMS); o Capítulo 5 apresenta uma comparação entre o método
2. Fundamentação Teórica
Este Capítulo apresenta os principais conceitos envolvidos neste trabalho: a Seção 2.1 introduz o conceito de interesse transversal; a Seção 2.2 apresenta o modelo de metas PL-AOVgraph, uma linguagem de modelagem de requisitos orientada a aspectos; e, a Seção 2.3 resume os trabalhos de identificação de interesses transversais em documentos de requisitos, usados como referência para elaboração do método aqui proposto.
2.1. Interesse Transversal
Embora, separação de concerns seja um princípio bem definido na Engenharia
de Software desde a década de 1970 (Sutton Jr; Rouvellou, 2002), o conceito de
concern é diferente para alguns autores. Este princípio está relacionado à decomposição
e modularização, isto é, sistemas de software devem ser decompostos em unidades modulares menores, cada uma tratando de um concern.
Sommerville (2007) afirma que concerns são reflexões dos requisitos do sistema
e das prioridades dos stakeholders do sistema. Já Sutton Jr e Rouvellou (2002) definem concern como qualquer característica em um sistema de software. Essas características
podem estar diretamente relacionadas com o sistema em si ou com o contexto no qual elas estão inseridas, tais como políticas de uso do sistema e prioridades organizacionais.
Embora os avanços em todas as fases do processo de desenvolvimento de software tenham tido benefícios significantes, problemas relacionados à separação inadequada das características permanecem. Diante da permanência desses problemas, surgiu o estudo sobre separação de concerns avançada, incluindo programação e projeto
orientados a objetivos, programação orientada a aspecto e separação de características multi-dimensionais. Esse estudo trouxe uma série de ideias inovadoras para a programação e para o desenvolvimento de software em geral que amadureceram e se fundiram no desenvolvimento de software orientado a aspectos (Sutton Jr; Rouvellou, 2002).
No contexto de orientação a aspectos, são estudadas as crosscutting concerns,
traduzidas, nesta proposta, como interesses transversais, que são, segundo Kiczales et al
(1997), partes de um programa, que afetam muitas outras partes deste mesmo programa. Ainda segundo Kiczales et al (1997), interesses transversais podem ser
A programação orientada a aspectos (POA) visa encapsular os interesses transversais de um sistema, através de uma abstração chamada de aspecto, com o objetivo de reduzir os fenômenos acima citados e manter sua modularidade, permitindo, com isso, seu reuso. O estudo desses interesses transversais nas fases anteriores à implementação, desde a engenharia de requisitos até o projeto detalhado, é chamado de
Early-aspects.
No que diz respeito à engenharia de requisitos, essa área da engenharia de software visa prover meios para identificação, modularização, composição e análise da influência dos interesses transversais sobre outros requisitos do sistema, podendo ser requisitos funcionais ou não funcionais. Aplicando os fundamentos básicos sobre interesses transversais à engenharia de requisitos, pode-se dizer que um requisito dito transversal é aquele que está espalhado e entrelaçado com outros requisitos do sistema. Esses requisitos algumas vezes são bastante óbvios e outras, bastante sutis, por isso sua identificação costuma ser considerada difícil (Ali; Kasirun, 2008).
2.2. PL-AOVgraph
O modelo de metas PL-AOVgraph (Santos, 2010) é uma extensão ao modelo de metas AOV-Graph (Silva, 2006) com suporte à variabilidade. Assim, PL-AOVgraph é uma linguagem de modelagem de requisitos que herda todas as funcionalidades de AOV-Graph. Embora esses modelos sejam essencialmente gráficos, temos trabalhado em sua representação textual, que é mais facilmente manipulável.
Da mesma forma que AOV-Graph, modelos PL-AOVgraph são grafos orientados constituídos pelos seguintes tipos de elementos: (i) task (tarefa): representa
um requisito funcional; (ii) softgoal (softmeta): representa um requisito não funcional;
e, (iii) goal (meta): representa uma meta organizacional. Os relacionamentos entre os
elementos de PL-AOVgraph podem ser de 3 (três) tipos: contribuição, correlação e transversal. A Figura 1 mostra como os elementos e relacionamentos são representados graficamente em PL-AOVgraph.
Figura 1: Elementos e relacionamentos de PL-AOVgraph (representação gráfica)
O relacionamento de correlação indica a influência, positiva ou negativa, que um determinado requisito pode exercer sobre outro (relação um-para-um). Essa influência pode ser classificada em 5 (cinco) níveis: (i) Make– indica que um requisito só existe se
o outro existir; (ii) Break– indica que um requisito impossibilita a existência do outro;
(iii) Help– indica que um requisito reforça o outro; (iv) Hurt– indica que um requisito
afeta o outro; e, (v) Unknown – indica que existe influência entre os requisitos, porém
não é possível identificar se é positiva ou negativa.
Na representação textual de PL-AOVgraph, o relacionamento de contribuição é representado pela relação hierárquica (um-para-um) entre elementos (task/goal/softgoal)
filhos e pais, respectivamente, origem e destino do relacionamento. Essas contribuições podem ser de 4 (quatro) tipos: (i) And – indica que o elemento é obrigatório para a
concretização do elemento pai; (ii) Or – indica que o elemento é opcional para a
concretização do elemento pai; (iii) Xor– indica que apenas um dos elementos com este
tipo de relacionamento deve ser satisfeito para que o elemento pai também seja; e, (iv)
Inc-or – indica que no mínimo um e no máximo todos os elementos com este tipo de
relacionamento devem ser satisfeitos para que o elemento pai também seja. Os três primeiros tipos de relacionamento de contribuição foram herdados do AOV-Graph (Silva, 2006)
Diferentemente das contribuições e das correlações que são relacionamentos um-para-um, o relacionamento transversal é uma relação de n-para-n, que permite a modularização de requisitos espalhados e entrelaçados entre si, uma vez que muitas interações são condensadas em poucos relacionamentos transversais (Silva, 2006). Assim, ele reduz a quantidade de relacionamentos de contribuição entre tasks,goals e softgoals, e torna explícito quais interesses são transversais aos demais.
A descrição do relacionamento transversal é baseada nos elementos do Desenvolvimento de Software Orientado a Aspecto (DSOA) propostos pela linguagem AspectJ, assim, ela é composta de: (i) Source – que é a origem do relacionamento, isto
é, qual requisito afeta outros requisitos; (ii) Pointcut – que é o conjunto de destinos do
relacionamento, isto é, os componentes que são afetados pelo source; (iii) Advice– que
especifica quais dos elementos filhos de source se espalham e se entrelaçam nos pointcuts. Podem ser do tipo before, around ou after que indicam a maneira como o advice afeta o pointcut: pré-condição, decomposição e pós-condição do elemento em
relação ao pointcut, respectivamente. (iv) Intertype Declarations – que adiciona um
novo tipo de elemento ao modelo. Podem ser do tipo Attribute ou Element que
adicionam um novo tipo de dado e um novo elemento, respectivamente, ao modelo de requisitos.
Adicionalmente, PL-AOVgraph admite a inserção de novas propriedades ao modelo através da palavra reservada property e com este recurso define seis
cardinalityMax permite a atribuição de cardinalidade aos elementos, mínima e máxima,
respectivamente; a propriedade groupFeature permite a declaração explícita dos
membro de um grupo. Essa propriedade atua conjuntamente com as propriedades
cardinalityGroupMin e cardinalityGroupMax que permite a inserção de cardinalidade,
mínima e máxima respectivamente, aos grupos; e, a última propriedade é a isFeature
que permite determinar os elementos de PL-AOVgraph que não devem ser transformados em features. Esta propriedade é relevante quando se pretende obter um
modelo de features a partir de um modelo PL-AOVgraph, uma vez que nem sempre um
requisito é equivalente a uma feature.
As Figuras 2 e 3 ilustra uma pequena parte do modelo PL-AOVgraph do Crisis Management System (CMS) (Kienzle; Guelfi; Mustafiz, 2009), gráfica e textualmente,
respectivamente. O CMS é um sistema cujo documento de requisitos foi utilizado neste trabalho como estudo de caso. Nesse exemplo, a tarefa “Manage [Communication]”
contribui para 2 (duas) tarefas e 4 (quatro) softmetas. Essas contribuições são
representadas pelas setas ‘and’ entre os nós na Figura 2 e pelos rótulos entre parênteses
na Figura 3. Entretanto, a medida que o modelo cresce é difícil manter sua legibilidade. Os relacionamentos transversais são, então, uma estratégia para separação de características e para redução do número de relacionamento existente.
Figura 3: Relacionamentos de contribuição em PL-AOVgraph no modo textual
Figura 4: Relacionamento transversal no modo textual de PL-AOVgraph
A Figura 4 mostra o relacionamento transversal que substitui aqueles relacionamentos apresentados nas Figuras 2 e 3, isto é, substitui os relacionamentos de
contribuição originários da tarefa “Manage [Communication]”, na figura 2,
representados pelas setas, e na figura 3, representados pela sua referência (task_ref). O
source desse relacionamento é a meta “Crisis resolved”, esta meta é o primeiro
os elementos afetados pelo advice, as 2 (duas) tarefas (“Use [alternate communication channels]” e “Manage [Crisis]”) e as 4 (quatro) softmetas (“Reliability [Communication]”, “Communication, coordination, info Access from rescue resources = 20000”, “Time of delay in communication <= 500ms” e “Deterioration factor on communication <= 0.0001/1000km”). O bloco de advice define o elemento que está
espalhado ou entrelaçado com os elementos do poincut, ou seja, a tarefa “Manage [Communication]”.
Além disso, PL-AOVgraph possui algumas ferramentas para apoiar o engenheiro na elaboração dos modelos de requisitos. Dentre elas, pode ser destacado a ReqSys (Santos, 2010) e a ReqSys-MDD (Santos, 2012). Ambas são plug-ins para o
Eclipse que automatizam o mapeamento proposto por Santos (2010) entre PL-AOVgraph e Modelo de Features. Sendo o primeiro totalmente implementado na
linguagem de programação Java, enquanto que o segundo utilizou-se da abordagem MDD (Model Driven Development) para a geração de código, de forma automática.
Além disso, ReqSys-MDD propõe novas regras para solucionar as restrições de mapeamento existentes no ReqSys e adiciona um editor que possibilita a utilização do recurso de auto-completar, reconhecendo as palavras reservadas e indicação de erros léxicos e sintáticos no momento da edição.
Porém, essa ferramenta não contempla a funcionalidade de identificar os interesses transversais da especificação PL-AOVgraph, ela apenas apoia a edição desses modelos e transforma-os em modelos de features, estando a cargo do engenheiro de
requisitos a tarefa de identificar os interesses transversais e escrever os relacionamentos transversais. E ainda, não existe uma maneira sistemática para ajudá-los a realizar essas atividades, há apenas algumas heurísticas definidas por Silva (2006). Nesse contexto, este trabalho propõe evoluir a ferramenta ReqSys-MDD, adicionando a ela o método de identificação de interesses transversais aqui proposto.
2.3. Identificação de Interesses transversais
O objeto de estudo das abordagens orientadas a aspectos é o interesse transversal. Como os interesses transversais podem ser os responsáveis pelos fenômenos de espalhamento e entrelaçamento, essas abordagens têm se preocupado na redução dos problemas ocasionados por esses fenômenos. Dessa forma, é proposto que essa redução é conseguida através da identificação, da separação e da composição de interesses transversais.
implementadas) e tratadas separadamente. Enquanto que a composição garante uma integração completa e coerente entre as características antes separadas.
Para maximizar seus benefícios, a ideia da orientação a aspectos deve ser seguida a partir das primeiras atividades do desenvolvimento de software e aplicada aos diversos artefatos produzidos.
No contexto de engenharia de requisitos orientada a aspectos, um documento de especificação de requisitos deveria documentar todos os requisitos do sistema, incluindo aqueles identificados como transversais bem como os relacionamentos existentes entre os requisitos do sistema. Entretanto, na realidade, raros são os documentos que explicitam quais requisitos são transversais. Segundo Rosenhainer (2004), a principal razão para isto ocorrer é que, geralmente, não há tempo suficiente durante o desenvolvimento de um projeto de software para fazer grandes melhorias no documento de especificação de requisitos.
No entanto, sem esse detalhamento é difícil de identificar como os requisitos são influenciados por outros e como isto irá impactar no processo de desenvolvimento de software. E ainda, se esses interesses transversais não forem identificados, elas irão afetar a escolha da arquitetura do sistema, causando mais custo, tempo e esforço (Ali; Kasirun, 2008).
Ali e Kasirun (2008) ressaltam a importância de identificar e documentar os interesses transversais nas fases iniciais, citando 3 (três) vantagens. A primeira vantagem citada é que uma vez que os interesses transversais estão bem encapsulados, fica fácil identificar os efeitos que um requisito exerce sobre outros, pois, por natureza, eles influenciam outros requisitos.
A segunda vantagem citada é que, como os interesses transversais podem ser tanto requisitos funcionais quanto requisitos não funcionais, desprezar esses interesses transversais leva ao desenvolvimento de um software incompleto uma vez que a elicitação desses requisitos que vão assegurar a completude do sistema de software.
E, a terceira e última vantagem citada é que tendo a documentação dos requisitos e dos relacionamentos transversais, facilitará a evolução de requisitos, diminuindo a ocorrência de erros em fases posteriores.
Apesar de sua grande importância, identificar interesses transversais em requisitos é considerado, por muitos, uma tarefa complexa e tediosa (Rosenhainer, 2004), visto que envolve a análise de muitos documentos ou documentos muito extensos. Além disso, esses interesses transversais podem ser mencionados, ao longo do documento, usando-se termos distintos, tornando sua identificação ainda mais difícil.
grandes grupos de abordagens de identificação: (i) aqueles que processam documentos de requisitos textuais e tem ferramenta de apoio; e, (ii) aqueles que lidam com tipos de modelos específicos, por exemplo, modelos de casos de uso, i* e V-graph e não tem ferramenta de apoio.
No contexto de PL-AOVgraph, Silva (2006) e Yu; Leite; Mylopoulos (2004) propõem algumas heurísticas para realizar essa atividade. Eles utilizam heurísticas (baseadas em análise fan-in) que consideram os elementos intrínsecos à linguagem para
realizar a identificação de interesses transversais, após a identificação, os interesses transversais são representados usando elementos da linguagem. Vale salientar que utilizando essas heurísticas, pode-se identificar tanto interesses transversais funcionais quanto não funcionais. E ainda, que elas não compõem um método sistematizado para a realização da atividade, isto é, elas não seguem um processo bem definido para sua execução.
A seguir são apresentadas a algumas dessas abordagens existentes. Essas abordagens foram identificadas por meio de uma revisão sistemática e embasaram o desenvolvimento do método de identificação de interesses transversais aqui proposto.
2.3.1. Abordagens que processam documentos de requisitos textuais
Nesta Seção são apresentadas algumas abordagens de identificação de interesses transversais que se utilizam do processamento de documentos de requisitos textuais para a realização dessa atividade.
2.3.1.1. Theme/Doc
A abordagem Theme/Doc, desenvolvida e proposta por Baniassad e Clarke (2004), apresenta uma identificação semi-automatizada de interesses transversais em documentos de especificação de requisitos, através da análise léxica.
O processo Theme/Doc consiste das seguintes atividades: primeiramente, os requisitos presentes no documento de requisitos devem ser enumerados. Em seguida, o analista deve analisar todo o documento a fim de identificar o conjunto de verbos, chamados de tema nessa abordagem. Cada um dos temas é classificado como ação maior ou ação menor. Os temas ação menor podem ser classificados como sub-temas dos temas ação maior. Assim sendo, as relações entre os temas e os requisitos deste documento são mapeados através de uma modelo, chamado “ActionViewModel”.
O foco desta abordagem é os requisitos que estão presentes em mais de um tema. Se um requisito está presente em dois ou mais temas, deve-se decidir qual dos temas deve prover a funcionalidade. Assim, ao final do processo, não há nenhum requisito diretamente associado a mais de um tema.
estão diretamente relacionados com eles são também considerados interesses transversais. Para validar esse método, foi realizado um estudo de caso com o conjunto de requisitos do Crystal Game.
A abordagem Theme/Doc pode ser dita semi-automatizada, uma vez que parte dela só pode ser aplicada de forma manual, enquanto outra parte pode ser aplicada com o auxílio de ferramentas. As etapas mais iniciais, como identificação de palavras de ação e dos temas são feitas de maneira manual, sem o auxílio de qualquer ferramenta. Já a criação dos modelos Action View Model pode contar com o auxilio da ferramenta Theme/Doc Tool, desenvolvida especialmente para a aplicação desta abordagem.
Assim, as principais características dessa abordagem são que ela identifica interesses transversais tanto em requisitos funcionais quanto em requisitos não funcionais; ela analisa documentos de requisitos que estejam de acordo com o padrão definido; e, ela propõe a identificação através de análise léxica e contextual.
2.3.1.2. DISCERN
Rosenhainer (2005) propõe um método baseado em análise contextual de documentos de requisitos que pretende identificar os interesses transversais e compô-los nas descrições de casos de uso.
Figura 5: Visão geral do método DISCERN
Fonte: Rosenhainer (2005)
As principais contribuições desse método são suporte a extração de interesses transversais não funcionais (NFRs) em documentos relacionados a requisitos; suporte a coleta de informações dos documentos de requisitos, para refinar as descrições de casos de uso, de modo que permita descrições não ambíguas de pointcuts; e, especificações
mais elaboradas de pointcuts em casos de uso aspectuais.
Para realizar a identificação proposta pelo método, são utilizadas técnicas baseadas no processamento de linguagem natural, tal como procura por padrões textuais (podem incluir expressões regulares de palavras-chave ou frases chave, estruturas gramaticais ou propriedades morfológicas). Assim sendo, são utilizadas as técnicas de pré-processamento de linguagem: POS tagging, sentence boundary disabiguation, lemmatizing, parsing for deriving syntax trees (Rosenhainer, 2005). Para validar esse
método, foi realizado um estudo de caso com uma aplicação para loja de animais (Pet Store Application).
Desse modo, as principais características deste método são: analisar qualquer documento de requisito textual; realizar análise contextual através de técnicas de processamento de linguagem natural para identificação de interesses transversais; e, identificar interesses transversais apenas em requisitos não funcionais.
2.3.1.3. Early-AIM
A principal meta do método Early-AIM, acrônimo de Early Aspects Identification Method, proposto por Sampaio et al (2005), é determinar candidatos a
aspectos, através de técnicas de processamento de linguagem natural, no documento de requisitos, independentemente de como eles são estruturados.
Essa abordagem utiliza-se de um processador de linguagem natural, WMATRIX, que provê recursos como identificação semântica, análise de frequência e concordância.
Fonte: Sampaio et al (2005)
A esquematização do método Early-AIM pode ser vista na Figura 6. No passo 1 é feita a análise dos documentos existentes, que são resultados da elicitação de requisitos, como entrevistas e descrição informal do sistema, pelo processador WMATRIX. Os passos 2 e 3 são opcionais e visam facilitar a produção do modelo aspectual no passo 4, através da análise de modelos intermediários, como Viewpoints e
casos de uso.
No passo 4, o modelo é produzido, mostrando os requisitos, os candidatos a aspectos e seus relacionamentos. A realização desse passo é baseada nas seguintes tarefas:
1. Verbos: o WMATRIX procura por verbos e produz um modelo que representa os relacionamentos entre os requisitos;
2. Análise semântica e domínio léxico: um domínio léxico, baseado em listas de requisitos não funcionais (NFR), categoriza os interesses transversais bem conhecidos. O WMATRIX vai procurar os candidatos a aspectos através da marcação semântica e pelo domínio léxico evitando a escolha de candidatos errados.
3. Meta-modelos e heurísticas: para produzir a saída do passo (modelo aspectual), serão olhados os candidatos a aspectos identificados, e também os modelos intermediários (opcionais) de entrada tais como seus meta-modelos e construção de heurísticas.
Para uso dessa abordagem, existe a ferramenta semi-automática EA-Miner (Sampaio et al, 2005) que utiliza-se do WMATRIX para identificar os interesses
transversais e seus relacionamentos entre os requisitos. Para validar a proposta, foi realizado um exemplo demonstrativo com um sistema de cobrança de pedágio para as estradas portuguesas.
Assim, podem-se destacar como principais características deste método: analisa qualquer documento de requisito textual; identificar interesses transversais em requisitos funcionais e em requisitos não funcionais; e, a identificação de interesses transversais é feita através da análise semântica e do domínio léxico;
2.3.1.4. CCCINPL(Crosscutting Concern Identification using NLP)
Syd Ali e Kasirum (2008) propõem uma abordagem totalmente automatizada para a identificação de interesses transversais ainda nas etapas mais iniciais do processo de desenvolvimento de software, tendo como artefato de análise o documento de
1. Estruturar os requisitos: todos os requisitos do sistema são numerados a
fim de possibilitar sua fácil identificação nas etapas seguintes. Esta é a única etapa não automatizada do processo;
2. Remover redundâncias: todas as redundâncias identificadas entre os
requisitos são eliminadas;
3. Aplicar análise de parte da escrita: os verbos presentes na descrição de
cada um dos requisitos são extraídos. Analisa-se então a frequência da ocorrência de cada verbo no documento de requisitos em análise. Se o verbo tem uma grande frequência dentro deste documento, os requisitos que estão associados a ele são fortes candidatos a aspectos;
4. Aplicar análise semântica: o contexto no qual os verbos estão inseridos é
analisado por um marcador semântico. Esses marcadores tem a função de identificar verbos diferentes que são utilizados para representar requisitos similares;
5. Filtrar verbos: a partir dos resultados apontados pela etapa de análise
semântica, verbos utilizados em duplicidade são descartados;
6. Mapear visão de relacionamento: uma matriz é gerada para identificar e representar as relações existentes entre os requisitos e os verbos previamente identificados. Os campos desta matriz são preenchidos quando um verbo está presente na descrição de um requisito;
7. Refinar visão de relacionamento: nesta etapa é feita a análise da matriz de visão de relacionamentos a fim de identificar quais verbos estão espalhados por diversos requisitos e quais requisitos possuem mais de um verbo;
8. Verbos dominantes: uma nova matriz é gerada para mapear os relacionamentos de entrelaçamento entre os requisitos a fim de identificar o verbo dominante do requisito e verificar se ele é chamado por outros requisitos. Esse verbo dominante é o candidato a aspecto.
9. Modelar interesses transversais: os verbos e os requisitos são modelados
usando um Action View Model, emprestado da abordagem Theme/Doc.
textos de documentos de requisitos escritos em inglês a fim de identificar seus interesses transversais, através técnicas baseadas no Processamento de Linguagem Natural (NPL).
Para validar o método CCCINPL, foram realizados dois estudos de casos: um com um sistema simples e o outro com um sistema um pouco mais complexo. O primeiro foi realizado com o Campus Messenger System cujo documento possuía 120
palavras em 1 página. O segundo foi realizado com o Auction System Problem Description cujo documento possuía 443 palavras em 2 páginas.
Portanto, as principais características deste método são: analisar qualquer documento de requisitos textual escrito em inglês; identificar interesses transversais em requisitos funcionais e em requisitos não funcionais; a identificação é realizada através da análise semântica e do domínio léxico, utilizando-se das técnicas de processamento de linguagem natural; e, a existência da ferramenta de apoio automática.
2.3.2. Abordagens que processam modelos específicos
Nesta Seção são apresentadas algumas abordagens de identificação de interesses transversais em modelos específicos.
2.3.2.1. Identificação de interesses transversais em modelos UML
Araújo et al (2002) apresentam uma abordagem voltada para a identificação de
interesses transversais relativas a requisitos não funcionais utilizando a Unified Modelling Language (UML). A ideia central desta abordagem é estender os modelos da
Figura 7: Processo da abordagem
Fonte: Araújo et al (2002)
A Figura 7 mostra o processo proposto por essa abordagem. Este processo é dividido verticalmente em 3 (três) principais partes: interesses transversais (tradução de
crosscutting concerns), características funcionais (tradução de functional concerns) e
composição dos requisitos (tradução de composed requirements).
A parte do processo identificada como interesse transversal manuseia com os requisitos não funcionais e então identifica aqueles que são transversais. Os interesses transversais serão aqueles requisitos não funcionais que afetam mais de um caso de uso.
Já a parte do processo identificada como características funcionais realiza uma tradicional especificação de requisitos funcionais, usando de uma abordagem semelhante à UML onde o modelo de caso de uso é a principal técnica de especificação.
E, a parte do processo identificada como composição dos requisitos começa com a composição dos requisitos funcionais com aspectos. Após, é realizada a identificação e a resolução dos conflitos. Os conceitos de overlapping, overriding e wrapping são
utilizados para definir a composição.
Overlapping: o interesse transversal modifica o requisito funcional que
Overriding: o interesse transversal sobrepõe o requisito funcional que ela
afeta. Neste caso, a interesse transversal substitui o comportamento do requisito funcional.
Wrapping: o interesse transversal encapsula o requisito funcional que ela
afeta. Neste caso, o comportamento do requisito funcional é envolvido pelo comportamento do interesse transversal.
Esses conceitos relacionados ao comportamento do interesse transversal são passados para o diagrama de caso através novos estereótipos, como o estereótipo
<<wrappedBy>>. Para validar essa proposta, foi realizado um estudo de caso com a
versão simplificada de um sistema real implantado na rede de rodovias portuguesas. Desse modo, pode-se destacar as principais características: analisa casos de uso textuais; identifica interesses transversais apenas em requisitos não funcionais; e, a identificação dos interesses transversais é baseada nos fenômenos de espalhamento e entrelaçamento.
2.3.2.2. Identificando interesses transversais em modelos i*
Essa abordagem, desenvolvida por Alencar et al (2006), propõe um conjunto de
regras para identificar interesses transversais presentes em modelos de requisitos baseados em i*, permitindo que esse modelo seja simplificado.
No contexto de i*, um interesse transversal pode ser identificada seguindo as regras a seguir.
Regra 1 – Identificando interesses transversais no modelo SD: Quando a mesma dependência é requerida por no mínimo 2 atores, a operacionalização correspondente à dependência, é uma interesse transversal;
Regra 2 – Identificando interesses transversais no modelo SR: Se uma tarefa, que é diretamente ou indiretamente relacionada a uma dependência externa, é requerida por 2 ou mais tarefas, que são relatadas a outras dependências externas, essa tarefa é uma interesse transversal; Regra 3 – Remover redundâncias: os interesses transversais identificados
pela regra 2, que correspondem a operacionalização dos interesses transversais identificados pela regra 1, precisam ser fundidas. Os interesses transversais finais são aquelas que correspondem às operacionalizações.
curvas com triângulos escuros (a direção do triângulo indica a direção do relacionamento).
A ferramenta iAspectPlugin (Monteiro et al, 2007) é um plug-in baseado na
ferramenta OME e foi desenvolvida com o propósito de automatizar as regras de identificação de interesses transversais em modelos I*. Para ilustrar o funcionamento dessa ferramenta, foi utilizado o sistema Health Watcher.
Assim, as principais características deste método são: analisar modelos de requisitos em i*; identificar interesses transversais em requisitos funcionais e em requisitos não funcionais; e, a identificação é realizada através de três regras pré-definidas.
2.3.2.3. Identificando interesses transversais em modelos V-graph
Essa abordagem, desenvolvida por Yu, Leite e Mylopoulos (2004), propõe que os interesses transversais sejam definidos através da identificação de tarefas que possuem alto fan-in.
Isto é, os relacionamentos existentes entre tarefas são utilizados na identificação de aspectos: as tarefas que contribuem ou estão correlacionadas a várias softmetas e metas indicam espalhamento e entrelaçamento.
Dessa forma, é proposto um processo sistemático para o refinamento de modelo V-graph. Ele termina quando todas as metas e softmetas raizes são satisfeitas. Além disso, ele é realizado de forma manual, entretanto é usada uma ferramenta de análise de meta durante cada etapa do processo para detectar conflitos e deteriorações. Um conflito ocorre quando uma rotulagem, como satisfeita ou negada, de meta folha conduz outras metas para serem rotuladas de ambos os tipos, satisfeita e negada. Uma deterioração ocorre quando a rotulagem de softmetas durante a primeira etapa da iteração é mais fraca que durante as etapas anteriores à iteração.
O processo seguido por essa abordagem é descrito a seguir. Uma vez que se têm as informações a respeito das metas elicitadas, o processo de identificação de aspectos pode começar. Esse processo começa pela listagem das metas e softmetas raizes. Em seguida, o engenheiro de requisitos decompõe metas (softmetas) em submetas (subsoftmetas) ou tarefas e correlaciona com metas/tarefas, na perspectiva funcional, ou metas/operacionalizações, na perspectiva não funcional.
Posteriormente, é verificado se o grafo contém deterioração ou conflitos. Se forem identificados deterioração ou conflitos, é necessário que sejam removidos. Assim sendo, esse processo de remoção se repete até que não haja mais conflitos e deteriorações e que as metas e softmetas estejam consistentes e satisfeitas ou satisficed.
Figura 8: Processo de identificação de interesses transversais em modelos V-graph
Fonte: (Yu; Leite; Mylopoulos, 2004)
3. Método de identificação de interesses
transversais em modelos PL-AOVgraph
Neste capítulo apresentamos o método de identificação de interesses transversais em especificações de requisitos PL-AOVgraph proposto por este trabalho e sua ferramenta de apoio. Para exemplificação deste método, trechos da modelagem PL-AOVgraph de um sistema de gerenciamento de crises (CMS - Crisis Management System) já apresentado anteriormente são utilizados.
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.
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 é
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.
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
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 .
3.2. Implementação do método de identificação na ferramenta
ReqSys-MDD
A ferramenta ReqSys-MDD, desenvolvida por Santos (2012), visa a automatização do mapeamento bidirecional entre PL-AOVgraph e Modelo de Features,
utilizando a abordagem MDD (Model Driven Development). Além disso, a
ReqSys-MDD fornece um editor para a linguagem PL-AOVgraph na forma textual que realiza além das análises léxica e sintática em tempo de edição, o reconhecimento das palavras reservadas e o recurso de auto-completar.
A necessidade de realizar análises para verificar se o modelo estaria em conformidade com seu metamodelo foi um dos motivos de se inserir o método de identificação de interesses transversais na ferramenta ReqSys-MDD uma vez que ela provê de um editor que efetua essa função. Além disso, outro motivo para essa integração seria centralizar as funcionalidades acerca de PL-AOVgraph em uma única ferramenta. Concebendo, assim, uma ferramenta mais completa e diversificada.
3.2.1 Arquitetura de ReqSys-MDD
Conforme descrito por Santos (2012), a implementação de ReqSys-MDD foi realizada no ambiente Eclipse, que disponibiliza o ambiente de desenvolvimento de
plug-in (Plug-in Developer Enviroment – PDE), o framework de modelagem (Eclipse Modeling Framework– EMF), ambos necessários para a elaboração dos metamodelos,
implementação das regras de mapeamento entre PL-AOVgraph e Modelo de Features definidas em Santos (2012).
Além disso, são utilizados os plug-ins XText e Acceleo que se integram ao EMF para realizar transformações de texto para modelo e de modelo para texto, respectivamente.
A implementação do método de identificação é um módulo adicional a este
plug-in ReqSys-MDD. A implementação foi feita no Eclipse, utilizando o ambiente Plug-in Developer Enviroment (PDE). E os métodos necessários para a identificação
dos interesses transversais são implementados utilizando-se da linguagem de programação Java. Os parsers desenvolvidos para as transformações de modelo para
texto e de texto para modelo, utilizando XText e Acceleo, respectivamente, são reusados de Santos (2012). A Figura 12 apresenta a arquitetura de ReqSys-MDD, em cinza escuro está o componente que implementa a identificação e especificação de relacionamentos transversais, desenvolvido neste trabalho.
Figura 12: Arquitetura de ReqSys-MDD
A Figura 13 apresenta o fluxo do módulo de identificação de interesses transversais em ReqSys-MDD. Nessa Figura, os componentes definidos por Santos (2012) estão representados em cinza claro e o componente que implementa a identificação de interesses transversais, em cinza escuro. O fluxo da identificação de interesses transversais se dá da seguinte forma: (i) a especificação PL-AOVgraph textual de entrada é analisada pela gramática do XText e transformada em um modelo XMI; (ii) a partir deste modelo XMI, são criados os objetos Java e através da análise da matriz de adjacência são identificados os interesses transversais, especificados os relacionamentos transversais e transformados em um modelo XMI; (iii) esse XMI é transformado, através do Acceleo, em uma especificação textual PL-AOVgraph.
Além disso, é importante ressaltar que foi utilizado na Figura 13 a nomenclatura
de “Especificação” para se referir ao documento escrito em PL-AOVgraph e a
nomenclatura de “Modelo” para se referir ao documento escrito em XML.
Figura 13: Fluxo da identificação de interesses transversais em ReqSys-MDD
Fonte: Adaptado de Santos (2012)
A Figura 14 apresenta a interface de ReqSys-MDD: (1) Menu de funcionalidades onde encontramos as opções referentes à identificação de interesses transversais e aos mapeamentos de Modelo de Features para AOVgraph e de
PL-AOVgraph para Modelo de Features; (2) Árvore de diretórios onde o usuário pode
Figura 14: Interface da ferramenta ReqSys-MDD
3.2.2. Algoritmo de identificação
Figura 15: Diagrama de atividades da identificação e especificação de relacionamentos transversais
Esse diagrama de atividades está organizado em três etapas, cada uma delas correspondente às atividades do método da Figura 9. Dessa maneira, a primeira etapa é responsável por criar a matriz de adjacência dos relacionamentos entre os elementos do modelo. Para isso, primeiramente, ocorre a leitura do arquivo XMI referente ao modelo PL-AOVgraph de entrada. Em seguida, são criados objetos Java de acordo com os elementos apresentados no arquivo XMI. E então, uma matriz de adjacência é criada, explicitando os relacionamentos de contribuição entre os elementos.
A segunda etapa é responsável pela análise da matriz de adjacência que foi criada em memória. Essa análise é composta pela contabilização dos relacionamentos de contribuição originados por cada elemento (relacionamento de contribuição de saída). Assim, o elemento que originar pelo menos a quantidade de relacionamentos de contribuição previamente definida é identificado como um interesse transversal e é armazenado em uma lista.
