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
1

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
2

ITC- Istituto Trentino di Cultura

IRST -Instituto per la Ricerca Scientifica e Tecnologica,
Trento-Povo, Italy
jaelson@itc.it
3

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

Cliente

<<crosscuts>>

Realizar Transao
Financeira

Limitar Valor da
Movimentao

<<crosscuts>>
Cobrar Tarifa por
Transao Extra

Realizar
Checar Senha
Transao de Internet Banking
Consulta

Visualizar
Saldo da Conta

Emitir
Comprovante

Pagar Boleto Realizar

Bancrio Transferncia
Legenda

Visualizar
Extrato da Conta

Requisitos
Aspectuais

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;

3.

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.

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

M2
M3

Diretrizes

Mtricas instanciadas
M1

M3

Experincias do Eng.
de Software, dados
externos de outras
medies, etc

M2

1
2

Documento de
Requisitos

Dados Coletados

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.