Avaliação da Qualidade de Documentos de Requisitos
Orientado a Aspectos
Ricardo Argenton Ramos1 , André Carvalho1, Cleviton Monteiro1, Carla Silva1, *Jaelson Castro1,2, *Fernanda Alencar3, Ricardo Afonso4
1Centro de Informática
Universidade Federal de Pernambuco – UFPE Av. Prof. Luiz Freire s/n, Recife PE, Brasil
50732-970, +55 81 212618430
{rar2, allc, cvfm,ctlls, jbc}@cin.ufpe.br 2ITC- Istituto Trentino di Cultura
IRST -Instituto per la Ricerca Scientifica e Tecnologica, Trento-Povo, Italy
3Departamento de Eletrônica e Sistemas Universidade Federal de Pernambuco – UFPE Av. Prof. Luiz Freire s/n, Recife PE, Brasil
50732-970, +55 81 2126 8995 [email protected]
4Grupo de Tecnologias da Informação em Saúde (TIS) Núcleo de Tele-Saúde – NUTES - Hospital das Clínicas, Av. Prof. Moraes Rego, s/n, Cidade Universitária, Recife-PE, Brasil
50.670-420, telefone: +55 81 2126-3903. [email protected]
Resumo. Pesquisas promissoras na fase de requisitos utilizando a orientação a aspectos têm como propósito a utilização de técnicas que possibilitam separar e, posteriormente, compor os interesses que estão espalhados e entrelaçados no documento de requisitos. Novos fatores que surgem nesses documentos de requisito, tais como a separação de interesses, o tamanho e o acoplamento ainda não são avaliados qualitativamente, por falta de métricas. Este artigo apresenta um conjunto de métricas abstratas, que com o auxílio de diretrizes, podem ser instanciadas para medir um documento de requisitos orientado a aspectos que foi elaborado segundo qualquer abordagem. Além disso, é proposto um processo de medição.
Abstract. Recent proposals have looked at the requirements stage, using the aspect oriented programming, trying to separate and after to compose the concerns that are spread and tangled in the requirement document. New factors appear in these requirements documents, such as, crosscutting concerns, size and coupling are not qualitative evaluated, because there are not these metrics. This paper shows a set of abstract metrics that, with the help of guidelines, can be applied to measure an aspect oriented requirements document developed by any approach. Also a measurement process is proposed.
1 Introdução
O uso inadequado de processos de desenvolvimento de software gera grandes custos nas fases de manutenção deste software em desenvolvimento. É do conhecimento geral [19], que o custo da correção de erros já na fase de projeto é cerca de três a seis vezes mais alto do que na fase de definição de requisitos. Todavia, esse custo aumenta ainda mais quando a correção de erros é realizada em fases mais avançadas no processo de desenvolvimento.
O desenvolvimento de software orientado a aspectos (Aspect Oriented Software Development AOSD) surge como uma opção para que engenheiros de software organizem melhor todas as fases de desenvolvimento, desde os documentos de requisitos até a implementação e testes de softwares [4, 11, 26]. Por ser uma linha de pesquisa ainda em evolução, a maioria dos esforços iniciais têm sido concentrados na fase da implementação como uma solução para aumentar a facilidade de entendimento e, conseqüentemente, facilitar a manutenção e evolução desse software. Por esse motivo, na fase de implementação, é possível encontrar tanto técnicas de modelagem [18] e reengenharia [20] como ferramentas [9] que minimizam os esforços de engenheiros de software que trabalham com o AOSD nessa fase.
Por outro lado, a utilização do conceito de separação de interesses [5] e orientação a aspectos [13], já na fase de requisitos, permite uma melhor organização do documento de requisitos. Nessa nova visão, os requisitos que entrecortam outros requisitos [22] e os que são voláteis (suscetíveis a mudanças) [31] são identificados e modularizados como aspectos. Em um primeiro momento os termos “interesses entrecortantes” (do inglês crosscutting concerns) foram utilizados para classificar requisitos não funcionais que entrecortavam outros requisitos (funcionais ou não). Dessa forma, somente poderia ser considerado um aspecto algum requisito não funcional. Em trabalhos recentes [31] o termo interesse é utilizado para classificar qualquer tipo de requisito (funcional ou não-funcional). Quando um desses interesses entrecorta outros interesses ou quando o interesse é volátil, esse é considerado um candidato a aspecto.
Contudo, apesar das prováveis facilidades que o AOSD sugere para a fase de requisitos, ainda não existe preocupação em se desenvolver trabalhos que avaliem qualitativamente um documento de requisitos orientado a aspectos. Santa´Ana e outros [25, 26] avaliam qualitativamente e quantitativamente os benefícios de implementações de padrões de projeto em sistemas orientados a aspectos e orientados a objetos. Não sendo avaliados, porém, os documentos de requisitos.
No contexto de métricas que auxiliem o engenheiro de software a avaliar a qualidade de documentos de requisitos orientados a aspectos, Ramos [21] elabora um conjunto de métricas para medir a qualidade dos aspectos especificados em uma abordagem orientada a casos de uso aspectuais. Nessa mesma linha, este artigo propõe um conjunto de métricas abstratas que podem ser instanciadas, com o auxilio de diretrizes em um documento de requisitos com aspectos, bem como um processo de medição. As métricas serão utilizadas em abordagens diferentes de engenharia de requisitos com aspectos. Para ilustrar é apresentado um estudo de caso.
as métricas para avaliar documentos de requisitos orientados a aspectos, na Seção 5 é descrito como foi realizado o estudo de caso. As considerações finais são apresentadas na Seção 6.
2. Orientação a Aspectos na Fase de Requisitos
Czarnecki e Eisenecker [5] comentam que a necessidade de manipular um requisito importante de cada vez, durante o desenvolvimento de um sistema, é chamado de princípio da separação de interesses. Linguagens de programação geralmente fornecem construtores para organizar um sistema em unidades modulares que representam os interesses funcionais da aplicação. Essas unidades são expressas como objetos, módulos ou procedimentos. A maioria dos softwares consiste em um conjunto de interesses que se entrecortam em vários módulos diferentes. Como conseqüência da não modularização desses interesses, a implementação resulta em softwares de complexo entendimento e, conseqüentemente, de difícil manutenção [19, 29].
A separação destes interesses é de fundamental importância para que artefatos dos vários estágios do desenvolvimento do software sejam legíveis e sejam facilmente manuteníveis. Esse princípio estabelece que um problema deve ser decomposto em unidades menores, claramente separadas, de maneira que cada uma delas represente um único interesse. [3, 13, 14]
Com o objetivo de apresentar técnicas de programação capazes de cobrir a separação de interesses de um sistema, em código, foi estudado e implementado um novo paradigma de programação, a Programação Orientada a Aspectos POA [13]. A POA traz uma nova unidade modular chamada “aspecto”, que encapsula comportamentos que interferem (entrecortam) em múltiplas classes. Trabalhos iniciais com POA foram desenvolvidos maciçamente para solucionar problemas que ocorrem em nível de código [7, 8, 13, 20]. Somente mais recentemente alguns pesquisadores começaram a trazer os benefícios da orientação a aspectos para as fases inicias do processo de desenvolvimento[2, 4, 22, 23, 28].
A Engenharia de Requisitos Orientada a Aspectos surgiu da necessidade de modelar certos requisitos que se encontram repetidos ou espalhados na especificação de requisitos, chamados requisitos aspectuais. As primeiras investigações realizadas foram sobre a relação entre atributos de qualidade e interesses que se encontram espalhados e repetidos na especificação de requisitos [17, 22]. Uma das primeiras abordagens que surgiram na área, propunha um modelo genérico para engenharia de requisitos orientada a aspectos, e foi chamada de AORE (Aspect-Oriented
Requirements Engineering) [22]. O modelo trata propriedades não-funcionais como
interesses do sistema e separa-os das propriedades funcionais, através de uma série de passos bem definidos.
Araújo e outros [2] propõem o uso de aspectos concentrado na especificação de requisitos baseado em cenários. Nesse processo, primeiramente, os casos de uso são mapeados em um conjunto de cenários que, posteriormente, são separados em aspectuais e não-aspectuais. Os aspectuais são representados utilizando especificação de padrões de interações (Interaction Patterns Specifications) e os não-aspectuais como diagramas de casos de uso. No passo seguinte, cada cenário é traduzido para uma máquina de estados correspondente e combinados para formação de um conjunto de máquinas de estados que representam os requisitos de modo geral
Ainda no foco de trabalhos sobre requisitos orientados a aspectos, Silva e outros [27] propõem o uso de modelo de metas V-graph para modelar aspectos e requisitos. A proposta possui basicamente três fases: Separação, Composição e Visualização. A separação consiste na modelagem dos requisitos identificando algumas restrições. A composição funciona de forma semelhante ao combinador (weaver) das linguagens de programação orientadas a aspectos, interpretando as restrições transversais e gerando um modelo único com todas as informações. A última fase trata da geração de diferentes visões do modelo integrado. Assim, o modelo garante aos desenvolvedores uma ampla visualização das influências exercidas pelos requisitos em toda a estrutura do sistema.
Utilizando como base o processo de desenvolvimento unificado [12], Sousa [28] realiza uma adaptação desse processo para o desenvolvimento orientado a aspectos, onde o principal foco desta pesquisa é o desenvolvimento guiado por casos de uso [11], possibilitando a separação de interesses transversais nas fases de requisitos, análise e projeto utilizando fundamentos da orientação a aspectos. Nesse processo as unidades bases (que podem ser afetadas por aspectos) correspondem às unidades de decomposição comumente utilizadas em cada um dos fluxo de atividades do processo unificado, por exemplo: casos de uso no fluxo de requisitos; classes de análise no fluxo de análise; e classes de projeto no fluxo de projeto. Sendo que os possíveis pontos de junção referem-se a elementos nessas unidades que representam pontos de execução: no fluxo de requisitos pode-se especificá-los em função dos eventos (ou passos) nos cenários de um caso de uso; no de análise, em termos de mensagens trocadas entre objetos de análise; e no de projeto, em termos de operações de classes.
Partindo do princípio de que aspectos são encapsulados nas mesmas unidades de decomposição existentes em cada um dos fluxos considerados, Sousa [28] cria um estereotipo especial para cada fase, como por exemplo, caso de uso aspectual (Figura 1), classe de análise aspectual, para indicar que o comportamento do aspecto deverá ser inserido em alguma parte das unidades que ele afeta. O termo
crosscuts refere-se ao relacionamento entre uma unidade aspectual e uma unidade
afetada por ela. Uma tabela denominada de tabela de composição armazena para cada aspecto identificado e em cada fluxo, informações relativas à composição entre um aspecto e a(s) unidade(s) que ele afeta.
Fig. 1. Diagrama (parcial) de casos de uso de um sistema de banco pela Internet.
A principal contribuição das propostas de se usar aspectos nas fases inicias do processo de desenvolvimento é a ajuda na identificação de conflitos entre os requisitos, para que medidas sejam tomadas o quanto antes, onde o custo é muito menor do que em fases posteriores. Além, de promover uma melhor legibilidade e manutenibilidade dos artefatos produzidos nos vários estágios do desenvolvimento. [22]
A Seção seguinte apresenta alguns trabalhos que utilizam métricas para avaliar a qualidade na fase de requisitos.
3. Metodologias e Métricas para Avaliação da Qualidade de
Requisitos
A comunidade de engenharia de software vem adaptando padrões existentes como a ISO 9126 [10] para que desta maneira se permita fornecer suporte para que haja conformidade e assim possibilitando elaborar métricas para medir a qualidade de um produto de software [19, 29]. A medição de um software é importante para garantir a qualidade do produto, avaliar a produtividade das pessoas que o produzem e formar uma linha base para estimativas. Portanto são muitas as vantagens de se poder medir a qualidade e corrigir seus erros, inconsistências e saber sua completitude, porém quanto mais cedo nas fases de desenvolvimento do software for descoberto os erros, menos custoso é o seu processo de correção [19]. Por esse motivo a medição da qualidade de um produto de software na fase de requisitos tem sido uma área bastante promissora.
Tabela 1. Atividades que asseguram a qualidade em documentos de requisitos. Atividade Objetivo Principal
Análise Identifica conflitos em requisitos. Verificação Detecta defeitos em requisitos.
Validação Certifica que os requisitos são consistentes com as intenções dos clientes e usuários.
Cobrar Tarifa por Transação Extra Limitar Valor da Movimentação <<crosscuts>> <<crosscuts>> <<crosscuts>> Legenda Requisitos Aspectuais Realizar Transação Bancária Realizar Transação Financeira Realizar Transação de Consulta Visualizar
Saldo da Conta Extrato da Conta Visualizar
As atividades que asseguram a qualidade em documentos de requisitos são divididas em três, como sumarizadas na Tabela 1 [6].
A medição quantitativa dos requisitos de um sistema é utilizada como meio de medir o tamanho do produto de software, por derivação, esforço, tempo e custo necessário para implementá-lo. Uma técnica bastante utilizada para esse fim é a analise de pontos de função, que foi introduzida por Allan Albrecht [1]. A proposta de Albrecht é que o software deveria ter o seu tamanho medido a partir das funções implementadas para o usuário, examinadas sob a ótica do usuário. [1]
A maioria dos métodos utilizados para avaliação de qualidade (métricas) de artefatos de software não levam em consideração o princípio da engenharia de software de que o custo para modificar um requisito na fase de manutenção chega a ser cinqüenta vezes maior do que na fase de definição de requisitos [19, 29]. Portanto, a medição da qualidade na fase de requisitos é uma estratégia importante para reduzir os custos de manutenção [19, 29]. Além de trazer esses benefícios, a obtenção de métricas na fase de requisitos possibilita também o respaldo de estudos estatísticos que viabilizem a melhoria do processo de engenharia de requisitos e do software em si.
Durán [6] propõe uma ferramenta denominada REM (REquirements
Manager - Gerenciador de Requisitos), que dá apoio a verificação de requisitos que
estão armazenados em XML [32]. Em seu trabalho são elaboradas heurísticas que tratam de alguns problemas recorrentes em documentos de requisitos, tais como: ambigüidade, completitude, rastreabilidade. A ferramenta REM também dá apoio a verificação de casos de uso, desta maneira foram elaboradas algumas métricas para verificar a qualidade em casos de uso.
As métricas elaboradas no trabalho de Durán [6] medem fatores de complexidade em caso de uso como o número de passos de um caso de uso, passos condicionais, exceções e o número de vezes que um caso de uso é incluído ou estendido em outros casos de uso.
Algumas métricas como a relatada anteriormente apenas fornecem mecanismos para se medir o tamanho, ou a complexidade, não fornecendo mecanismos para indicar se esse ou aquele valor obtido está bom ou ruim. Porém, existem métricas que auxiliam o engenheiro de software a fazer uma avaliação dando um escore final para um determinado fator que foi medido, como é o caso da metodologia apresentada por Reis [24].
Reis [24] elabora uma metodologia denominada REQE (Requirements
Engineering Quality valuation), essa metodologia propõe a avaliação da qualidade de
aplicações web na fase de requisitos através da medição de atributos de qualidade, tendo assim como benefício à possibilidade de descobrir erros de uma forma antecipada. A aplicação da metodologia REQE consiste em cinco fases: i) Representação das características, ii) Subcaracterísticas e atributos de qualidades, iii) Especificação descritiva da árvore de característica, subcaracterísticas e atributos de qualidade, iv) Associação de pesos aos nós, Associação de escores aos atributos de qualidade e v) Cálculo geral.
Na Seção seguinte são apresentadas as métricas elaboradas para se avaliar a qualidade de documentos de requisitos orientados a aspectos.
4. Métricas para Avaliar Documentos de Requisitos Orientados a
Aspectos
A medição de software se ocupa em obter um valor numérico para alguns atributos de um produto ou um processo de software. Comparando esses valores uns com outros e com os padrões que se aplicam em uma organização, é possível tirar conclusões sobre a qualidade do software ou dos processos de software [29].
As métricas apresentadas nesse artigo são consideradas quantitativas (preditivas). Essas métricas são associadas a um produto de software (neste caso o documento de requisitos). Alguns exemplos desse tipo de métricas são: a medida da complexidade ciclomática de um módulo, o comprimento médio de identificadores em um programa, número de atributos e operações associadas com objetos em um projeto entre outras.
Um conjunto de atributos e alguns fatores são sugeridos por [29], para a elaboração de um conjunto de métricas, essas devem ser:
Simples e computáveis: Deve ser relativamente fácil aprender como originar
as métricas e seu cálculo não deve exigir esforço ou tempo exagerado.
Empíricas e intuitivamente persuasivas: A métrica deve satisfazer as noções
intuitivas do engenheiro sobre o atributo do produto que está sendo considerado.
Consistentes e objetivas: a métrica deve produzir sempre resultados que não
são ambíguos. Um terceirizado deve poder originar o mesmo valor para a métrica usando a mesma informação sobre o software.
Consistentes no uso de unidades e dimensões: O cálculo matemático da
métrica deve usar medidas que não levam a combinações de unidades bizarras. Por exemplo, multiplicar pessoas na equipe de projeto por variáveis da linguagem de programação do programa resulta numa mistura suspeita de unidades que não são intuitivamente convincentes.
Independente da linguagem de programação: Métricas devem ser baseadas
no modelo de análise, modelo de projeto e na estrutura propriamente dita do programa. Elas não devem estar dependentes das excentricidades da sintaxe ou da semântica de linguagens de programação.
Mecanismo efetivo para realimentação de alta qualidade: Isto é, a métrica
deve fornecer ao engenheiro de software informações que pode levar a um produto final de alta qualidade.
Fig. 2 - Diretrizes para Instanciação de Métricas Abstratas.
As métricas são divididas em três subconjuntos de métricas (Fig. 3): i) separação de interesses (M1); ii) tamanho (M2); e, iii) acoplamento (M3).
Fig. 3 – Métricas Abstratas.
O primeiro conjunto de métricas M1, verifica o quão separado está um determinado interesse, ou seja, em quantos módulos estão especificados um determinado interesse e quantos passos foram necessários para descrever esse interesse. Esse primeiro tipo de métrica terá um valor para cada interesse, por exemplo: “Utilizando as métricas de separação de interesses foi possível verificar que o interesse de Segurança foi modularizado por 7 (sete) casos de uso aspectuais e descrito em 78 (setenta e oito) passos”.
O segundo conjunto de métricas são relacionadas ao tamanho de cada módulo, indicando fatores como o número de passos, passos condicionais e exceções. Essas métricas terão um valor único para cada módulo, por exemplo: “Utilizando as métricas de tamanho foi possível verificar que o caso de uso aspectual Limitar Valor da Movimentação contém 2 (dois) passos e 0 (zero) exceções e passos condicionais”. Diretrizes
1. identificar qual a estrutura (módulo de decomposição) utilizada para especificar um aspecto ou interesse;
1.1. na estrutura, identificar como esta é composta, se existem passos, sub estruturas, exceções, desvios ou condições;
2. identificar como é o mecanismo de combinação entre os módulos que se entrecortam; 2.1. no mecanismo, identificar como este é composto, se existem passos, sub mecanismos, estruturas, exceções, desvios ou condições;
3. identificar outros relacionamentos que podem haver entre as estruturas; 3.1. no relacionamento, identificar o seu tipo.
M1 - Separação de interesses:
Número de módulos que especificam um determinado interesse; Número de passos que compõem esses módulos
M2 - Tamanho:
Número de passos nas descrições de cada módulo independente; Número de passos condicionais de cada módulo independente; Número de exceções de cada módulo independente.
M3 - Acoplamento:
Número de módulos que são incluídos ou estendidos em outros módulos; Número de módulos que são entrecortados por um determinado módulo. Legenda:
Módulo: qualquer estrutura que encapsula uma funcionalidade (ou parte dela), por exemplo: um caso de uso, um agente, um papel, uma classe, um caso de uso aspectual, um aspecto entre outros.
Interesse: representa funcionalidade e restrições de um sistema, podendo ser tanto um requisito funcional como um não-funcional, por exemplo: segurança, persistência, interface, tratamento de erros, cadastro de cliente, emissão de pedidos entre outros.
Aspecto: uma estrutura que encapsula um interesse (ou parte deste).
O terceiro conjunto de métricas relacionadas com o acoplamento verifica a quantidade de relacionamentos tanto de entrecorte quanto de extensão e inclusão existentes em cada módulo.
Baseando-se nos processos de medição descritos em [19, 29], foi elaborado um processo que pode ser uma alternativa de como realizar a aplicação do conjunto de métricas abstratas em um documento de requisitos orientado a aspectos, Figura 4. São basicamente três etapas:
1 - Instanciação das métricas abstratas: tem como entrada as métricas abstratas, as diretrizes e um documento de requisitos orientado a aspectos. A saída dessa primeira etapa é um conjunto de métricas instanciadas para medir o documento de requisitos.
2 - Aplicação das métricas: tem como entrada o documento de requisitos e as métricas já instanciadas para esse documento. A saída dessa etapa é um conjunto de dados coletados a partir da aplicação das métricas.
3 - Análise dos dados coletados: tem como entrada o resultado dos dados obtidos a partir da aplicação das métricas e outros dados que podem ser desde estatísticas obtidas de outras aplicações de métricas como a própria experiência do engenheiro de software. A saída dessa ultima fase serão dados que auxiliarão o engenheiro de software na tomada de decisões e possíveis alterações no documento de requisitos avaliado.
Fig. 4 - Um processo de utilização das métricas abstratas.
A Seção seguinte apresenta um estudo de caso em que as diretrizes auxiliam a instanciar as métricas abstratas para que seja realizada a medição de documento de requisitos orientado a aspectos.
5. Estudo de Caso
Existem duas técnicas básicas para avaliar uma abordagem: experimentos e estudos de caso. A realização de experimentos provê uma maneira de avaliação baseada em comparação direta, permitindo a pesquisadores investigar qual o impacto da tecnologia no processo de maneira detalhada [30]. Já a realização de estudos de caso
está mais preocupada em avaliar os benefícios de uma abordagem de forma a verificar se as mudanças no processo proporcionam o resultado desejado [15]. A técnica escolhida para ser utilizada neste trabalho foi o estudo de caso, por se pretender avaliar o comportamento das métricas em um documento de requisitos orientado a aspectos.
O documento de requisitos orientados a aspectos que foi utilizado no estudo de caso trata de um sistema bancário via web, denominado Internet Banking (tem as funções básicas para realizar transações financeiras e bancárias). Esse documento foi elaborado utilizando a abordagem de Sousa [28], que foi especificado utilizando tabelas, para detalhar os relacionamentos de entrecorte, e casos de uso que contêm uma nova unidade modular que Sousa chamou de caso de uso aspectual. Esse trabalho é melhor detalhado na Seção 2.
Para ter alguma garantia que a aplicação das métricas foi efetuada corretamente, o engenheiro de software deverá estabelecer os objetivos da medição antes que a coleta de dados tenha início, definindo cada métrica de modo não ambíguo [19].
O estudo de caso foi realizado seguindo o processo de medição mostrado na Figura 4, porém a última etapa, de Análise dos dados coletados, não é relatada nesse artigo, assim este estudo ficou dividido em duas etapas que são apresentadas nas subseções seguintes.
5.1 Instanciação das Métricas Abstratas
Seguindo as diretrizes apresentadas na Seção anterior, Fig. 2, foram encontrados os seguintes itens mensuráveis no documento de requisitos:
1 - As unidades modulares utilizadas são: casos de uso e casos de uso aspectuais. 1.1 - Cada caso de uso (também os aspectuais) são compostos por passos. 2 - Os mecanismos de composição são especificados por tabelas.
2.1 - Cada tabela contém linhas que identificam os casos de uso afetados por um determinado caso de uso aspectual.
3 - Os relacionamentos existentes entre os casos de uso são os mesmos existentes em um diagrama de caso de uso habitual com a adição do relacionamento dos casos de uso aspectuais.
3.1 - Os relacionamentos podem ser de extensão (extend), inclusão (include) e entrecortes (crosscuts).
Após identificar os itens que compõem a abordagem utilizada no documento de requisitos, o engenheiro de software deve instanciar os itens mensuráveis de acordo com as métricas abstratas, Figura 3. A seguir é mostrado como ficou os três conjuntos de métricas após a instanciação.
M1 - Separação de interesses:
M1a - Número de casos de uso (aspectual ou não) que modelam um determinado interesse;
M1b - Número de passos nas descrições dos casos de uso (aspectual ou não) que descrevem um determinado interesse.
M2 - Tamanho:
M2b - Número de passos condicionais de cada caso de uso (aspectual ou não);
M2c - Número de exceções de cada caso de uso (aspectual ou não). M3 - Acoplamento:
M3a - Número de casos de uso (aspectual ou não) que são incluídos ou estendidos em um determinado caso de uso aspectual;
M3b - Número de casos de uso (aspectual ou não) que são entrecortados por um determinado caso de uso aspectual.
5.2. Aplicação das Métricas
Após instanciar as métricas, o engenheiro deverá realizar a coleta dos dados a partir da medição dos itens especificados por cada métrica. No caso desse estudo os dados foram coletados manualmente, percorrendo todo o documento de requisitos. Ou seja, para cada métrica foi percorrido o documento por completo e contabilizado (somado todas as ocorrências) o item que estava sendo especificado na métrica.
Para coletar dados com a aplicação da métrica M1a, que tem a finalidade de medir o grau de separação de um Interesse, deve-se primeiramente selecionar um interesse (no caso do sistema de Internet Banking existe um interesse todo modularizado e especificado por aspectos), por exemplo, o interesse de Segurança. Deve-se localizar no documento de requisitos todos os casos de uso aspectuais que implementam esse interesse, neste caso foram encontrados os casos de uso aspectuais: Gravar informações Transação, Cobrar Tarifa por Transação Extra, Checar Senha Internet Banking, Checar Dados Pessoais do Cliente, Registrar CPMF, Limitar Valor da Movimentação (Tabela 2), Oferecer Bonificação. Ou seja, o valor obtido com a aplicação da métrica M1a é 7 (sete).
A Tabela 2, mostra o caso de uso aspectual “Limitar Valor da Movimentação”e seus 2 (dois) passos, para a aplicação da métrica M1b deverão ser contados todos os passos de todos os casos de uso encontrados para o interesse de Segurança. Para a métrica M1b o valor obtido é 78 (setenta e oito), ou seja, essa é soma de todos passos dos casos de uso aspectuais que especificam o interesse de Segurança.
Tabela 2. Especificação do caso de uso aspectual Limitar Valor de Movimentação.
OPERACIONALIZACAO #03: Limitar valor de movimentação
INFORMAÇÕES CARACTERÍSTICAS
Objetivo Verificar limite do valor de transações financeiras para diminuir riscos de fraudes. Pré-condições Valor da transação é dado como entrada.
Ator Primário Cliente do banco, titular da conta. CENÁRIO PRINCIPAL DE SUCESSO
Passo Ação
1 O sistema verifica se o valor da transação supera limite. 2 O sistema retorna o resultado da verificação
“Limitar Valor da Movimentação”, Tabela 2, o valor da métrica M2a é 2 (dois), o valor da M2b é 0 (zero) e da métrica M2c é 0 (zero).
Tabela 3- Tabela de composição Limitar Valor de Movimentação.
REQUISITO ASPECTUAL: AR #07 LIMITAR VALOR DE MOVIMENTAÇÃO
Caso de uso Afetado Condição (Opcional) Regra de Composição Ponto de Junção Informações Adicionais UC #04 Realizar transferência
- Wrap 3 Se limiteOk então execute(pto junção) Senão exibe(msgErro)
UC #05 Pagar boleto bancário
- Wrap 4 Se limiteOk então execute(pto junção) Senão exibe(msgErro)
UC #06 Emitir comprovante
- Wrap 3 Se limiteOk então execute(pto junção) Senão exibe(msgErro)
Selecionando o mesmo caso de uso aspectual “Limitar Valor da Movimentação”, Tabela 2, e aplicando a métrica M3a obtém-se o valor 0 (zero). A coleta dos dados da aplicação da métrica M3b é basicamente obtido pela observação das Tabelas de composição, por exemplo a tabela “Limitar Valor de Movimentação”, Tabela 3, pode-se obter a informação que o caso de uso aspectual “Limitar Valor de Movimentação” entrecorta os casos de uso: realizar transferência, pagar boleto bancário e emitir boleto bancário, ou seja, o valor da M3b para o caso de aspectual “Limitar Valor de Movimentação” é 3 (três). Esses relacionamentos de entrecorte podem ser também observados no diagrama de casos de uso, Fig. 1.
Após a aplicação das métricas os dados coletados deverão ser analisados e interpretados para ganhar profundidade na visão de qualidade do software e os resultados dessa interpretação poderá levar a modificações do documento de requisitos.
Utilizando como base os fatores de qualidade que podem ser medidos (diretamente) segundo McCall [16], as métricas apresentadas nesse estudo de caso auxiliarão o engenheiro a avaliar o documento de requisitos segundo os fatores de:
- Utilização: Esforço necessário para entender, operar, interpretar e aprender um documento.
- Mantenabilidade: O esforço necessário para localizar e consertar um erro. - Flexibilidade: O esforço necessário para modificar um documento.
- Reutilização: Quanto um documento (ou parte dele) pode ser reusado em outros projetos, sistemas, aplicações, etc. Relativo ao empacotamento e escopo das funções que o sistema realiza
A Seção seguinte relata algumas considerações feitas sobre as métricas e o estudo de caso apresentado.
6. Considerações Finais
Este artigo apresentou um conjunto de métricas abstratas, que com o auxílio de diretrizes, podem ser instanciadas para medir um documento de requisitos orientado a aspectos em relação a separação de interesses, tamanho e acoplamento, sendo que esse documento pode ter sido elaborado por uma abordagem qualquer.
deverá auxiliar decisões em projetos futuros que foram implementados utilizando os conceitos do desenvolvimento orientado a aspectos. Com a aplicação das métricas em vários documentos de requisitos será possível inferir qual seria um bom grau de separação de um determinado interesse.
Com a utilização de métricas abstratas, a aplicação dessas pode ser feita em qualquer tipo de documento de requisitos orientados a aspectos, independente da abordagem que foi seguida para sua criação. Isso facilita a adoção das métricas, pois, como a orientação a aspectos está em um estágio inicial, principalmente na fase de requisitos, a todo momento estão surgindo novas abordagens de como elaborar um documento de requisitos orientado a aspectos, além das várias já existentes.
Engenheiros de software devem adaptar as métricas ao ambiente de seu projeto de software, inserindo padronizações, como por exemplo, somente medir módulos aspectuais, ou então coletar os dados por módulos. Técnicas estatísticas válidas devem ser aplicadas para se estabelecer relações, como por exemplo o nível de complexidade. Cálculos que melhor expressem os dados coletados devem ser definidos, como por exemplo mostrar a média de uma determinada métrica.
As métricas apresentadas nesse artigo são o ponto de partida para se garantir a qualidade de documentos de requisitos especificados com base na orientação a aspectos. Porém deve-se levar em conta outros fatores para que haja sucesso em uma atividade métrica, como a condução da coleta dos dados e sua análise. Outro ponto que se deve estar ciente é que essa atividade de medição esta intimamente ligada ao apoio gerencial. Financiamento, treinamento e promoção devem ser considerados, se um programa de medição técnica deve ser estabelecido e sustentado.
Como trabalhos futuros novas avaliações deverão ser realizadas em outros documentos de requisitos orientados a aspectos elaborados por outras metodologias, para que deste modo seja possível validar a aplicabilidade das métricas abstratas.
Novas diretrizes deverão ser elaboradas para permitirem instanciar as métricas para qualquer fase do desenvolvimento de software e não somente na fase de requisitos.
Uma ferramenta que implemente as métricas e faça a coleta dos dados de forma, no mínimo semi-automática deverá ser elabora, para que assim agilize o processo de aplicação das métricas.
Agradecimentos
Este trabalho contou com o apoio de vários projetos de pesquisa (CNPq 304982/2002-4, CAPES BEX 1775/2005-7, CAPES BEX 3003/05-1 e CAPES/ GRICES 129/05).
Referências Bibliográficas
1. Albrecht, P. F. et al. “Reliability test system” IEEE trans. on Pas., Vol. Pas-98, No.6 , p. 2047-2054. Nov./Dec.1979.
2. Araújo, J.; Whittle, J.; Kim, D. "Modeling and Composing Scenario-Based Requirements with Aspects". In: The 12th Requirements Engineering Conference , Kyoto, Japan, September 2004. 3. Aksit, M.; Tekinerdogan, B. and Bergmans, L. "The Six Concerns for Separation of Concerns", In:
Workshop on Advanced Separation of Concerns, Budapest, Hungary, June 18-22, 2001.
5. Czarnecki, K.; Eisenecker, U. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000.
6. Durán, A.; Cortés, A. R.; Corchuelo, R.; Toro, M. “Supporting Requirements Verification Using XSLT ”.Requirements Engineering Conference - RE 2002 – Essen, Alemanha, Setembro 2002. 7. Elrad, T., Filman, R. and Bader, A. “Aspect-Oriented Programming: Introduction”, Communications
of the ACM, v.44 n.10, p.29-32, Oct. 2001.
8. Elrad, T.; Aksit, M.; Kiczales, G.; Lieberherr, K. and Ossher, H. “Discussing Aspects of AOP”. Communications of the ACM, 44(10):33–38, October 2001.
9. Hannemann, J.; Kiczales, G. “Overcoming the Prevalent Decomposition in Legacy Code”. In: Workshop on Advanced Separation of Concerns, Toronto, Canada, Maio 2001.
10. ISO 9126, “Tecnologia da Informação – Qualidade de Produto – Parte 1: Modelo de Qualidade”, International Standard ISO/IEC 9126, International Standard Organization, Junho, 2001.
11. Jacobson, I; Chriterson, M; Jonsson, P. and Overgaard, G. "Object-Oriented Software Engineering: A Use Case Driven Approach". Addison Wesley, 1992.
12. Jacobson, I.; Booch, G.; and Rumbaugh, J. “The Unified Software Development Process”, Addison-Wesley, 1999.
13. Kiczales, G.; Lamping, J.; Mendhekar, A. RG: A Case-Study for Aspect-Oriented Programming. In: SPL97. Palo Alto Research Center, Technical Report, 1997.
14. Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J. and Griswold, W. “An Overview of AspectJ”. In: 15th European Conference on Object-Oriented Programming, Berlin, Heidelberg, Springer Verlag, 2001.
15. Kitchenham, B.; Pickard, L. and Pfleeger, S. “Case Studies for Method and Tool Evaluation” . IEEE, 1994.
16. McCall, J.; Richards, P.; Walters, G. “Factors in software quality”, Technical Report, Vols. 1--3, Rome Air Development Center, United States Air Force, Hanscom AFB, Springfield, VA. 1977. 17. Moreira, A.; Araújo, J. and Brito, I. “Crosscutting Quality Attributes for Requirements Engineering”,
SEKE 2002, ACM Press, Italy, July, 2002.
18. Pawlak, R., Duchien, L., Florin G., Legong-Aubry, F., Seinturier, L, Martelli, L. A UML Notation for Aspect-Oriented Software Design. In: Workshop of Aspect Oriented Modeling with UML of Proceedings of Aspect Oriented Software Development Conference , Enschede, Abril, 2002. 19. Pressman, R. Engenharia de Software. Makron Books, 5ª edição, 2002.
20. Ramos, R. A.; Penteado, R.; Masiero, P. C.; - “Um Processo de Reestruturação de Código Baseado em Aspectos” - SBES’2004 - Brasília/DF. Outubro, 2004.
21. Ramos, R. A, Castro, J. F. B. “Avaliação de uma Metodologia de Medição da Qualidade em um Documento de Requisitos Orientado a Aspectos”. In: WER, Porto- Portugal, 2005.
22. Rashid, A.; Sawyer, P.; Moreira, A. and Araújo, J. “Early Aspects. A Model for Aspect-Oriented Requirements Engineering”. Conference on Requirements Engineering, Essen, Germany, 2002. 23. Rashid, A.; Moreira, A. and Araújo, J. “Modularisation and Composition of Aspectual
Requirements”. In: 2nd International Conference on Aspect-Oriented Software Development, 2003. 24. Reis, T., P., C. “Uma Metodologia para Medição da Qualidade de Aplicações Web na Fase de
Requisitos”. Dissertação – Programa de Pós-Graduação em Ciência da Computação, UFPE, Recife – Pernambuco, 2004, 163f.
25. Sant’Anna, C.; Garcia, A.; Chavez, C.; Lucena C.; Staa A. On Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. In: SBES’2003, Manaus/Amazonas. Outubro, 2003. 26. Sant’Anna, C.; Garcia, A.; Chavez, C.; Lucena C.; Staa A. “Design Patterns as Aspects: A
Quantitative Assessment”. In: SBES’2004, Brasilia - DF, 2004.
27. Silva, L.; Leite, J. “Uma linguagem de modelagem de requisitos orientada a aspectos”, Proceedings of the Requirement Engineering Workshop at CAiSE 2005, Porto-Portugal, 2005.
28. Sousa, G. “Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento de Software Orientado a Aspectos”. Dissertação – Programa de Pós-Graduação em Ciência da Computação, UFPE, Recife – Pernambuco, maio 2004, 180f.
29. Summerville, I. “Engenharia de Software”. Addison- Wesley, 2003.
30. Travassos, G.; Gurov, D. and Amaral, E. “Introdução à Engenharia de Software Experimental”. Relatório Técnico, RT-ES-590/02, Rio de Janeiro, 2002.
31. Whitte, J.; Araújo, J. “Scenario modelling with aspects”. In: IEE Proceedings online no. 20040921, Vol. 151, No. 4, Agosto 2004.
