O documento discute a separação de interesses como uma técnica essencial no desenvolvimento de software, abordando especialmente os interesses transversais que surgem durante o processo. Introduz a programação orientada a aspectos (POA) como um novo paradigma que utiliza abstrações chamadas 'aspectos' para lidar com preocupações que se cruzam em vários componentes do software. O artigo também descreve a importância da gestão desses interesses nas fases iniciais do ciclo de vida do desenvolvimento de software.

1. Engenharia de Software Orientada a Aspectos: do Interesse ao
Aspecto
Diego Antonio Lusa1
1
Instituto de Ciˆencias Exatas e Geociˆencias – Universidade de Passo Fundo (UPF)
Campus 1 - BR 285 - Passo Fundo (RS) - Brasil
{83473}@upf.br
Abstract. Separation of concerns is an indispensable resource for system de-
velopment. Sometimes, when separating interests, it is identified that some of
them intersect the others. This type of interest, known as crosscuting concern,
requires special treatment in the coding phase. This treatment occurs through
the aspect-oriented languages, which introduce an abstraction for crosscutting
concerns in implementation called aspects. To be properly mapped, aspects pro-
mote ease of maintenance and evolution, as well as higher levels of code reuse.
This paper present a literature review about concerns and aspects, with special
emphasis on Aspect-oriented Programming. Briefly, also describe the use of
aspectual programming in the development of Software Product Lines.
Resumo. A separac¸˜ao de interesses ´e um recurso indispens´avel ao desenvol-
vimento de sistemas. Por vezes, ao separar interesses, identifica-se que al-
guns deles entrecortam os demais. Esse tipo de interesse, conhecido como
transversal, requer um tratamento especial na fase de codificac¸˜ao. Esse tra-
tamento se d´a atrav´es das linguagens orientadas a aspectos, que introduzem `a
implementac¸˜ao uma abstrac¸˜ao para interesse transversal chamada aspecto. Ao
serem adequadamente mapeados, os aspectos promovem maior facilidade de
manutenc¸˜ao e evoluc¸˜ao, bem como maiores ´ındices de reuso de c´odigo. Neste
artigo apresenta-se uma revis˜ao bibliogr´afica acerca de interesses e aspectos,
com especial enfoque `a Programac¸˜ao Orientada a Aspectos. De modo sucinto,
descreve-se tamb´em o uso da programac¸˜ao aspectual no desenvolvimento de
Linhas de Produto de Software.
1. Introduc¸˜ao
O processo de desenvolvimento de software consiste basicamente de uma sequˆencia de
atividades que busca converter requisitos em uma soluc¸˜ao computacional. Por muitas
vezes, dadas as dimens˜oes do problema a ser resolvido e da natureza dos requisitos eli-
citados, o processo torna-se envolto por uma “nuvem” de complexidade, exigindo maior
esforc¸o e melhores t´ecnicas para alcanc¸ar as expectativas iniciais dos stakeholders.
Para lidar com a complexidade imposta ao desenvolvimento de um software pode-
se lanc¸ar m˜ao de t´ecnicas que facilitam sua construc¸˜ao. Uma destas t´ecnicas chama-
se separac¸˜ao de interesses que, segundo Sommerville [2011], “´e um princ´ıpio-chave de
projeto e implementac¸˜ao de um software”. O objetivo da separac¸˜ao de interesses ´e garantir
que cada elemento do programa seja respons´avel por somente um coisa, o que significa
dizer que estes elementos devem apresentar alta coes˜ao e baixo acoplamento entre si.

2. Contudo, mesmo havendo preocupac¸˜ao com a adequada separac¸˜ao de interes-
ses, o processo de construc¸˜ao dos componentes de um software pode ser afetado pela
ocorrˆencia de fenˆomenos indesejados, como o espalhamento e o embaralhamento, por
exemplo. Tanto o embaralhamento quanto o espalhamento s˜ao fenˆomenos prejudiciais
porque reduzem a manutenibilidade do sistema e as possibilidades de reuso dos compo-
nentes [Sommerville 2011]. Al´em disso, em determinadas situac¸˜oes, os paradigmas de
programac¸˜ao tradicionais, como a programac¸˜ao estruturada e a orientac¸˜ao a objetos n˜ao
oferecem mecanismos eficazes para tratar o embaralhamento e o espalhamento, o que
corrobora para tornar o problema ainda maior.
Em face desta problem´atica, um novo paradigma de programac¸˜ao foi concebido,
conhecido como Programac¸˜ao Orientada a Aspectos, ou simplesmente POA. Baseada
essencialmente no conceito de separac¸˜ao de interesses, a POA provˆe um novo tipo de
abstrac¸˜ao chamado aspecto, capaz de atacar um dos grandes vil˜oes do desenvolvimento
respons´avel pelos fenˆomenos indesejados, conhecido como interesse transversal. Pos-
teriormente, a proposta de separac¸˜ao dos aspectos espalhou-se pelas demais etapas do
ciclo de vida do software, como na engenharia de requisitos e desenho da arquitetura, por
exemplo.
Neste artigo, a separac¸˜ao de interesses ´e abordada em maiores detalhes na Sec¸˜ao
2. A seguir, na Sec¸˜ao 3, apresenta-se importantes t´opicos relacionados `a Engenharia
de Software Orientada a Aspectos, com especial enfoque `a POA e a sua aplicac¸˜ao na
construc¸˜ao de Linhas de Produtos de Software. Ao final, na Sec¸˜ao 4 s˜ao expostas as
impress˜oes e considerac¸˜oes a respeito do tema abordado.
2. Separac¸˜ao de Interesses
Decompor um problema em partes menores ´e uma ´otima forma de lidar com sua comple-
xidade. A separac¸˜ao de interesses ´e uma t´ecnica eficaz que faz uso deste princ´ıpio para dar
condic¸˜oes `a cognic¸˜ao humana de compreender e tratar ambientes complexos, atrav´es da
resoluc¸˜ao de um assunto importante por vez [Junior, 2008 apud Dijkstra,1976]. Ao consi-
derar apenas um assunto, consegue-se melhor ordenar os pensamentos e por conseguinte,
focar a atenc¸˜ao.
Para compreender o mecanismo de separac¸˜ao de interesses ´e necess´ario primei-
ramente ter claro o real significado de interesse dentro do contexto de desenvolvimento
de software. Sommerville [2011] e Jacobson e Ng [2004] entendem um interesse como
algo de importˆancia para um ou mais stakeholders. Por sua vez, Filmann [2004] afirma
que interesses podem ser compreendidos como conjuntos de requisitos relacionados ou
ainda como funcionalidades, caracter´ısticas ou tipos de processamento desejados para o
software.
Embora diferentes entre si, os conceitos apresentados por Sommerville [2011],
Jacobson e Ng [2004] e Filman [2004] permitem analisar um interesse sobre a ´otica de
atributos de valor. Estes atributos podem representar teoricamente qualquer coisa, pois
est˜ao atrelados aos anseios dos stakeholders acerca do software a ser desenvolvido. Desta
forma, limitar o conceito de interesse a requisitos puramente funcionais ou n˜ao-funcionais
n˜ao ´e correto, visto que seria plenamente poss´ıvel existirem interesses relacionados, por
exemplo, `a manutenc¸˜ao de uma boa reputac¸˜ao da marca ou ainda `a ades˜ao de determinado
padr˜ao de nomenclatura de vari´aveis, os quais n˜ao se encaixam adequadamente como um

3. requisito funcional ou n˜ao-funcional. De fato, al´em dos benef´ıcios t´ecnicos, identificar,
compreender e separar adequadamente os interesses vai ao encontro da satisfac¸˜ao das
necessidades dos stakeholders, algo fundamental em qualquer projeto de software.
Na perspectiva conceitual, a separac¸˜ao de interesses visa atender duas quest˜oes
fundamentais. A primeira delas ´e oferecer um mecanismo de abstrac¸˜ao que seja sufi-
cientemente capaz de tratar cada interesse como um conceito individual. J´a a segunda
quest˜ao trata de garantir que conceitos individuais sejam primitivos, ou seja, estejam as-
sociados a interesses naturais na mente do programador. J´a a n´ıvel de implementac¸˜ao, a
separac¸˜ao de interesses tem por objetivo prover uma forma de organizac¸˜ao que isole os
interesses uns dos outros, com vistas a reduzir o acoplamento entre os blocos de c´odigo
que implementam tais interesses [Filman 2005].
Os interesses oriundos dos stakeholders podem apresentar diferentes tipos. Som-
merville [2011] elenca cinco tipos distintos de interesses, os quais encontram-se descritos
abaixo:
• Interesses funcionais: Relacionados com as funcionalidades essenciais do sis-
tema.
• Interesses de qualidade de servic¸o: Relacionados a comportamentos n˜ao-
funcionais do sistema.
• Interesses de pol´ıtica: Referem-se `as regras de uso do sistema; seguranc¸a e regras
de neg´ocio.
• Interesses de sistema: Abordam o sistema como um todo; manutenibilidade e
configurabilidade s˜ao alguns exemplos.
• Interesses organizacionais: Relacionam o sistema com objetivos organizacio-
nais, tais como orc¸amento e reputac¸˜ao.
Al´em do seu agrupamento por tipo, os interesses podem ainda ser classificados
como centrais1
, secund´arios e transversais2
. Os interesses centrais referem-se aqueles
interesses de prop´osito prim´ario no sistema, relacionados com as funcionalidades ne-
cess´arias. Os interesses centrais podem receber apoio dos interesses secund´arios, na
forma de alguma funcionalidade compartilhada. J´a os interesses transversais s˜ao os assun-
tos que se estendem por todo o sistema, isto ´e, aqueles que naturalmente espalham-se por
todos os componentes do software. Os interesses secund´arios podem tamb´em apresentar-
se como interesses transversais, mas com amplitude reduzida em relac¸˜ao aos ´ultimos,
comumente limitados a alguns m´odulos do software [Sommerville 2011].
A quest˜ao principal que envolve os interesses transversais se resume a como mo-
dulariz´a-los, de modo a separ´a-los dos interesses centrais do sistema. As abordagens
tradicionais de desenvolvimento, como a orientac¸˜ao a objetos, por exemplo, s˜ao eficazes
no trato aos interesses centrais, mas se mostram ineficazes quando o assunto ´e interesses
transversais [Jacobson and Ng 2004]. Exemplo disso ´e a ocorrˆencia dos fenˆomenos de
embaralhamento e espalhamento na implementac¸˜ao de muitos softwares.
Quando ocorre embaralhamento3
, um ´unico m´odulo do sistema inclui c´odigo de
diversos requisitos. J´a no caso do espalhamento4
, um ´unico requisito ou conjunto deles
1
Do inglˆes core concern.
2
Do inglˆes crosscuting concern.
3
Do inglˆes tangling.
4
Do inglˆes scattering

4. tem sua implementac¸˜ao espalhada por diversos componentes [Sommerville 2011]. Am-
bos os fenˆomenos s˜ao apresentados esquematicamente pela Figura 1.
Figura 1. Diagrama esquem´atico dos fenˆomenos do espalhamento e embaralha-
mento. No M´odulo A, os requisitos 1, 2 e 3 encontram-se embaralhados entre si.
J´a no M´odulo B, o requisito 2 encontra-se espalhado, visto que tem parte de sua
implementac¸ ˜ao no M´odulo A e parte no M´odulo B. Fonte prim´aria.
A lacuna deixada pelos paradigmas de programac¸˜ao existentes no trato a interes-
ses transversais trouxe `a tona a necessidade por um novo paradigma de programac¸˜ao.
Este novo paradigma deveria ser capaz de fornecer a atividade de codificac¸˜ao um meca-
nismo eficaz para mapear interesses transversais. Isso veio a ocorrer em 1997, quando a
Programac¸˜ao Orientada a Aspectos foi apresentada `a comunidade pela Xerox Corpora-
tion5
.
3. Engenharia de Software Orientada a Aspectos
As pesquisas por um meio eficaz de tratar interesses transversais durante a codificac¸˜ao de
um software tiveram uma importante contribuic¸˜ao quando, em 1997, Gregor Kickzales
em conjunto com um grupo de cientistas do Xerox Palo Alto Research Center (PARC),
propuseram um novo paradigma de programac¸˜ao, chamado Programac¸˜ao Orientada a As-
pectos (POA). Este novo paradigma tinha por objetivo justamente solucionar a lacuna
deixada pela programac¸˜ao orientada a objetos na quest˜ao de tratamento dos interesses
transversais [Casachi and Camolesi 2012].
Interessante observar que as preocupac¸˜oes relacionadas ao tratamento de interes-
ses transversais mantiveram-se focadas inicialmente na etapa de implementac¸˜ao. Com o
passar do tempo e na contram˜ao da sequˆencia natural das fases do ciclo de vida de um
software, buscou-se tratar os interesses transversais nas fases iniciais de descoberta de re-
quisitos e desenho de arquitetura. Em vista disso, entender o paradigma da programac¸˜ao
a aspectos torna-se pr´e-requisito para a compreens˜ao do papel desempenhado pela desco-
berta antecipada dos interesses transversais dentro da Engenharia de Software como um
todo.
5
Empresa norte-estadunidense de tecnologia de informac¸˜ao criada em 1906.

5. 3.1. Programac¸˜ao Orientada a Aspectos (POA)
Jacobson e Ng [2004], ao falar sobre desenvolvimento de software orientado a aspectos,
descrevem um interesse transversal como uma redundˆancia na codificac¸˜ao, um trecho de
c´odigo de mesma func¸˜ao que se espalha por diversas classes. Ainda segundo os auto-
res, a chave para solucionar o problema dos interesses transversais est´a em dois pontos
fundamentais, que s˜ao:
• Dispor de uma t´ecnica de engenharia capaz de separar os interesses dos requisitos.
• Dispor de um mecanismo de composic¸˜ao capaz de unir interesses durante as fases
de projeto e codificac¸˜ao para compor o sistema desejado.
A Programac¸˜ao Orientada a Aspectos, no que diz respeito ao segundo ponto elen-
cado por Jacobson e Ng [2004], se apresenta como um paradigma eficaz de composic¸˜ao
de interesses transversais durante a codificac¸˜ao de um software. Dentro do arcabouc¸o
te´orico da POA, um interesse transversal ´e representado atrav´es de uma abstrac¸˜ao cha-
mada aspecto, que descreve uma restric¸˜ao cruzada que tem impacto em toda a arquitetura
do sistema [Pressman 2011]. O conceito de aspecto traz consigo novos elementos ao
processo de codificac¸˜ao de um software, al´em daqueles j´a conhecidos e difundidos pela
programac¸˜ao estruturada e orientada a objetos.
Conforme explica Sommerville [2011], um aspecto cont´em a definic¸˜ao de um
ponto de corte e do adendo associado. Desta forma, aspectos tornam-se abstrac¸˜oes total-
mente distintas de outras existentes porque incluem formalmente a especificac¸˜ao de onde
devem ser executados dentro do programa.
Para que determinado aspecto seja unido ao c´odigo ´e necess´ario haver um ponto de
junc¸˜ao especificado, que permita identificar o exato momento na execuc¸˜ao do programa
em que a implementac¸˜ao do interesse transversal ´e requerida. Este ponto de junc¸˜ao ´e
um evento de interesse na execuc¸˜ao do programa que est´a presente no modelo de pontos
de junc¸˜ao especificado pela linguagem de programac¸˜ao aspectual [Filman 2005]. Seu
funcionamento se assemelha a um gatilho com capacidade para disparar a execuc¸˜ao de
um adendo quando atendidas as condic¸˜oes definidas pelos pontos de corte. S˜ao exemplos
de pontos de junc¸˜ao a execuc¸˜ao de um m´etodo, a chamada a um construtor ou um acesso
de leitura a um atributo de uma classe.
Atuando como um adesivo entre o ponto de junc¸˜ao e seus respectivos adendos
est˜ao os pontos de corte. Na func¸˜ao de predicados, eles estabelecem as condic¸˜oes em que
determinado adendo pode ser unido ao ponto de junc¸˜ao [Filman 2005]. Por sua vez, o
adendo designa a sequˆencia de comandos que devem ser unidos ao ponto de junc¸˜ao, se
atendido os crit´erios definidos pelos pontos de corte. Portanto, ´e o adendo que cont´em a
implementac¸˜ao do aspecto que representa o interesse transversal considerado.
Ainda sobre os adendos, pode-se condicion´a-los a modificadores que alteram o
ponto onde o c´odigo que implementa o aspecto ser´a unido ao ponto de junc¸˜ao. ´E poss´ıvel
definir se a uni˜ao ir´a ocorrer, por exemplo, antes, depois ou em torno do ponto de junc¸˜ao
identificado [Sommerville 2011].
A Figura 2 apresenta o diagrama esquem´atico do relacionamento entre eventos,
pontos de junc¸˜ao, pontos de corte e adendos. A partir dele torna-se poss´ıvel identi-
ficar algumas importantes relac¸˜oes entre os elementos fundamentais do paradigma da
Programac¸˜ao Orientada a Aspectos. Estas relac¸˜oes encontram-se descritas na sequˆencia.

6. • Nem todo evento tem associado um ponto de junc¸˜ao. Portanto, o modelo de pontos
de junc¸˜ao ´e um subconjunto do conjunto de eventos de um programa.
• Um ponto de junc¸˜ao pode ter nenhum, um ou v´arios pontos de corte relacionados.
• Um ponto de corte sempre tem associado a si um e somente um adendo.
• Um adendo requer a existˆencia de um ponto de corte e de um ponto de junc¸˜ao
definidos.
Figura 2. Diagrama esquem´atico do relacionamento entre eventos, pontos de
junc¸ ˜ao, pontos de corte e adendos. Fonte prim´aria.
A responsabilidade de incluir os adendos aos pontos de junc¸˜ao definidos pelos
pontos de corte fica a cargo de um compositor6
. O compositor atua como uma extens˜ao
do compilador que processa todos os constructos aspectuais presentes no c´odigo-fonte
da aplicac¸˜ao com objetivo de gerar uma nova vers˜ao do c´odigo que contenha os aspec-
tos integrados nos seus respectivos pontos de junc¸˜ao, perfazendo um processo chamado
composic¸˜ao.
Segundo Sommerville [2011], o processo de composic¸˜ao pode ocorrer por
pr´e-processamento, em tempo de execuc¸˜ao e por ligac¸˜ao. Na abordagem de pr´e-
processamento, o c´odigo-fonte ´e pr´e-processado pelo compositor de aspectos, o qual gera
uma nova vers˜ao de c´odigo-fonte pass´ıvel de compilac¸˜ao pelo compilador da pr´opria lin-
guagem de programac¸˜ao utilizada. J´a na composic¸˜ao em tempo de execuc¸˜ao, os pontos
de junc¸˜ao s˜ao monitorados durante a execuc¸˜ao do programa, ocorrendo dinamicamente
a integrac¸˜ao do adendo quando houver ponto de corte definido. O ´ultimo e, segundo o
autor, mais utilizado dos m´etodos, ´e a composic¸˜ao por ligac¸˜ao, na qual o compositor est´a
integrado ao compilador na forma de uma extens˜ao.
3.2. Captura antecipada de aspectos
Os aspectos e toda sua conceituac¸˜ao correlata teve impacto inicialmente na fase de
codificac¸˜ao dos projetos de software. Durante este per´ıodo, os interesses transversais
6
Do inglˆes weaver

7. n˜ao tinham qualquer distinc¸˜ao dos interesses centrais na fase de an´alise de requisitos ou
de projeto. Com o passar do tempo, a necessidade de se obter antecipadamente os inte-
resses transversais no processo de desenvolvimento de software tornou-se evidente. Foi
neste momento que as linguagens aspectuais deixaram de figurar no papel principal e pas-
saram a ser vistas como ferramentas de apoio, respons´aveis por perpetuar a separac¸˜ao de
interesses para as demais fases do desenvolvimento [Sommerville 2011].
Jacobson e Ng [2004], ao discutirem sobre a obtenc¸˜ao antecipada dos aspectos,
afirmam ser necess´ario dispor de t´ecnicas para identificar, capturar e estruturar os interes-
ses transversais enquanto requisitos, a fim de preservar nas fases subsequentes de an´alise,
projeto e codificac¸˜ao a separac¸˜ao inicialmente obtida. Esse processo de coleta antecipada
dos aspectos de um software, em fases que antecedem a codificac¸˜ao, ´e conhecido como
aspectos antecipados7
.
Para Baniassad et al. [2006], a coleta antecipada de aspectos permite encontrar
interesses transversais a n´ıvel de requisitos e de arquitetura. Na fase de requisitos, um as-
pecto apresenta-se como um interesse que entrecorta artefatos de requisitos. J´a na fase de
projeto da arquitetura, um aspecto mostra-se como um interesse que entrecorta artefatos
de arquitetura. Os benef´ıcios obtidos com a captura antecipada de aspectos, segundo os
autores, seriam:
• Aumentar a consistˆencia dos requisitos com o desenho da arquitetura e destes
com a implementac¸˜ao: Ao considerar os aspectos antecipadamente nas fases de
requisitos e de desenho da arquitetura se obt´em um melhor discernimento para a
fase de implementac¸˜ao, visto que nestas etapas iniciais a vis˜ao sobre o software
tem uma amplitude maior.
• Prover rastreabilidade dos aspectos durante todas as atividades do ciclo de
vida do software: Os aspectos presentes nos requisitos introduzem aspectos na
arquitetura e estes, por sua vez na implementac¸˜ao. Identificando-os em sua ori-
gem, torna-se poss´ıvel rastrear sua presenc¸a em todas as fases do ciclo de vida.
• Assegurar maior garantia de que todos os interesses transversais ser˜ao cap-
turados como aspectos na fase de implementac¸˜ao: Naturalmente, ao capturar
inicialmente os interesses transversais diminui-se a chance de omiss˜ao de aspectos
na fase de implementac¸˜ao.
3.3. Programac¸˜ao Orientada a Aspectos aplicada ao desenvolvimento de Linhas de
Produtos de Software
Os benef´ıcios dos aspectos antecipados, assim como do paradigma da programac¸˜ao ori-
entada a aspectos podem ser de grande valia tamb´em para o processo de desenvolvimento
de Linhas de Produto de Software (LPS). Uma LPS “consiste de um conjunto de siste-
mas de software que compartilham caracter´ısticas comuns e satisfazem as necessidades
espec´ıficas de um segmento particular”[J´unior 2008].
Segundo J´unior[2008], a Programac¸˜ao Orientada a Aspectos combinada `a En-
genharia de Linhas de Produto de Software soluciona problemas de modularizac¸˜ao de
interesses transversais, reduz o impacto sobre o c´odigo-base da arquitetura e facilita a
combinac¸˜ao de interesses comuns e variantes no processo de instanticac¸˜ao de novos mem-
bros da LPS.
7
Do inglˆes early aspects

8. Fazendo uso da separac¸˜ao de aspectos, a gerac¸˜ao de produtos de uma LPS passa
a utilizar a combinac¸˜ao de um dom´ınio base e de v´arios dom´ınios transversais. O uso de
dom´ınios transversais aumenta o reuso de artefatos entre diferentes linhas de produtos,
trazendo benef´ıcios ao processo. No trabalho proposto por J´unior[2008], o desenvolvi-
mento de LPSs em combinac¸˜ao com os aspectos ´e auxiliado por uma ferramenta chamada
Captor-AO. Maiores detalhes acerca do processo proposto, bem como do funcionamento
da ferramenta Captor-AO podem ser encontrados no decorrer do estudo apresentado pelo
autor.
4. Considerac¸˜oes Finais
Conforme visto, a separac¸˜ao de interesses ´e uma t´ecnica eficaz para contornar a complexi-
dade de problemas. Um dos principais benef´ıcios quem adv´em da separac¸˜ao de interesses
´e a identificac¸˜ao dos interesses (ou assuntos) transversais. Comparados aos demais tipos
de interesses, os transversais s˜ao os mais dif´ıceis de se isolar em m´odulos durante a fase de
codificac¸˜ao, logo apresentam-se como a principal causa dos fenˆomenos do espalhamento
e embaralhamento durante o desenvolvimento.
Tanto o paradigma estruturado quanto o da orientac¸˜ao a objetos n˜ao disp˜oem de
abstrac¸˜oes suficientemente completas para tratar os interesses transversais. Em vista desta
lacuna, surgiu um novo paradigma, conhecido como Programac¸˜ao Orientada a Aspectos,
o qual trouxe `a implementac¸˜ao um conjunto de novos conceitos, dentre eles, os aspectos.
Na POA, os aspectos s˜ao abstrac¸˜oes para interesses transversais. No decorrer
da codificac¸˜ao, a implementac¸˜ao dos aspectos ´e feita de forma separada em relac¸˜ao aos
pontos de junc¸˜ao onde s˜ao necess´arios. Como o aspecto cont´em a definic¸˜ao exata do
ponto de execuc¸˜ao, um processo de composic¸˜ao faz a agregac¸˜ao dele com o restante do
c´odigo.
Seguindo na contram˜ao do ciclo de vida do software, a preocupac¸˜ao pela
separac¸˜ao de aspectos, inicialmente concentrada na fase de codificac¸˜ao, passou a tornar-
se presente na etapa de requisitos e desenho de arquitetura. Esse processo de descoberta
antecipada dos aspectos trouxe benef´ıcios ao processo de desenvolvimento, em especial
ao prover uma vis˜ao mais detalhada do aspecto e seus impactos por todas as fases do ciclo
de vida.
Pode-se observar tamb´em a aplicac¸˜ao da Programac¸˜ao Orientada a Aspectos na
construc¸˜ao de Linhas de Produtos de Software. Como um dos benef´ıcio de sua aplicac¸˜ao
neste universo, tornou-se poss´ıvel reutilizar dom´ınios transversais em diferentes linhas de
produtos. As instˆancias das LPSs poderiam ent˜ao ser constru´ıdas a partir de um dom´ınio-
base associado a v´arios dom´ınios transversais.
Por fim, foi poss´ıvel perceber que a orientac¸˜ao a aspectos ´e ainda incipiente na
Engenharia de Software. S˜ao necess´arios maiores estudos para torn´a-la uma t´ecnica mais
madura e confi´avel, que apresente aderˆencia `a todas as fases do ciclo de vida do software,
em especial `as etapas que antecedem a codificac¸˜ao, como a engenharia de requisitos e
desenho de arquitetura, por exemplo.
Referˆencias
Baniassad, E., Clements, P. C., Rashid, A., and Tekinerdo, B. (2006). Discovering early
aspects. IEEE Software, (23):61–70.

9. Casachi, R. and Camolesi, A. R. (2012). Uso de programac¸˜ao orientada a aspectos no de-
senvolvimento de aplicac¸˜oes que utilizam conceitos de tecnologia adaptativa. Revista
de Sistemas e Computac¸˜ao, (2).
Filman, R. E. (2005). Aspect-oriented software development. Addison-Wesley.
Jacobson, I. and Ng, P.-W. (2004). Aspect-Oriented Software Development With Use
Cases. Addison Wesley, 7 edition.
J´unior, C. A. d. F. P. (2008). Gerac¸˜ao de aplicac¸˜oes para linhas de produtos orientadas a
aspectos com apoio da ferramenta Captor-AO.
Pressman, R. S. (2011). Engenharia de software: uma abordagem profissional. McGraw
Hill, 7 edition.
Sommerville, I. (2011). Engenharia de software. Addison-Wesley, 9 edition.