Avaliao 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
Centro de Informtica 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 ITC- Istituto Trentino di Cultura IRST -Instituto per la Ricerca Scientifica e Tecnologica, Trento-Povo, Italy jaelson@itc.it
3 2 1

Departamento de Eletrnica e Sistemas Universidade Federal de Pernambuco UFPE Av. Prof. Luiz Freire s/n, Recife PE, Brasil 50732-970, +55 81 2126 8995 fmra@ufpe.br

Grupo de Tecnologias da Informao em Sade (TIS) Ncleo de Tele-Sade NUTES Hospital das Clnicas, Av. Prof. Moraes Rego, s/n, Cidade Universitria, Recife-PE, Brasil 50.670-420, telefone: +55 81 2126-3903. ricardo.afonso@nutes.ufpe.br

Resumo. Pesquisas promissoras na fase de requisitos utilizando a orientao a aspectos tm como propsito a utilizao de tcnicas que possibilitam separar e, posteriormente, compor os interesses que esto espalhados e entrelaados no documento de requisitos. Novos fatores que surgem nesses documentos de requisito, tais como a separao de interesses, o tamanho e o acoplamento ainda no so avaliados qualitativamente, por falta de mtricas. Este artigo apresenta um conjunto de mtricas abstratas, que com o auxlio de diretrizes, podem ser instanciadas para medir um documento de requisitos orientado a aspectos que foi elaborado segundo qualquer abordagem. Alm disso, proposto um processo de medio.

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.

Atualmente afastado da UFPE

1 Introduo
O uso inadequado de processos de desenvolvimento de software gera grandes custos nas fases de manuteno deste software em desenvolvimento. do conhecimento geral [19], que o custo da correo de erros j na fase de projeto cerca de trs a seis vezes mais alto do que na fase de definio de requisitos. Todavia, esse custo aumenta ainda mais quando a correo de erros realizada em fases mais avanadas no processo de desenvolvimento. O desenvolvimento de software orientado a aspectos (Aspect Oriented Software Development AOSD) surge como uma opo para que engenheiros de software organizem melhor todas as fases de desenvolvimento, desde os documentos de requisitos at a implementao e testes de softwares [4, 11, 26]. Por ser uma linha de pesquisa ainda em evoluo, a maioria dos esforos iniciais tm sido concentrados na fase da implementao como uma soluo para aumentar a facilidade de entendimento e, conseqentemente, facilitar a manuteno e evoluo desse software. Por esse motivo, na fase de implementao, possvel encontrar tanto tcnicas de modelagem [18] e reengenharia [20] como ferramentas [9] que minimizam os esforos de engenheiros de software que trabalham com o AOSD nessa fase. Por outro lado, a utilizao do conceito de separao de interesses [5] e orientao a aspectos [13], j na fase de requisitos, permite uma melhor organizao do documento de requisitos. Nessa nova viso, os requisitos que entrecortam outros requisitos [22] e os que so volteis (suscetveis a mudanas) [31] so identificados e modularizados como aspectos. Em um primeiro momento os termos interesses entrecortantes (do ingls crosscutting concerns) foram utilizados para classificar requisitos no funcionais que entrecortavam outros requisitos (funcionais ou no). Dessa forma, somente poderia ser considerado um aspecto algum requisito no funcional. Em trabalhos recentes [31] o termo interesse utilizado para classificar qualquer tipo de requisito (funcional ou no-funcional). Quando um desses interesses entrecorta outros interesses ou quando o interesse voltil, esse considerado um candidato a aspecto. Contudo, apesar das provveis facilidades que o AOSD sugere para a fase de requisitos, ainda no existe preocupao em se desenvolver trabalhos que avaliem qualitativamente um documento de requisitos orientado a aspectos. SantaAna e outros [25, 26] avaliam qualitativamente e quantitativamente os benefcios de implementaes de padres de projeto em sistemas orientados a aspectos e orientados a objetos. No sendo avaliados, porm, os documentos de requisitos. No contexto de mtricas que auxiliem o engenheiro de software a avaliar a qualidade de documentos de requisitos orientados a aspectos, Ramos [21] elabora um conjunto de mtricas para medir a qualidade dos aspectos especificados em uma abordagem orientada a casos de uso aspectuais. Nessa mesma linha, este artigo prope um conjunto de mtricas abstratas que podem ser instanciadas, com o auxilio de diretrizes em um documento de requisitos com aspectos, bem como um processo de medio. As mtricas sero utilizadas em abordagens diferentes de engenharia de requisitos com aspectos. Para ilustrar apresentado um estudo de caso. Na Seo 2 esto sendo relatados alguns trabalhos na rea da orientao a aspectos na fase de requisitos, na Seo 3 so apresentadas mtricas para a avaliao da qualidade de aspectos em documentos de requisitos, na Seo 4 so apresentadas

as mtricas para avaliar documentos de requisitos orientados a aspectos, na Seo 5 descrito como foi realizado o estudo de caso. As consideraes finais so apresentadas na Seo 6.

2. Orientao 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 princpio da separao de interesses. Linguagens de programao geralmente fornecem construtores para organizar um sistema em unidades modulares que representam os interesses funcionais da aplicao. Essas unidades so expressas como objetos, mdulos ou procedimentos. A maioria dos softwares consiste em um conjunto de interesses que se entrecortam em vrios mdulos diferentes. Como conseqncia da no modularizao desses interesses, a implementao resulta em softwares de complexo entendimento e, conseqentemente, de difcil manuteno [19, 29]. A separao destes interesses de fundamental importncia para que artefatos dos vrios estgios do desenvolvimento do software sejam legveis e sejam facilmente manutenveis. Esse princpio 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 tcnicas de programao capazes de cobrir a separao de interesses de um sistema, em cdigo, foi estudado e implementado um novo paradigma de programao, a Programao Orientada a Aspectos POA [13]. A POA traz uma nova unidade modular chamada aspecto, que encapsula comportamentos que interferem (entrecortam) em mltiplas classes. Trabalhos iniciais com POA foram desenvolvidos maciamente para solucionar problemas que ocorrem em nvel de cdigo [7, 8, 13, 20]. Somente mais recentemente alguns pesquisadores comearam a trazer os benefcios da orientao 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 especificao de requisitos, chamados requisitos aspectuais. As primeiras investigaes realizadas foram sobre a relao entre atributos de qualidade e interesses que se encontram espalhados e repetidos na especificao de requisitos [17, 22]. Uma das primeiras abordagens que surgiram na rea, propunha um modelo genrico para engenharia de requisitos orientada a aspectos, e foi chamada de AORE (Aspect-Oriented Requirements Engineering) [22]. O modelo trata propriedades no-funcionais como interesses do sistema e separa-os das propriedades funcionais, atravs de uma srie de passos bem definidos. Tendo como base, o modelo AORE, Rashid e outros [23] utilizam a tcnica de pontos de vista para especificar requisitos e XML [32] para defini-los. Tambm usando XML, essa abordagem separa as regras de composio dos aspectos e dos pontos de vistas promovendo, assim, o reuso e a maior facilidade na identificao e no gerenciamento dos conflitos.

Arajo e outros [2] propem o uso de aspectos concentrado na especificao de requisitos baseado em cenrios. Nesse processo, primeiramente, os casos de uso so mapeados em um conjunto de cenrios que, posteriormente, so separados em aspectuais e no-aspectuais. Os aspectuais so representados utilizando especificao de padres de interaes (Interaction Patterns Specifications) e os no-aspectuais como diagramas de casos de uso. No passo seguinte, cada cenrio traduzido para uma mquina de estados correspondente e combinados para formao de um conjunto de mquinas de estados que representam os requisitos de modo geral Ainda no foco de trabalhos sobre requisitos orientados a aspectos, Silva e outros [27] propem o uso de modelo de metas V-graph para modelar aspectos e requisitos. A proposta possui basicamente trs fases: Separao, Composio e Visualizao. A separao consiste na modelagem dos requisitos identificando algumas restries. A composio funciona de forma semelhante ao combinador (weaver) das linguagens de programao orientadas a aspectos, interpretando as restries transversais e gerando um modelo nico com todas as informaes. A ltima fase trata da gerao de diferentes vises do modelo integrado. Assim, o modelo garante aos desenvolvedores uma ampla visualizao das influncias exercidas pelos requisitos em toda a estrutura do sistema. Utilizando como base o processo de desenvolvimento unificado [12], Sousa [28] realiza uma adaptao desse processo para o desenvolvimento orientado a aspectos, onde o principal foco desta pesquisa o desenvolvimento guiado por casos de uso [11], possibilitando a separao de interesses transversais nas fases de requisitos, anlise e projeto utilizando fundamentos da orientao a aspectos. Nesse processo as unidades bases (que podem ser afetadas por aspectos) correspondem s unidades de decomposio comumente utilizadas em cada um dos fluxo de atividades do processo unificado, por exemplo: casos de uso no fluxo de requisitos; classes de anlise no fluxo de anlise; e classes de projeto no fluxo de projeto. Sendo que os possveis pontos de juno referem-se a elementos nessas unidades que representam pontos de execuo: no fluxo de requisitos pode-se especific-los em funo dos eventos (ou passos) nos cenrios de um caso de uso; no de anlise, em termos de mensagens trocadas entre objetos de anlise; e no de projeto, em termos de operaes de classes. Partindo do princpio de que aspectos so encapsulados nas mesmas unidades de decomposio 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 anlise 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 composio armazena para cada aspecto identificado e em cada fluxo, informaes relativas composio entre um aspecto e a(s) unidade(s) que ele afeta. A Fig.1 apresenta o exemplo de um diagrama (parcial) de casos de uso elaborado pela abordagem de Sousa[28], nesse diagrama possvel observar alguns casos de uso aspectuais (representados por losangos) que especificam o interesse de segurana. O relacionamento que indica que um caso de uso aspectual entrecorta um caso de uso (normal) nomeado como <<crosscuts>> e representado por uma seta com linhas tracejadas.

<<crosscuts>> Realizar Transao Bancria <<crosscuts>> <<crosscuts>> Cobrar Tarifa por Transao Extra Realizar Checar Senha Transao de Internet Banking Consulta Limitar Valor da Movimentao

Cliente

Realizar Transao Financeira

Emitir Comprovante

Pagar Boleto Realizar Bancrio Transferncia Legenda Requisitos Aspectuais

Visualizar Saldo da Conta

Visualizar Extrato da Conta

Fig. 1. Diagrama (parcial) de casos de uso de um sistema de banco pela Internet.

A principal contribuio das propostas de se usar aspectos nas fases inicias do processo de desenvolvimento a ajuda na identificao de conflitos entre os requisitos, para que medidas sejam tomadas o quanto antes, onde o custo muito menor do que em fases posteriores. Alm, de promover uma melhor legibilidade e manutenibilidade dos artefatos produzidos nos vrios estgios do desenvolvimento. [22] A Seo seguinte apresenta alguns trabalhos que utilizam mtricas para avaliar a qualidade na fase de requisitos.

3. Metodologias e Mtricas para Avaliao da Qualidade de Requisitos

A comunidade de engenharia de software vem adaptando padres existentes como a ISO 9126 [10] para que desta maneira se permita fornecer suporte para que haja conformidade e assim possibilitando elaborar mtricas para medir a qualidade de um produto de software [19, 29]. A medio 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 so muitas as vantagens de se poder medir a qualidade e corrigir seus erros, inconsistncias e saber sua completitude, porm quanto mais cedo nas fases de desenvolvimento do software for descoberto os erros, menos custoso o seu processo de correo [19]. Por esse motivo a medio 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 Anlise Verificao Validao Objetivo Principal Identifica conflitos em requisitos. Detecta defeitos em requisitos. Certifica que os requisitos so consistentes com as intenes dos clientes e usurios.

As atividades que asseguram a qualidade em documentos de requisitos so divididas em trs, como sumarizadas na Tabela 1 [6]. A medio quantitativa dos requisitos de um sistema utilizada como meio de medir o tamanho do produto de software, por derivao, esforo, tempo e custo necessrio para implement-lo. Uma tcnica bastante utilizada para esse fim a analise de pontos de funo, que foi introduzida por Allan Albrecht [1]. A proposta de Albrecht que o software deveria ter o seu tamanho medido a partir das funes implementadas para o usurio, examinadas sob a tica do usurio. [1] A maioria dos mtodos utilizados para avaliao de qualidade (mtricas) de artefatos de software no levam em considerao o princpio da engenharia de software de que o custo para modificar um requisito na fase de manuteno chega a ser cinqenta vezes maior do que na fase de definio de requisitos [19, 29]. Portanto, a medio da qualidade na fase de requisitos uma estratgia importante para reduzir os custos de manuteno [19, 29]. Alm de trazer esses benefcios, a obteno de mtricas na fase de requisitos possibilita tambm o respaldo de estudos estatsticos que viabilizem a melhoria do processo de engenharia de requisitos e do software em si. Durn [6] prope uma ferramenta denominada REM (REquirements Manager - Gerenciador de Requisitos), que d apoio a verificao de requisitos que esto armazenados em XML [32]. Em seu trabalho so elaboradas heursticas que tratam de alguns problemas recorrentes em documentos de requisitos, tais como: ambigidade, completitude, rastreabilidade. A ferramenta REM tambm d apoio a verificao de casos de uso, desta maneira foram elaboradas algumas mtricas para verificar a qualidade em casos de uso. As mtricas elaboradas no trabalho de Durn [6] medem fatores de complexidade em caso de uso como o nmero de passos de um caso de uso, passos condicionais, excees e o nmero de vezes que um caso de uso includo ou estendido em outros casos de uso. Algumas mtricas como a relatada anteriormente apenas fornecem mecanismos para se medir o tamanho, ou a complexidade, no fornecendo mecanismos para indicar se esse ou aquele valor obtido est bom ou ruim. Porm, existem mtricas que auxiliam o engenheiro de software a fazer uma avaliao 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 prope a avaliao da qualidade de aplicaes web na fase de requisitos atravs da medio de atributos de qualidade, tendo assim como benefcio possibilidade de descobrir erros de uma forma antecipada. A aplicao da metodologia REQE consiste em cinco fases: i) Representao das caractersticas, ii) Subcaractersticas e atributos de qualidades, iii) Especificao descritiva da rvore de caracterstica, subcaractersticas e atributos de qualidade, iv) Associao de pesos aos ns, Associao de escores aos atributos de qualidade e v) Clculo geral. Com a utilizao de pesos e escores, a metodologia de Reis [24] produz um nmero (resultado do clculo geral), que utilizados de parmetro para que o engenheiro compare com outros valores e assim consiga avaliar a completitude do sistema que foi avaliado.

Na Seo seguinte so apresentadas as mtricas elaboradas para se avaliar a qualidade de documentos de requisitos orientados a aspectos.

4. Mtricas para Avaliar Documentos de Requisitos Orientados a Aspectos

A medio de software se ocupa em obter um valor numrico para alguns atributos de um produto ou um processo de software. Comparando esses valores uns com outros e com os padres que se aplicam em uma organizao, possvel tirar concluses sobre a qualidade do software ou dos processos de software [29]. As mtricas apresentadas nesse artigo so consideradas quantitativas (preditivas). Essas mtricas so associadas a um produto de software (neste caso o documento de requisitos). Alguns exemplos desse tipo de mtricas so: a medida da complexidade ciclomtica de um mdulo, o comprimento mdio de identificadores em um programa, nmero de atributos e operaes associadas com objetos em um projeto entre outras. Um conjunto de atributos e alguns fatores so sugeridos por [29], para a elaborao de um conjunto de mtricas, essas devem ser: Simples e computveis: Deve ser relativamente fcil aprender como originar as mtricas e seu clculo no deve exigir esforo ou tempo exagerado. Empricas e intuitivamente persuasivas: A mtrica deve satisfazer as noes intuitivas do engenheiro sobre o atributo do produto que est sendo considerado. Consistentes e objetivas: a mtrica deve produzir sempre resultados que no so ambguos. Um terceirizado deve poder originar o mesmo valor para a mtrica usando a mesma informao sobre o software. Consistentes no uso de unidades e dimenses: O clculo matemtico da mtrica deve usar medidas que no levam a combinaes de unidades bizarras. Por exemplo, multiplicar pessoas na equipe de projeto por variveis da linguagem de programao do programa resulta numa mistura suspeita de unidades que no so intuitivamente convincentes. Independente da linguagem de programao: Mtricas devem ser baseadas no modelo de anlise, modelo de projeto e na estrutura propriamente dita do programa. Elas no devem estar dependentes das excentricidades da sintaxe ou da semntica de linguagens de programao. Mecanismo efetivo para realimentao de alta qualidade: Isto , a mtrica deve fornecer ao engenheiro de software informaes que pode levar a um produto final de alta qualidade. As mtricas apresentadas nesse artigo focam na medio de documentos de requisitos orientados a aspectos em termos de separao de interesses, acoplamento e tamanho. Essas mtricas so abstratas e devem ser instanciadas de acordo com a metodologia seguida no documento de requisitos, por exemplo, na metodologia apresentada por Sousa [28], os aspectos so especificados por casos de uso. Portando as mtricas devem ser instanciadas para medir os mdulos (casos de uso) dessa metodologia. Diretrizes que ajudam o engenheiro de software a instanciar as mtricas abstratas para um sistema especfico so dadas, Fig. 2.

Diretrizes 1. identificar qual a estrutura (mdulo de decomposio) utilizada para especificar um aspecto ou interesse; 1.1. na estrutura, identificar como esta composta, se existem passos, sub estruturas, excees, desvios ou condies; 2. identificar como o mecanismo de combinao entre os mdulos que se entrecortam; 2.1. no mecanismo, identificar como este composto, se existem passos, sub mecanismos, estruturas, excees, desvios ou condies;

identificar outros relacionamentos que podem haver entre as estruturas; 3.1. no relacionamento, identificar o seu tipo. Fig. 2 - Diretrizes para Instanciao de Mtricas Abstratas.

3.

As mtricas so divididas em trs subconjuntos de mtricas (Fig. 3): i) separao de interesses (M1); ii) tamanho (M2); e, iii) acoplamento (M3).
M1 - Separao de interesses: Nmero de mdulos que especificam um determinado interesse; Nmero de passos que compem esses mdulos M2 - Tamanho: Nmero de passos nas descries de cada mdulo independente; Nmero de passos condicionais de cada mdulo independente; Nmero de excees de cada mdulo independente. M3 - Acoplamento: Nmero de mdulos que so includos ou estendidos em outros mdulos; Nmero de mdulos que so entrecortados por um determinado mdulo. Legenda: Mdulo: 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 restries de um sistema, podendo ser tanto um requisito funcional como um no-funcional, por exemplo: segurana, persistncia, interface, tratamento de erros, cadastro de cliente, emisso de pedidos entre outros. Aspecto: uma estrutura que encapsula um interesse (ou parte deste). Entrecorta: o relacionamento de um aspecto com um mdulo, pelo fato de um aspecto especificar um interesse (ou parte deste) que ser inserido no mdulo. Fig. 3 Mtricas Abstratas.

O primeiro conjunto de mtricas M1, verifica o quo separado est um determinado interesse, ou seja, em quantos mdulos esto especificados um determinado interesse e quantos passos foram necessrios para descrever esse interesse. Esse primeiro tipo de mtrica ter um valor para cada interesse, por exemplo: Utilizando as mtricas de separao de interesses foi possvel verificar que o interesse de Segurana foi modularizado por 7 (sete) casos de uso aspectuais e descrito em 78 (setenta e oito) passos. O segundo conjunto de mtricas so relacionadas ao tamanho de cada mdulo, indicando fatores como o nmero de passos, passos condicionais e excees. Essas mtricas tero um valor nico para cada mdulo, por exemplo: Utilizando as mtricas de tamanho foi possvel verificar que o caso de uso aspectual Limitar Valor da Movimentao contm 2 (dois) passos e 0 (zero) excees e passos condicionais.

O terceiro conjunto de mtricas relacionadas com o acoplamento verifica a quantidade de relacionamentos tanto de entrecorte quanto de extenso e incluso existentes em cada mdulo. Baseando-se nos processos de medio descritos em [19, 29], foi elaborado um processo que pode ser uma alternativa de como realizar a aplicao do conjunto de mtricas abstratas em um documento de requisitos orientado a aspectos, Figura 4. So basicamente trs etapas: 1 - Instanciao das mtricas abstratas: tem como entrada as mtricas abstratas, as diretrizes e um documento de requisitos orientado a aspectos. A sada dessa primeira etapa um conjunto de mtricas instanciadas para medir o documento de requisitos. 2 - Aplicao das mtricas: tem como entrada o documento de requisitos e as mtricas j instanciadas para esse documento. A sada dessa etapa um conjunto de dados coletados a partir da aplicao das mtricas. 3 - Anlise dos dados coletados: tem como entrada o resultado dos dados obtidos a partir da aplicao das mtricas e outros dados que podem ser desde estatsticas obtidas de outras aplicaes de mtricas como a prpria experincia do engenheiro de software. A sada dessa ultima fase sero dados que auxiliaro o engenheiro de software na tomada de decises e possveis alteraes no documento de requisitos avaliado.
Mtricas abstratas M1 Diretrizes M2 M3 Mtricas instanciadas M1 M2 M3 Experincias do Eng. de Software, dados externos de outras medies, etc

1 2
Dados Coletados

Documento de Requisitos

Possveis alteraes (realimentao)

Decises

Fig. 4 - Um processo de utilizao das mtricas abstratas.

A Seo seguinte apresenta um estudo de caso em que as diretrizes auxiliam a instanciar as mtricas abstratas para que seja realizada a medio de documento de requisitos orientado a aspectos.

5. Estudo de Caso
Existem duas tcnicas bsicas para avaliar uma abordagem: experimentos e estudos de caso. A realizao de experimentos prov uma maneira de avaliao baseada em comparao direta, permitindo a pesquisadores investigar qual o impacto da tecnologia no processo de maneira detalhada [30]. J a realizao de estudos de caso

est mais preocupada em avaliar os benefcios de uma abordagem de forma a verificar se as mudanas no processo proporcionam o resultado desejado [15]. A tcnica escolhida para ser utilizada neste trabalho foi o estudo de caso, por se pretender avaliar o comportamento das mtricas 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 bancrio via web, denominado Internet Banking (tem as funes bsicas para realizar transaes financeiras e bancrias). 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 contm uma nova unidade modular que Sousa chamou de caso de uso aspectual. Esse trabalho melhor detalhado na Seo 2. Para ter alguma garantia que a aplicao das mtricas foi efetuada corretamente, o engenheiro de software dever estabelecer os objetivos da medio antes que a coleta de dados tenha incio, definindo cada mtrica de modo no ambguo [19]. O estudo de caso foi realizado seguindo o processo de medio mostrado na Figura 4, porm a ltima etapa, de Anlise dos dados coletados, no relatada nesse artigo, assim este estudo ficou dividido em duas etapas que so apresentadas nas subsees seguintes. 5.1 Instanciao das Mtricas Abstratas Seguindo as diretrizes apresentadas na Seo anterior, Fig. 2, foram encontrados os seguintes itens mensurveis no documento de requisitos: 1 - As unidades modulares utilizadas so: casos de uso e casos de uso aspectuais. 1.1 - Cada caso de uso (tambm os aspectuais) so compostos por passos. 2 - Os mecanismos de composio so especificados por tabelas. 2.1 - Cada tabela contm linhas que identificam os casos de uso afetados por um determinado caso de uso aspectual. 3 - Os relacionamentos existentes entre os casos de uso so os mesmos existentes em um diagrama de caso de uso habitual com a adio do relacionamento dos casos de uso aspectuais. 3.1 - Os relacionamentos podem ser de extenso (extend), incluso (include) e entrecortes (crosscuts). Aps identificar os itens que compem a abordagem utilizada no documento de requisitos, o engenheiro de software deve instanciar os itens mensurveis de acordo com as mtricas abstratas, Figura 3. A seguir mostrado como ficou os trs conjuntos de mtricas aps a instanciao. M1 - Separao de interesses: M1a - Nmero de casos de uso (aspectual ou no) que modelam um determinado interesse; M1b - Nmero de passos nas descries dos casos de uso (aspectual ou no) que descrevem um determinado interesse. M2 - Tamanho: M2a - Nmero de passos nas descries de cada caso de uso (aspectual ou no);

M2b - Nmero de passos condicionais de cada caso de uso (aspectual ou no); M2c - Nmero de excees de cada caso de uso (aspectual ou no). M3 - Acoplamento: M3a - Nmero de casos de uso (aspectual ou no) que so includos ou estendidos em um determinado caso de uso aspectual; M3b - Nmero de casos de uso (aspectual ou no) que so entrecortados por um determinado caso de uso aspectual. 5.2. Aplicao das Mtricas Aps instanciar as mtricas, o engenheiro dever realizar a coleta dos dados a partir da medio dos itens especificados por cada mtrica. No caso desse estudo os dados foram coletados manualmente, percorrendo todo o documento de requisitos. Ou seja, para cada mtrica foi percorrido o documento por completo e contabilizado (somado todas as ocorrncias) o item que estava sendo especificado na mtrica. Para coletar dados com a aplicao da mtrica M1a, que tem a finalidade de medir o grau de separao 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 Segurana. 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 informaes Transao, Cobrar Tarifa por Transao Extra, Checar Senha Internet Banking, Checar Dados Pessoais do Cliente, Registrar CPMF, Limitar Valor da Movimentao (Tabela 2), Oferecer Bonificao. Ou seja, o valor obtido com a aplicao da mtrica M1a 7 (sete). A Tabela 2, mostra o caso de uso aspectual Limitar Valor da Movimentaoe seus 2 (dois) passos, para a aplicao da mtrica M1b devero ser contados todos os passos de todos os casos de uso encontrados para o interesse de Segurana. Para a mtrica 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 Segurana.
Tabela 2. Especificao do caso de uso aspectual Limitar Valor de Movimentao.
OPERACIONALIZACAO #03: Limitar valor de movimentao INFORMAES CARACTERSTICAS Objetivo Verificar limite do valor de transaes financeiras para diminuir riscos de fraudes. Pr-condies Valor da transao dado como entrada. Ator Primrio Cliente do banco, titular da conta. CENRIO PRINCIPAL DE SUCESSO Passo Ao 1 O sistema verifica se o valor da transao supera limite. 2 O sistema retorna o resultado da verificao

Neste estudo de caso, optou-se por coletar somente dados referentes aos mdulos (casos de uso) aspectuais. Portanto, primeiramente foi selecionado um caso de uso e se mediu o item desejado. Por exemplo, para o caso de uso aspectual

Limitar Valor da Movimentao, Tabela 2, o valor da mtrica M2a 2 (dois), o valor da M2b 0 (zero) e da mtrica M2c 0 (zero).
Tabela 3- Tabela de composio Limitar Valor de Movimentao.
REQUISITO ASPECTUAL: AR #07 LIMITAR VALOR DE MOVIMENTAO Caso de uso Afetado Condio Regra de Ponto de Informaes (Opcional) Composio Juno Adicionais UC #04 Realizar Wrap 3 Se limiteOk ento execute(pto juno) transferncia Seno exibe(msgErro) UC #05 Pagar boleto Wrap 4 Se limiteOk ento execute(pto juno) bancrio Seno exibe(msgErro) UC #06 Emitir Wrap 3 Se limiteOk ento execute(pto juno) comprovante Seno exibe(msgErro)

Selecionando o mesmo caso de uso aspectual Limitar Valor da Movimentao, Tabela 2, e aplicando a mtrica M3a obtm-se o valor 0 (zero). A coleta dos dados da aplicao da mtrica M3b basicamente obtido pela observao das Tabelas de composio, por exemplo a tabela Limitar Valor de Movimentao, Tabela 3, pode-se obter a informao que o caso de uso aspectual Limitar Valor de Movimentao entrecorta os casos de uso: realizar transferncia, pagar boleto bancrio e emitir boleto bancrio, ou seja, o valor da M3b para o caso de aspectual Limitar Valor de Movimentao 3 (trs). Esses relacionamentos de entrecorte podem ser tambm observados no diagrama de casos de uso, Fig. 1. Aps a aplicao das mtricas os dados coletados devero ser analisados e interpretados para ganhar profundidade na viso de qualidade do software e os resultados dessa interpretao poder levar a modificaes do documento de requisitos. Utilizando como base os fatores de qualidade que podem ser medidos (diretamente) segundo McCall [16], as mtricas apresentadas nesse estudo de caso auxiliaro o engenheiro a avaliar o documento de requisitos segundo os fatores de: - Utilizao: Esforo necessrio para entender, operar, interpretar e aprender um documento. - Mantenabilidade: O esforo necessrio para localizar e consertar um erro. - Flexibilidade: O esforo necessrio para modificar um documento. - Reutilizao: Quanto um documento (ou parte dele) pode ser reusado em outros projetos, sistemas, aplicaes, etc. Relativo ao empacotamento e escopo das funes que o sistema realiza A Seo seguinte relata algumas consideraes feitas sobre as mtricas e o estudo de caso apresentado.

6. Consideraes Finais
Este artigo apresentou um conjunto de mtricas abstratas, que com o auxlio de diretrizes, podem ser instanciadas para medir um documento de requisitos orientado a aspectos em relao a separao de interesses, tamanho e acoplamento, sendo que esse documento pode ter sido elaborado por uma abordagem qualquer. As mtricas apresentadas auxiliam o engenheiro de software a elaborar uma base de conhecimento em relao ao interesse medido. Essa base de conhecimento

dever auxiliar decises em projetos futuros que foram implementados utilizando os conceitos do desenvolvimento orientado a aspectos. Com a aplicao das mtricas em vrios documentos de requisitos ser possvel inferir qual seria um bom grau de separao de um determinado interesse. Com a utilizao de mtricas abstratas, a aplicao dessas pode ser feita em qualquer tipo de documento de requisitos orientados a aspectos, independente da abordagem que foi seguida para sua criao. Isso facilita a adoo das mtricas, pois, como a orientao a aspectos est em um estgio inicial, principalmente na fase de requisitos, a todo momento esto surgindo novas abordagens de como elaborar um documento de requisitos orientado a aspectos, alm das vrias j existentes. Engenheiros de software devem adaptar as mtricas ao ambiente de seu projeto de software, inserindo padronizaes, como por exemplo, somente medir mdulos aspectuais, ou ento coletar os dados por mdulos. Tcnicas estatsticas vlidas devem ser aplicadas para se estabelecer relaes, como por exemplo o nvel de complexidade. Clculos que melhor expressem os dados coletados devem ser definidos, como por exemplo mostrar a mdia de uma determinada mtrica. As mtricas apresentadas nesse artigo so o ponto de partida para se garantir a qualidade de documentos de requisitos especificados com base na orientao a aspectos. Porm deve-se levar em conta outros fatores para que haja sucesso em uma atividade mtrica, como a conduo da coleta dos dados e sua anlise. Outro ponto que se deve estar ciente que essa atividade de medio esta intimamente ligada ao apoio gerencial. Financiamento, treinamento e promoo devem ser considerados, se um programa de medio tcnica deve ser estabelecido e sustentado. Como trabalhos futuros novas avaliaes devero ser realizadas em outros documentos de requisitos orientados a aspectos elaborados por outras metodologias, para que deste modo seja possvel validar a aplicabilidade das mtricas abstratas. Novas diretrizes devero ser elaboradas para permitirem instanciar as mtricas para qualquer fase do desenvolvimento de software e no somente na fase de requisitos. Uma ferramenta que implemente as mtricas e faa a coleta dos dados de forma, no mnimo semi-automtica dever ser elabora, para que assim agilize o processo de aplicao das mtricas.

Agradecimentos
Este trabalho contou com o apoio de vrios projetos de pesquisa (CNPq 304982/2002-4, CAPES BEX 1775/2005-7, CAPES BEX 3003/05-1 e CAPES/ GRICES 129/05).

Referncias Bibliogrficas
1. 2. 3. 4. Albrecht, P. F. et al. Reliability test system IEEE trans. on Pas., Vol. Pas-98, No.6 , p. 2047-2054. Nov./Dec.1979. Arajo, J.; Whittle, J.; Kim, D. "Modeling and Composing Scenario-Based Requirements with Aspects". In: The 12th Requirements Engineering Conference , Kyoto, Japan, September 2004. 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. Brito, I. and Moreira, A. Towards a Composition Process for Aspect-Oriented Requirements. In: Aspect-Oriented Requirements Engineering and Architecture Design, - Boston, USA, 2003.

5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.

Czarnecki, K.; Eisenecker, U. Generative Programming: Methods, Tools, and Applications. AddisonWesley, 2000. Durn, A.; Corts, A. R.; Corchuelo, R.; Toro, M. Supporting Requirements Verification Using XSLT .Requirements Engineering Conference - RE 2002 Essen, Alemanha, Setembro 2002. Elrad, T., Filman, R. and Bader, A. Aspect-Oriented Programming: Introduction, Communications of the ACM, v.44 n.10, p.29-32, Oct. 2001. Elrad, T.; Aksit, M.; Kiczales, G.; Lieberherr, K. and Ossher, H. Discussing Aspects of AOP. Communications of the ACM, 44(10):3338, October 2001. Hannemann, J.; Kiczales, G. Overcoming the Prevalent Decomposition in Legacy Code. In: Workshop on Advanced Separation of Concerns, Toronto, Canada, Maio 2001. ISO 9126, Tecnologia da Informao Qualidade de Produto Parte 1: Modelo de Qualidade, International Standard ISO/IEC 9126, International Standard Organization, Junho, 2001. Jacobson, I; Chriterson, M; Jonsson, P. and Overgaard, G. "Object-Oriented Software Engineering: A Use Case Driven Approach". Addison Wesley, 1992. Jacobson, I.; Booch, G.; and Rumbaugh, J. The Unified Software Development Process, AddisonWesley, 1999. Kiczales, G.; Lamping, J.; Mendhekar, A. RG: A Case-Study for Aspect-Oriented Programming. In: SPL97. Palo Alto Research Center, Technical Report, 1997. 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. Kitchenham, B.; Pickard, L. and Pfleeger, S. Case Studies for Method and Tool Evaluation . IEEE, 1994. 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. Moreira, A.; Arajo, J. and Brito, I. Crosscutting Quality Attributes for Requirements Engineering, SEKE 2002, ACM Press, Italy, July, 2002. 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. Pressman, R. Engenharia de Software. Makron Books, 5 edio, 2002. Ramos, R. A.; Penteado, R.; Masiero, P. C.; - Um Processo de Reestruturao de Cdigo Baseado em Aspectos - SBES2004 - Braslia/DF. Outubro, 2004. Ramos, R. A, Castro, J. F. B. Avaliao de uma Metodologia de Medio da Qualidade em um Documento de Requisitos Orientado a Aspectos. In: WER, Porto- Portugal, 2005. Rashid, A.; Sawyer, P.; Moreira, A. and Arajo, J. Early Aspects. A Model for Aspect-Oriented Requirements Engineering. Conference on Requirements Engineering, Essen, Germany, 2002. Rashid, A.; Moreira, A. and Arajo, J. Modularisation and Composition of Aspectual Requirements. In: 2nd International Conference on Aspect-Oriented Software Development, 2003. Reis, T., P., C. Uma Metodologia para Medio da Qualidade de Aplicaes Web na Fase de Requisitos. Dissertao Programa de Ps-Graduao em Cincia da Computao, UFPE, Recife Pernambuco, 2004, 163f. SantAnna, C.; Garcia, A.; Chavez, C.; Lucena C.; Staa A. On Reuse and Maintenance of AspectOriented Software: An Assessment Framework. In: SBES2003, Manaus/Amazonas. Outubro, 2003. SantAnna, C.; Garcia, A.; Chavez, C.; Lucena C.; Staa A. Design Patterns as Aspects: A Quantitative Assessment. In: SBES2004, Brasilia - DF, 2004. 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. Sousa, G. Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento de Software Orientado a Aspectos. Dissertao Programa de Ps-Graduao em Cincia da Computao, UFPE, Recife Pernambuco, maio 2004, 180f. Summerville, I. Engenharia de Software. Addison- Wesley, 2003. Travassos, G.; Gurov, D. and Amaral, E. Introduo Engenharia de Software Experimental. Relatrio Tcnico, RT-ES-590/02, Rio de Janeiro, 2002. Whitte, J.; Arajo, J. Scenario modelling with aspects. In: IEE Proceedings online no. 20040921, Vol. 151, No. 4, Agosto 2004. W3C. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. Outubro 2000.