ARQUITETURA

DE SISTEMAS

Jailson Costa dos Santos

Engenharia de software
orientada a aspectos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Caracterizar softwares orientados a aspectos.

 Discutir os aspectos de implementação de softwares orientados a
aspectos.
 Exemplificar o desenvolvimento de softwares orientados a aspectos.

Introdução
Neste capítulo, você vai compreender como a engenharia de software
orientada a aspectos auxilia na simplificação e no reúso de programas.
Você também vai analisar a implementação de softwares orientados, por
meio da separação de interesses, e como isso pode auxiliar no desen-
volvimento de software. Você vai verificar as ideias que servem de base
para o desenvolvimento orientado a aspectos, observando como a sua
abordagem influencia na engenharia de requisitos, na programação e
no projeto de software. Por fim, você vai avaliar a complexidade existente
nos testes do sistema orientado a aspectos.

Conceitos introdutórios da engenharia

de software orientada a aspectos
Existe uma complexidade visível na relação entre os atributos e os componen-
tes de um programa na maioria dos sistemas considerados de grande porte.
Um conjunto de componentes consegue implementar um único requisito,
sendo que cada componente pode acrescentar elementos de requisitos varia-
dos. Na prática, isso implica afirmar que a alteração desses requisitos leva ao
conhecimento e à mudança de diversos componentes.
2 Engenharia de software orientada a aspectos

Um componente, alternativamente, consegue apresentar o desempenho de

alguma atividade central, além de acrescentar o código que implementa di-
versos atributos de sistema, conforme leciona Sommerville (2011). É preciso
compreender que reusar esses componentes pode ser extremamente custoso,
mesmo que o reúso seja aplicado de maneira significativa. De acordo com
Sommerville (2011), qualquer alteração existente no reúso visa a extrair um
código extra que não esteja ligado à atividade central do componente.
Diante desse contexto, é possível definir que a engenharia de software
orientada a aspectos (do inglês aspect-oriented software engineering) se
refere a uma teoria apresentada para a criação de um software que objetiva
solucionar questões relacionadas ao reúso de software, possibilitando, dentre
outros aspectos, que os programas sejam mantidos de forma mais simples. Ela
tem como referência as abstrações (aspectos) que introduzem a atividade de
sistema, podendo ser solicitada em setores distintos dentro de um programa.
É importante que você entenda que os aspectos, segundo a conceituação de
Sommerville (2011), encapsulam a atividade que convive com outra funciona-
lidade existente no sistema, sendo que eles são empregados em paralelo com
outras abstrações.

A composição automática de objetos, aspectos e métodos alinhados com as ca-

racterísticas contidas no código-fonte de programa gera um programa executável
orientado a aspectos.

A determinação sobre os locais onde os aspectos serão incluídos no pro-

grama pode ser considerada uma relevante característica desses elementos.
Outro ponto importante se refere ao interesse transversal implementado por
meio do código. E como isso ocorre? Segundo o entendimento de Sommerville
(2011), é possível que você explicite que o código transversal seja incluído,
independentemente de se isso vai ocorrer antes ou depois da chamada de um
método determinado ou diante de um acesso de requisito.
Suportar a separação de interesses é considerada a vantagem mais
importante quando nos referimos à abordagem orientada a aspectos. As
boas práticas de engenharia de software consistem na separação desses
 Engenharia de software orientada a aspectos 3

interesses em componentes distintos, diferentemente da inclusão de interesses

diante de uma abstração lógica igual.
Vale ressaltar que a compreensão, o reúso e a alteração dos interesses
transversais apresentados como aspectos ocorrem de maneira independente,
sem maiores questionamentos sobre a forma de utilização do código. Imagine
que a representação da autenticação de usuário ocorra por meio de um aspecto
que solicita uma senha ou nome de usuário. A conclusão a que podemos chegar
é que isso pode ser embutido de maneira automática, no momento em que
aparece uma requisição de autenticidade.
Partamos do pressuposto de que a autenticação de usuário de um requisito
seja solicitada anteriormente a qualquer mudança nos detalhes de caráter
pessoal realizada no banco de dados. Isso pode ser descrito como um aspecto,
determinando-se que o código de autenticação seja acrescido antes de toda
chamada a métodos que permitem a atualização dos detalhes pessoais, con-
forme orienta Sommerville (2011). Em seguida, é possível aumentar o requisito
que permite a autenticação direcionada às atualizações do banco de dados
de maneira total, o que facilita a implementação com a mudança do aspecto.
Dessa maneira, é possível alterar a determinação do local da composição do
código de autenticação dentro do sistema, não sendo necessário buscar todas
as ocorrências referentes a esse método. A conclusão a que se pode chegar é
que a possibilidade de falhas é menor diante da aplicação de vulnerabilidades
de proteção no programa.

Segundo Sommerville (2011), o desenvolvimento de pesquisas relacionadas à orientação

a aspectos tem como meta a programação orientada a aspectos. Salienta-se que as
linguagens relacionadas foram criadas para aumentar a programação orientada a
objetos, para ser possível acrescentar aspectos. Porém, é perceptível que os interesses
transversais apresentam problemas em outras fases do processo de software, o que
estimula pesquisadores a descobrirem como usar, dentre outros fatores, a orientação
a aspectos na engenharia de requisitos de sistema.

Verificaremos mais adiante, dentre outros temas, as vantagens e as des-

vantagens da utilização de uma abordagem orientada a aspectos em fases
distintas do processo de desenvolvimento de software.
4 Engenharia de software orientada a aspectos

Implementação do software por meio

da separação de interesses
Para que você consiga compreender de maneira clara como a separação de
interesses é um fator importante para a implementação de software, é necessário
fazer uma analogia com a divisão do trabalho pertencente à administração
científica. Nesse caso, o operário passa por uma especialização em determi-
nadas tarefas para elevar a sua produtividade, conforme exemplifica Chiave-
nato (2003). Trazendo esse conceito para o ambiente tecnológico, é possível
verificar que é preciso organizar o software, de maneira que cada método ou
procedimento realize apenas uma atividade, sem a preocupação de atuar em
outros elementos do programa, segundo Sommerville (2011). Assim, pode-se
compreender cada item que compõe o programa, verificando os seus interesses
específicos. Havendo a necessidade de alteração, esta será realizada em uma
quantidade reduzida de elementos.

A separação de interesses é um princípio relevante desde as primeiras fases históricas

referentes à ciência da computação. Na década de 1950, foram criadas as sub-rotinas
responsáveis pelo encapsulamento de uma unidade de funcionalidade. Posteriormente,
foram criados os mecanismos de estruturação de programas, mais satisfatórios para
a realização da separação de interesses.

É preciso deixar claro que os mecanismos de estruturação de programas

apresentam problemas quando determinados interesses entram em conflito com
outros. Essa transversalidade não pode ser visualizada por meio de mecanismos
estruturados. Para auxiliar no gerenciamento desses interesses transversais,
foram introduzidos os conceitos relacionados à engenharia orientada a aspectos.
É extremamente complexo estabelecer o verdadeiro significado de um interesse
dentro desse contexto, ainda que se considere a separação de interesses como
uma boa prática de engenharia de software. Esporadicamente, o interesse é
definido como uma noção funcional, conforme aponta Sommerville (2011).
A possibilidade de se estabelecer uma relação entre os interesses e os progra-
mas pode ser considerada um dos principais problemas na maioria das tentativas
 Engenharia de software orientada a aspectos 5

de se definir interesses, já que eles são analisados como representações dos

atributos e prioridades dos stakeholders dentro do sistema, segundo Sommerville
(2011). É preciso que você entenda que o fato de os usuários almejarem um
retorno rápido do sistema pode torná-lo interessante, assim como acrescentar
uma funcionalidade específica ou uma organização que ofereça suporte a
sistemas de fácil manutenção.
Se os interesses forem analisados como uma forma de tornar os requisitos
organizados, é possível entender por qual motivo podemos considerar como
uma boa prática a abordagem que classifica os interesses como elementos
distintos de programas. Segundo Sommerville (2011), sem dúvida é mais
simples acompanhar interesses apresentados na forma de requisitos, de maneira
unitária ou conjunta, com os elementos de programa relacionados visando à
implementação desses interesses.
Pode-se observar diferentes tipos de interesses de stakeholders.
Por exemplo, ao avaliar um sistema de controle de trem, verifica-se o seu
modelo de frenagem. Esse modelo é considerado um interesse funcional, que,
por definição, está ligado a uma determinada funcionalidade a ser acrescida no
sistema. No que se refere aos interesses de qualidade de serviço, observa-se
que estão ligados ao desempenho não funcional do sistema. A disponibilidade,
o desempenho e a confiabilidade são aspectos presentes nesses interesses.
Por estarem em alinhamento com as políticas gerais que administram o
uso de um sistema, os interesses de políticas acrescentam interesses relacio-
nados às normas que envolvem negócios e segurança. Aspectos relacionados
à manutenção e à configuração estão inseridos nos interesses do sistema,
que se relacionam com os requisitos do sistema como um todo. Por fim, te-
mos os interesses organizacionais, que se alinham às prioridades e metas da
organização, acrescentando a criação de um sistema viável financeiramente,
utilizando os ativos do software, além da preocupação em manter a imagem
da organização, conforme aponta Sommerville (2011).
Você pode estar se questionando: e quando os interesses funcionais estão di-
recionados a atender aos próprios objetivos? Nesse caso, podemos classificá-los
como interesses centrais. Além dos centrais, os sistemas de grande porte podem
apresentar interesses funcionais de ordem secundária, que se caracterizam
por envolver as atividades que dividem informações com os interesses centrais.
Outra característica dos interesses funcionais secundários é serem solicitados
para que o sistema consiga atender aos seus atributos não funcionais.
Interesses como as políticas organizacionais, assim como a qualidade de
serviço, indicam os requisitos primordiais do sistema, além dos interesses
6 Engenharia de software orientada a aspectos

secundários mencionados. Normalmente, esses interesses são direciona-

dos ao sistema de maneira completa e são classificados como interesses
transversais, já que o objetivo é torná-los diferenciados em relação aos
interesses centrais.

Apesar de não abrangerem o sistema como um todo, é possível considerar que os

interesses funcionais secundários são transversais. Normalmente, eles são ligados a
conjuntos de interesses centrais que possibilitam a funcionalidade apresentada.

Na Figura 1, é possível visualizar um exemplo de interesses transversais

em um sistema de Internet Banking, em que a principal meta é disponibilizar
um serviço baseado na qualidade. Para atingir esse objetivo, é necessário
que os interesses centrais (gerenciamento de clientes e contas, verificação de
crédito, etc.) estejam alinhados com esses interesses. Porém, o sistema visa a
assegurar os requisitos da segurança dos dados, no caso de falhas no sistema,
e apresentar requisitos referentes a ações protetivas dos bancos.

Figura 1. Interesses transversais.

Fonte: Sommerville (2011, p. 398).
 Engenharia de software orientada a aspectos 7

É importante frisar que a influência exercida na implementação dos outros

atributos do sistema determina que estes sejam os interesses transversais.
Segundo Sommerville (2011), as abstrações de linguagem de programação
são métodos que geralmente empregamos para formar e constituir os inte-
resses centrais de um sistema. Porém, os interesses centrais nas linguagens
de programação convencionais implementadas geralmente acrescentam um
código adicional, visando a implementar interesses transversais, de políticas
funcionais e de qualidade de serviço, ainda conforme Sommerville (2011).
E o que isso pode ocasionar? É bem provável que isso permita o surgimento
do entrelaçamento, que consiste na inclusão de um código implementador
de requisitos distintos, e do espalhamento, que acontece quando a prática de
um único interesse está difundida por diversos elementos em um programa.
Observe na Figura 2 um exemplo de implementação simplificada da parte
do código direcionada a um sistema de determinação de buffer, que expõe
um entrelaçamento.

Figura 2. Entrelaçamento do código de gerenciamento e sincronização de buffer.

Fonte: Sommerville (2011, p. 398).
8 Engenharia de software orientada a aspectos

Um item no buffer é acrescido por meio da implementação da operação put.

Porém, se o buffer estiver completo, é preciso esperar até que a operação get
apropriada retire um componente do buffer. Vale ressaltar que os detalhes não
apresentam relevância, e, basicamente, as chamadas wait() e notify()
são empregadas visando à sincronização das operações put e get. O interesse
central é amparado pelo código que se encontra entrelaçado com o código
responsável pela implementação da sincronização.
Como visto, o espalhamento surge quando um único interesse implementado
está difundido em diversos componentes dentro de um programa. A possibili-
dade de isso ocorrer é maior assim que houver a implementação dos atributos
relacionados com os interesses de políticas ou com os interesses funcionais
secundários, conforme leciona Sommerville (2011).
Por exemplo, suponha um sistema de gerenciamento de apontamentos
médicos que apresente um conjunto de componentes, com a finalidade de
gerenciar, dentre outros aspectos, informações relacionadas a medicações,
tratamentos e diagnósticos. Todos esses componentes objetivam manter registros
dos pacientes, o que consiste no interesse central do sistema. Pode-se observar
que o sistema pode ser adaptado para clínicas distintas, ao possibilitar eleger
os componentes que apresentam a funcionalidade solicitada.
Porém, considere a possibilidade de existência de um importante inte-
resse secundário, que consiste na manutenção de informações estatísticas.
Sendo assim, é estabelecido um provedor de código de saúde capaz de
extrair dados gerais sobre os pacientes (admissão, dispensa e falecimento),
dentre outros aspectos. A adição do código permite que esses requisitos
sejam implementados, assegurando o anonimato dos dados do paciente e
registrando esses dados em um banco de dados de estatísticas. Por fim, os
dados estatísticos serão processados por um componente estatístico, gerando
os relatórios necessários.
Verifica-se, na Figura 3, o diagrama de três classes que poderiam ser adi-
cionadas ao sistema de apontamentos de pacientes. Paralelos a isso, alguns
procedimentos centrais são empregados para gerir informações de pacientes.
A área que aparece em tom sombreado demonstra as técnicas essenciais na
implementação do interesse estatístico secundário.
 Engenharia de software orientada a aspectos 9

Figura 3. Espalhamento de métodos que implementam interesses secundários.

Fonte: Sommerville (2011, p. 399).

Com relação ao interesse secundário de assegurar a exclusão mútua, o código

de sincronização deve ser acrescido a todos os métodos que acessam o buffer
compartilhado, conforme se visualiza em um tom mais sombreado na Figura 3.

Outros interesses centrais servem de espaço para que o interesse estatístico se disse-
mine. À medida que há uma alteração nos requisitos iniciais do sistema, os problemas
relacionados a entrelaçamento e espalhamento vão aparecer.

Diante da possibilidade de novos dados estatísticos serem extraídos do

sistema de registro de pacientes, você consegue perceber que as mudanças sis-
têmicas não são realizadas em um local exclusivo. Portanto, é preciso despender
tempo selecionando os elementos do sistema que sofrerão essas mudanças e
que devem ser alterados. Posteriormente, é preciso mudar esses componentes
de maneira individualizada, visando a incorporar as alterações necessárias, o
que pode ser extremamente custoso devido ao tempo necessário para avaliar
os itens que compõem o sistema e, em seguida, realizar as mudanças.
10 Engenharia de software orientada a aspectos

É importante observar que haverá sempre a possibilidade de você lembrar

de algum código que viria a ser mudado. A conclusão a que podemos chegar é
que, dessa forma, as estatísticas estariam erradas. Outro ponto a ser analisado
é o fato de que uma quantidade excessiva de mudanças a serem realizadas
eleva as possibilidades de defeitos e falhas no sistema.

Desenvolvimento de software: aspectos,

pontos de junção e corte
É importante que você se familiarize com os conceitos ligados ao desenvol-
vimento de software orientado a aspectos, a partir da nomenclatura abordada
pelos desenvolvedores de AspectJ, ao final da década de 1990, e elencada por
Sommerville (2011). Porém, vale ressaltar que a conceituação aqui abordada
será aplicada de maneira generalista. O Quadro 1 sintetiza os termos mais
relevantes, para um entendimento mais objetivo.

Quadro 1. Terminologia usada na engenharia de software orientada a aspectos

Termo Definição

Adendo Código que implementa um interesse.

Aspecto Uma abstração de programa que define o interesse

transversal. Inclui a definição de um ponto de corte
e do adendo associado com esse interesse.

Ponto de junção Evento em um programa em execução em que o adendo

associado com um aspecto pode ser executado.

Modelo de Conjunto de eventos que podem ser

ponto de junção referenciados em um ponto de corte.

Ponto de corte Uma declaração, inclusa em um aspecto, que

define os pontos de junção em que o adendo
de aspecto associado deve ser executado.

Composição A incorporação do código de adendo em ponto de

junção específico por um compositor de aspectos.

Fonte: Adaptado de Sommerville (2011).

 Engenharia de software orientada a aspectos 11

Podemos definir o AspectJ como um plugin criado com o objetivo de condicionar a

adaptação da linguagem Java e direcioná-la para a orientação a aspectos. É importante
ressaltar que essa adaptação abrange a inserção dos atributos, dos métodos e dos
construtores, juntamente com os aspectos, os pontos de corte, os pontos de junção
e os adendos.

Imagine que, ao dar suporte ao uso de uma determinada programação,

um elemento consiga encapsular os outros. Essas características definem o
conceito de aspecto, que consiste em um componente essencial de encap-
sulamento dos outros elementos. Esses elementos dão apoio à utilização
da programação orientada a aspectos, que são os pontos de corte, os aden-
dos e as declarações intertipos. Tais declarações conseguem modificar a
chamada estrutura estática (static crosscutting), a partir do momento em
que se acrescentam elementos a uma classe. Uma segunda possibilidade de
alteração ocorre na estrutura dinâmica, em que são feitas intercepções
em áreas anteriores e posteriores aos pontos de junção e acréscimo de
comportamento. Existe ainda uma alternativa de alteração, por meio da
aquisição total do controle do ponto de execução feito em um programa,
alterando o nível hierárquico do sistema.

Para a declaração de um aspecto, utiliza-se a forma geral:

[privileged] [modifiers] aspect Id [extends Type] [imple-
ments TypeList] [PerClause] { Body }
12 Engenharia de software orientada a aspectos

É importante verificar que os modifiers apresentam a mesma conceituação e

as mesmas normas de visibilidade observadas nas classes de programação Java.
O aspecto pode ser classificado por meio de três perspectivas, podendo ser:

 público, quando está disponível para todos;

 privado, quando a sua visualização ocorre exclusivamente para o as-
pecto detentor;
 protegido, quando a visibilidade é idêntica ao aspecto privado, com a dife-
rença de ser visto pelos subaspectos ou dentro do pacote em que se encontra.

Não havendo outra forma de se ter acesso às partes restritas das classes por meio dos
métodos gets e sets, utilizamos a declaração privileged. Agora, para determinar
o grau de disponibilidade e o momento de instanciar um aspecto, é preciso aplicar
o PerClause.

É possível conceituar o ponto de junção na programação orientada a

aspectos como um ponto existente no fluxo de realização de um programa,
que tem como referência os elementos em que serão inseridos os aspectos.
Segundo Gradeck (2003 apud BORGES; FREITAS, 2008), esses pontos são
empregados, dentre outros motivos, para a chamada e a execução dos métodos
e dos construtores, a inicialização, a referência a campos e a execução de
tratamento de exceções. É possível identificar na Figura 4 um exemplo de
pontos de junção e o fluxo de execução do programa.

Figura 4. Fluxo de execução do programa.

Fonte: Borges e Freitas (2008, documento on-line).
 Engenharia de software orientada a aspectos 13

É possível expor o funcionamento dos pontos de junção em atividade de

uma aplicação orientada a aspectos. Para que isso ocorra, é necessário levar
em consideração que o ponto de junção inicial no programa é um elemento
qualquer ou a chamada de um método. É importante mencionar que essa cha-
mada pode levantar uma exceção ou, até mesmo, ser satisfeita. Posteriormente,
o ponto de junção será a execução do método Retângulo e se caracteriza por
levantar uma exceção, pelo chamamento de outras técnicas, ou por encerrar
as suas atividades de maneira satisfatória.
É preciso que você compreenda que a execução do método Retângulo trouxe
uma chamada a um método Reta, que se encontra na classe Forma. Imagine
que, se esse método é chamado de maneira completa, o próximo ponto de
junção será a realização do método Reta. Caso o trabalho seja realizado com
êxito ou se levante algum tipo de exceção, o método Reta precisará apresentar
o fluxo de execução, retornando à execução do método Retângulo, caso não
esteja finalizado, ou até mesmo aguardando algum valor ou dado que volte
ao método Reta.
Após a sua finalização, o método Reta volta o controle para o prossegui-
mento da execução do método Retângulo, que aponta o término da execução
da classe a que pertence. Para que isso ocorra, é necessário que o método
Retângulo encerre a sua execução e não solicite mais nenhum método novo.
Caso a classe não detenha nenhum método para executar, é possível finalizar
a sua execução, conforme orientam Borges e Freitas (2008).
Segundo o entendimento de Borges e Freitas (2008), os pontos de corte
são os requisitos presentes em um aspecto em que são apresentados os pontos
de junção nos quais se quer encerrar a execução de um programa, visando à
interceptação de um aspecto, por meio da alteração do comportamento desse
programa. Eles possuem assinaturas de práticas que podem ser localizadas
visando a modificar o ciclo de execução original do programa e à introdução
de adendos, que são as novas chamadas.

Segundo a abordagem de Borges e Freitas (2008), a declaração de um ponto de corte

nomeado deve seguir a sintaxe abaixo:
pointcut <Nome> (Argumentos): <corpo>;
14 Engenharia de software orientada a aspectos

Vale ainda ressaltar que, nos pontos de corte de inicialização de classe, o

elaborador estabelece a classe a ser construída. A partir desses aspectos, os
pontos de corte podem ser divididos em:

 initialization, que acontece posteriormente à realização do construtor

da classe;
 preinitialization, que surge na chamada do construtor e se refere ao
ponto de corte da pré-inicialização; e
 static initialization, que está relacionado ao ponto de corte de inicia-
lização estática. Esse ponto de corte acontece no período anterior da
chamada do construtor, informando ao sistema o momento em que o
construtor desviará o fluxo e será chamado, conforme lecionam Borges
e Freitas (2008).

Engenharia de requisitos orientada a interesses

Como já mencionado anteriormente, os interesses indicam os atributos dos
stakeholders. A funcionalidade solicitada por um stakeholders, as políticas
aplicadas à organização ou a mensuração da qualidade do serviço do sistema
são alguns dos aspectos em que os interesses podem refletir. Isso implica
em uma abordagem direcionada à engenharia de requisitos, que reconheça
e especifique quais são os interesses distintos dos stakeholders, conforme
leciona Sommerville (2011).
Perspectivas distintas observadas dos mais variados ângulos foram introdu-
zidas a diversos métodos relacionados à engenharia de requisitos. Tais métodos
se caracterizam por selecionar os diferentes interesses dos stakeholders. Porém,
alguns desses atributos têm a capacidade de interceptar todos os pontos de
vista, como os interesses transversais.

Projeto e programação orientados a aspectos

Ao longo do processo de engenharia de software, é possível implementar os
interesses transversais e as extensões. Isso ocorre devido ao projeto orientado
a aspectos, que se refere ao processo de projetar um sistema usando aspectos
essenciais para essa implementação. Nessa fase, é preciso interpretar os inte-
resses expostos com o problema a ser resolvido como aspectos relacionados
ao programa que está implementando a solução. É importante deixar claro que
esses aspectos serão formados em conjunto com os componentes de sistema
 Engenharia de software orientada a aspectos 15

e assegurarão que não vão surgir ambiguidades de composição, conforme

aponta Sommerville (2011).
Um projeto orientado a aspectos deve contar com o desenvolvimento de
um processo efetivo. Diante disso, é importante mencionar que esse processo
inclui algumas tarefas, conforme descrito a seguir.

 No projeto de sistema central, você deve planejar a arquitetura de sistema

para auxiliar a atividade central desenvolvida pelo sistema. Essa arqui-
tetura considera os requisitos de qualidade de serviço como requisitos
de desempenho e confiança.
 O projeto de aspectos e a identificação se iniciam com o reconhecimento
das extensões dos atributos do sistema, sendo possível avaliá-las, para
visualizar as características dos aspectos. Ao reconhecer esses aspec-
tos, é possível planejá-los de maneira individualizada, considerando o
projeto de recursos centrais de sistema.
 Na fase do projeto de composição, é possível avaliar o sistema central
e os projetos de aspectos, no intuito de desvendar os locais onde deve
ocorrer a interligação dos aspectos em relação ao sistema central. Ba-
sicamente, é possível reconhecer os pontos de junção dentro de um
programa, onde serão constituídos os outros aspectos.

Quanto à resolução dos conflitos, observa-se que os problemas estão relacio-

nados aos aspectos, e que estes podem exercer influência uns sobre os outros, uma
vez que são formados junto com o sistema central. Sem dúvidas haverá conflitos
quando um ponto de corte confrontar aspectos distintos, determinando que pos-
sam ser formados no mesmo ponto do programa, conforme aponta Sommerville
(2011). Também é possível que você visualize conflitos mais perspicazes. Uma
vez que os aspectos são planejados independentemente, eles podem criar hipó-
teses sobre a atividade do sistema central a ser alterada. Porém, na formação de
diversos aspectos, um deles pode influenciar na atividade funcional do sistema,
de maneira não programada por outros aspectos, o que indica que o desempenho
do sistema pode atender às expectativas.
Por fim, o projeto de nomenclatura, que determina os parâmetros para a
terminologia de entidades dentro do programa, acaba sendo extremamente im-
portante, no intuito de impedir a propagação de problemas ocasionados por pontos
de corte em que o nome, de maneira involuntária, combina com o padrão. Você
consegue perceber que o adendo será introduzido de maneira involuntária nesse
ponto, o que é indesejável e pode ocasionar um desempenho atípico no programa.
16 Engenharia de software orientada a aspectos

Verificação e validação
Segundo Sommerville (2011), a verificação e a validação consistem no processo
de exposição de um programa para visualizar se ele atende à sua especificação,
assim como às prioridades dos stakeholders. Dentro desse contexto, a validação
estática visa à avaliação manual ou de forma automatizada em relação ao
código-fonte utilizado no programa. Já a validação dinâmica é empregada para
descobrir falhas no programa ou para demonstrar a capacidade do programa
de atender aos seus requisitos.
O procedimento de teste tende a ser direcionado pelo conhecimento do
código-fonte do programa, caso a verificação de falhas seja o principal obje-
tivo. As medições (métricas) de cobertura de testes servem para demonstrar o
nível de eficiência deles. Isso ocorre quando as declarações do código-fonte
forem realizadas.
Não existe grande diferença entre os procedimentos de teste realizados
em sistemas orientados a aspectos e aqueles realizados em outros sistemas.
Os testes são projetados para apresentar a capacidade do sistema de atender
aos requisitos. Se compararmos com a orientação a objetos, verificaremos
que esta trata do conjunto de atributos e classes que compõem um sistema de
informação. Porém, a utilização de aspectos traz uma série de problemas reais,
e o código-fonte do programa é utilizado para reconhecer potenciais de falhas.

Para planejar testes direcionados em um programa com certo nível de estrutura, como
os testes do código de um método, é possível recorrer a um fluxograma, iniciando-o
com um programa que apresenta os meios de execução baseados na lógica. Com isso,
é possível verificar o código e selecionar os parâmetros de entrada que permitirão a
execução do caminho.
 Engenharia de software orientada a aspectos 17

BORGES, F. S.; FREITAS, A. L. C. Estudo de caso sobre programação orientada a aspectos

utilizando protocolo RMI. Hífen, v. 32, n. 62, p. 41-50, 2008. Disponível em: http://revis-
taseletronicas.pucrs.br/ojs/index.php/hifen/article/view/4577. Acesso em: 2 jul. 2019.
CHIAVENATO, I. Introdução à teoria geral da administração: uma visão abrangente da
moderna administração das organizações. 7. ed. Rio de Janeiro: Campus, 2003.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Leitura recomendada
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio
de Janeiro. Elsevier, 2012.