A

Programao Orientada a Aspectos

A.1 Introduo
medida que aumenta a complexidade dos sistemas de software surge a necessidade de melhores tcnicas de programao, objetivando organizar e apoiar o processo de desenvolvimento de software. Com isso, no mbito da Cincia da Computao, essas tcnicas de programao tm evoluindo desde construes de baixo nvel como linguagens de mquina at abordagens de alto nvel como Programao Orientada a Objetos (POO) [Elrad et al., 2001]. Segundo [Gradeck and Lesiecki, 2003], a engenharia de software e as linguagens de programao possuem um relacionamento mtuo. Os sistemas so considerados pela maioria dos processos de desenvolvimento de software como unidades (mdulos) cada vez menores. Enquanto, as linguagens de programao fornecem meios para definir e compor abstraes das unidades do sistema de diversas maneiras para produo do sistema como um todo. Em meados da dcada de 70, com o advento de um novo paradigma de programao, a Programao Orientada a Objetos (POO), teve grandes avanos no desenvolvimento de software at os dias atuais, sendo atualmente, o paradigma de programao dominante no desenvolvimento de sistemas de software [Laddad, 2003]. Este paradigma possibilitou a construo de sistemas particionados em mdulos (classes) que trabalham em conjunto para fornecer funcionalidades especficas de um conjunto de requisitos do sistema com responsabilidades bem definidas, permitindo maiores nveis de reuso e manutenibilidade [Gradeck and Lesiecki, 2003]. O princpio da separao de interesses (concerns) foi introduzido em [Dijkstra, 1976], tendo como objetivo dividir o domnio do sistema em partes menores com o intuito de entender melhor cada parte isoladamente. Um interesse (concern) alguma parte do domnio do sistema que se deseja tratar com uma unidade conceitual nica. No desenvolvimento de software, um interesse pode ser visto como um requisito funcional ou no funcional de um sistema. De forma geral, os vrios interesses do sistema devem ser separados em mdulos modularizados de acordo com as abstraes do desenvolvimento de software providas por linguagens, mtodos e ferramentas. Pode-se classificar os interesses de um sistema de software como [Laddad, 2003]:

 Interesses do negcio - capturam a funcionalidade central de um mdulo, por exemplo, procedimento de quitao de uma compra; Interesses em nvel de sistema - capturam requisitos perifricos, no nvel do sistema e que atravessam mltiplos mdulos, por exemplo, segurana, logging, persistncia. A POO permitiu uma melhor separao dos diversos interesses do sistema, com a estruturao de projetos e cdigos mais prximos do que idealizado naturalmente pelos desenvolvedores [Elrad et al., 2001]. No caso da POO, as abstraes bsicas para os interesses so classes, objetos, mtodos e atributos. Entretanto, essas abstraes podem no ser suficientes para separar em um nico mdulo, alguns dos interesses contidos em muitos sistemas de software complexos, tendo assim os comportamentos distribudos ao longo de vrios e, s vezes no relacionados, mdulos. Esses interesses so chamados de interesses transversais (crosscutting concerns), j que, inerentemente, a sua implementao se d atravs da adio de cdigo em diversos objetos ao longo do software no estando diretamente relacionado com a funcionalidade definida pra estes objetos. Desta forma, a implementao mapeia os requisitos em uma nica dimenso como pode ser visualizado na Figura 1. Podemos citar como exemplos de interesses transversais logging, integridade de transaes, autenticao, segurana, desempenho, distribuio, persistncia e profiling [Elrad et al., 2001].

Figura 1 Mapeamento de um interesse transversal sem o uso da Programao Orientada a Aspectos.

Como exemplo de um interesse transversal, utilizaremos um editor de figuras apresentado em [Elrad et al., 2001]. O sistema de edio de figuras composto por duas classes concretas de elementos de figura, pontos e linhas. Sempre que os elementos da 2

figura forem movimentados, necessrio que a tela seja atualizada. Desta maneira, observa-se atravs do diagrama de classes apresentado na Figura 2, que o interesse de atualizao da tela no pertence a nenhuma das duas classes (Ponto e Linha), mas entrecorta ambas e, por isso, pode ser entendido como transversal a essas classes [Elrad et al., 2001].

Figura 2 Interesse transversal de atualizao da tela (adaptado de [Elrad et al., 2001]).

Sem o uso de tcnicas apropriadas para a separao de interesses e modularizao, alguns fenmenos so observados e podem ser classificados nas seguintes categorias: Cdigo entrelaado (code tangling) - acontece quando a implementao de um mdulo em um sistema de software interage simultaneamente com vrios interesses, tais como logging, autenticao, multi-threaded safety, validaes, entre outras. Na Figura 3 ilustrado o cdigo entrelaado em um mdulo, causado pela execuo simultnea de mltiplos interesses.

Figura 3 Cdigo entrelaado causado pela execuo simultnea de mltiplos interesses [Laddad, 2003].

Cdigo espalhado (code scattering) - acontece quando um interesse implementado em mltiplos mdulos. Desde que interesses transversais, por 3

definio, so espalhados por vrios mdulos, logo sua implementao tambm se espalha por esses mdulos. Por exemplo, considere o mecanismo de logging, fazendo uso das classes do Apache TomCat, um servidor web baseado em Java. Na Figura 4 as colunas representam cada uma das classes do sistema e, a linhas grifadas so referentes funcionalidade de logging.

Figura 4 Interesse de logging no TomCat.

A implementao de cdigos entrelaados e espalhados afetam o desenvolvimento do software de diversas maneiras: Forte acoplamento - mtodos das classes primrias precisam conhecer mtodos das classes que implementam funcionalidades espalhadas (crosscutting concerns); Fraca coeso - mtodos das classes afetadas contm instrues que no esto diretamente relacionadas a funcionalidades que implementam; Redundncia - muitos fragmentos de cdigo semelhantes ocorrem em diversos pontos do cdigo-fonte; Dificuldades de compreender, manter e reusar - como consequncia da implementao de crosscutting concerns ser dependente do cdigo espalhado pelo software, sua compreenso, manuteno e reutilizao ficam prejudicadas. Contudo, parte dessas limitaes podem ser solucionadas com o uso de tcnicas com o intuito de modularizar o desenvolvimento de software incluindo mix-in classes, padres de projeto, solues especficas de domnio. Por outro lado, existem algumas extenses do paradigma POO que tentam solucionar suas limitaes visando uma maior 4

modularidade de software, tais como Aspect-Oriented Programming (Programao Orientada a Aspectos) [Kiczales et al., 1997], Subject-Oriented Programming (Programao Orientada a Sujeito) [Osser and Tarr, 1999] e Adaptive Programming (Programao Adaptativa) [Lieberherr et al., 1994]. Dentre essas extenses a que tem se mostrado mais promissora a Programao Orientada a Aspectos (POA) [Elrad et al., 2001]. A POA foi proposta em [Kiczales et al., 1997] como uma tcnica objetivando melhorar o suporte modularizao dos interesses transversais por meio de abstraes que possibiltem a separao e composio destes interesses na construo dos sistemas de software.

A.2 Desenvolvimento de Software Orientado a Aspectos

A POA foi proposta com o objetivo de facilitar a modularizao dos interesses transversais, complementando a POO. A POA no tem o intuito de ser um novo paradigma de programao, mas uma nova tcnica que deve ser utilizada em conjunto com linguagens de programao para construo de sistemas de software de melhor arquitetura, auxiliando na manuteno dos vrios interesses e a compreenso do software. Entretanto, no um antdoto para um design ruim ou insuficiente [Elrad et al., 2001]. Em um sistema de software os interesses so implementados em blocos de cdigo, que manipulam dados. Os interesses que podem ser encapsulados de forma clara em uma unidade de funo so chamados de componentes. Em POO esses interesses so modularizados em objetos, compostos por mtodos que contm a implementao do interesse, e os atributos compostos pelos dados manipulados pelos mtodos. Em POA introduzido um novo mecanismo para abstrao e composio, que facilita a modularizao dos interesses transversais, o aspecto (aspect). Desta forma, os sistemas de software so decompostos em componentes e aspectos. Assim, os requisitos funcionais normalmente so organizados em componentes atravs de uma linguagem POO, como Java, e os requisitos no funcionais como aspectos relacionados as propriedades que afetam o comportamento do sistema [Kiczales et al., 1997]. A POA envolve basicamente trs etapas distintas de desenvolvimento: Decompor os interesses (aspectual decomposition) identificar e separar os interesses transversais dos interesses do negcio; 5

 Implementar os interesses (concern implementation) implementar cada um dos interesses identificados separadamente; Recompor o aspectual (aspectual recomposition) nesta etapa, tem-se integrador de aspectos que especifica regras de recomposio para criao de unidades de modularizao aspectos. A esse processo de juno da codificao dos componentes e dos aspectos denominada combinao (weaving). Na Figura 5, ilustrado as etapas de desenvolvimento da POA.

Figura 5 Etapas de desenvolvimento de software orientado a aspectos [Laddad, 2003].

Uma implementao de POA consiste dos seguintes elementos [Kiczales et al., 1997]: Linguagem de componentes responsvel por implementar interesses do negcio do sistema de software, por exemplo, Java; Linguagem de aspecto deve suportar a implementao de interesses transversais de forma clara e concisa, fornecendo meios para construo de estruturas que descrevam o comportamento do aspecto e definam em que situaes estes ocorrem, por exemplo, AspectJ; Combinador de aspectos sua tarefa combinar aspectos (aspect weaver) com programas escritos na linguagem de componentes com os programas escritos na linguagem de aspectos. As linguagens de aspectos so classificadas em linguagens de propsito especfico e de propsito geral. Como o prprio nome diz, as linguagens de propsito especfico tratam somente de determinados aspectos, impondo geralmente algumas restries quanto ao uso das linguagens de componentes. Por outro lado, as linguagens de propsito geral permitem a implementao de qualquer tipo de aspecto, sendo de uso 6

mais familiar e de fcil adoo pelos desenvolvedores, uma vez que geralmente a linguagem de aspecto compartilha o mesmo ambiente de desenvolvimento utilizado pela linguagem de componente [Kiczales et al., 2001]. No contexto deste trabalho ser abordada como linguagem de componentes a linguagem Java e no contexto da linguagem de aspecto a linguagem AspectJ.

A.3 AspectJ
A linguagem AspectJ [Kiczales et al., 2001] uma extenso orientada a aspectos de propsito geral da linguagem Java. Foi criada pela Xerox Palo Alto Research Center em 1997 e posteriormente agregada ao projeto Eclipse da IBM EM 2002. Alm dos elementos oferecidos pela POO como classes, mtodos, atributos e etc, so acrescentados novos conceitos e construes ao AspectJ, tais como: aspectos (aspects), conjuntos de juno (point cuts), pontos de juno (join points), adendos (advices) e declaraes inter-tipos (inter-type declarations)1. Aspects so os elementos bsicos dessa abordagem, pois podem alterar a estrutura esttica ou dinmica de um programa. A estrutura esttica alterada adicionando, por meio das declaraes inter-tipos, membros (atributos, mtodos ou construtores) a uma classe, modificando assim a hierarquia do sistema. J a alterao numa estrutura dinmica de um programa ocorre em tempo de execuo por meio dos conjuntos de juno, os quais so selecionados por pointcuts, e atravs da adio de comportamentos (adendos) antes ou depois dos pontos de juno [Kiselev, 2002]. A seguir, so apresentados cada um dos conceitos e construes que compem o AspectJ. A.3.1 Pontos de Juno (Join Points) Para o entendimento do AspectJ de fundamental importncia o conceito de ponto de juno. Pontos de juno so pontos na execuo de um programa de componentes aonde os aspectos sero aplicados. O AspectJ pode detectar e operar sobre os seguintes tipos de pontos de juno [Gradecki and Lesiecki, 2003]: chamada e execuo de mtodos; chamada e execuo de construtores;
1

As tradues utilizadas neste trabalho seguem as recomendaes definidas no WASP 2004 1 Workshop Brasileiro de Desenvolvimento de Software Orientado a Aspectos, disponveis em http://twiki.im.ufba.br/bin/view/AOSDbr/TermosEmPortugues

 execuo de inicializao; execuo de contrutores; execuo de inicializao esttica; pr-inicializao de objetos; inicializao de objetos; referncia a campos; execuo de tratamento de excees. Na Figura 6, demonstrado um exemplo apresentado em [Soares and Borba, 2002], de um fluxo de execuo entre dois objetos, identificando alguns pontos de juno.

Figura 6 Pontos de juno de um fluxo de execuo [Kiczales et al., 2001].

O primeiro ponto de juno a invocao de um mtodo de um objeto A, o qual pode retornar sucesso ou lanar uma exceo. O prximo ponto de juno a execuo deste mtodo, que por sua vez tambm pode retornar sucesso ou lanar uma exceo. Durante a execuo do mtodo do objeto A invocado um mtodo de um objeto B, podendo retornar sucesso ou lanar uma exceo. A invocao e execuo destes mtodos so pontos de juno. A.3.2 Conjuntos de Juno (Pointcuts) Um aspecto no AspectJ geralmente define conjuntos de juno, que so aninhados por pontos de juno atravs de operadores lgicos e, ou e no (&&, ||, e !). Eles so responsveis por selecionar pontos de juno, ou seja, eles detectam em que ponto do programa os aspectos devero interceptar. 8

Podemos declarar um conjunto de juno semelhante a uma classe em Java, podendo da mesma maneira que atributos e mtodos dessas classes, especificar um quantificador de acesso aos conjuntos de juno, podendo ser pblicos, privados ou final, mas no podem ser sobrecarregados. Tambm podem ser declarados abstratos, mas somente dentro de aspectos abstratos, e ainda podem ser nomeados ou annimos [Kiselev, 2002]. A declarao de um pointcut nomeado deve seguir a seguinte sintaxe:
pointcut <Nome> (Argumentos): <corpo>;

Para definir um conjunto de juno utiliza-se construtores de AspectJ nomeados de designadores, os principais esto listados na Tabela 1:
Tabela 1 Listagem dos designadores em AspectJ.

Designador Call(Signature) Execution(Signature) Get(Signature) Set(Signature) This(Type pattern) Target(Type pattern) Args(Type pattern) Within(Type pattern)

Caractersticas Invocao do mtodo / construtor identificado por assinatura Execuo do mtodo / construtor identificado por assinatura Acesso a atributo identificado por assinatura Atribuio assinatura do atributo identificado por

Objeto em execuo instncia do padro tipo Objeto de destino instncia do padro tipo Os argumentos so instncia do padro tipo O cdigo em execuo est definido em padro tipo

Em AspectJ elementos wildcards so utilizados, estes permitem que em especificaes de assinatura (signature) sejam definidos o nmero de caracteres (*) e o nmero dos argumentos (..). Por exemplo: public void set*(.., String), isto ir refletir sobre todos os mtodos que iniciam com a palavra set e que tenham zero ou mais argumentos como parmetro. E em padro tipo (type pattern) utilizam-se os seguintes wildcards: * - qualquer seqncia de caracteres no contendo pontos; .. qualquer seqncia de caracteres, inclusive pontos; + qualquer subclasse de uma classe.

A.3.3 Adendos (Advices) Adendos o cdigo para ser executado em um ponto de juno que est sendo referenciado pelo conjunto de juno. Existem trs maneiras de adendos: antes, durante e depois (before, around e after). Portanto, de acordo com seus nomes, before executa antes do ponto de juno, around executa antes e depois e after executa depois. O adendo pode modificar a execuo do cdigo no ponto de juno, pode substituir ou passar por ele. Usando o adendo pode-se logar as mensagens antes de executar o cdigo de determinados pontos de juno que esto espalhados em diferentes mdulos. O corpo de um adendo muito semelhante ao de qualquer mtodo, encapsulando a lgica a ser executada quando um ponto de juno alcanado [Gradecki and Lesiecki, 2003]. A.3.4 Declaraes Inter-tipos (Inter-type Declarations) O AspectJ prov uma maneira de alterar a estrutura esttica de uma aplicao, isto ocorre por meio das declaraes inter-tipos que so descritas como interesses estticos (static crosscutting). Estas declaraes provm uma construo chamada Introduction. Introduction um interesse esttico que introduz alteraes nas classes, interfaces e aspectos do sistema. Alteraes estticas em mdulos no tm efeito direto no comportamento. Por exemplo, pode ser adicionado um mtodo ou um atributo na classe [Gradecki and Lesiecki, 2003]. A.3.5 Aspectos (Aspects) Da mesma maneira que a classe a unidade central em Java, aspecto a unidade central do AspectJ. Aspectos encapsulam conjuntos de juno (point cuts), adendos (advices) e declaraes inter-tipos (inter-type declarations) em uma unidade modular de implementao. Assim como as classes em Java, os aspectos podem conter atributos, mtodos e classes internas. Aspectos podem alterar a estrutura esttica de um sistema adicionando membros (atributos, mtodos e construtores) a uma classe, alterando a hierarquia do sistema, e convertendo uma exceo checada por uma no checada (exceo de runtime). Esta caracterstica de alterar a estrutura esttica de um programa chamada static crosscutting. Alm de afetar a estrutura esttica, um aspecto tambm pode afetar a estrutura dinmica de um programa. Isto possvel atravs da interceptao pontos de

10

juno, e da adio de comportamento antes ou depois dos mesmos, ou ainda atravs da obteno de total controle sobre o ponto de execuo [Soares and Borba, 2002]. A.3.6 Exemplo Para exemplificao do uso de aspectos utilizaremos um exemplo didtico apresentado em [Elrad et al., 2001]. Este exemplo um sistema simples de elementos grficos. Como pode ser observado na Figura 7 formado pelas classes Ponto, Linha e
Tela,

alm de ElementoDeFigura e Figura.

Figura 7 Diagrama de classes do editor de figuras.

Relembrando os conceitos bsicos vistos nos tpicos anteriores em AspectJ, tm-se: Pontos de juno (joint points) pontos na execuo de programas Java; Conjuntos de juno (pointcuts) especificao de pontos de juno; Adendo (advice) especificao de comportamento que afeta o programa em seus pontos de juno; Declaraes inter-tipo (inter-type declarations) declaraes de membros e relaes entre classes que afetam a estrutura e hierarquia de classes do programa; Aspectos (aspects) unidade que modulariza um interesse transversal, contendo declaraes inter-tipo, adendos, conjuntos de juno, atributos, mtodos e construtores. Na Figura 8, so apresentadas as implementaes em Java das classes Ponto e
Linha

sem o uso de POA. Observa-se que aps a chamada dos mtodos setX e setY da 11

classe Ponto e dos mtodos setP1 e setP2 da classe Linha se faz necessrio a invocao do mtodo atualiza da classe Tela.

Figura 8 Implementao em Java de editor de figuras.

Desta forma, a invocao do mtodo atualiza fica espalhada pelos quatro mtodos. Portanto, visando a moduralizao desse interesse deve-se fazer uso de AspectJ, ficando este interesse localizado no aspecto AtualizaTela. Para isso, deve-se seguir os seguintes passos: 1. Identificar os pontos de juno. Um ponto de juno um ponto bem definido no fluxo de execuo de um programa. No caso do AspectJ, este tem suporte a um modelo de pontos de juno dinmico, ou seja, que ocorrem durante a execuo de programa Java. Considerando o editor de figuras apresentado na Figura 9 a identificao dos pontos de juno no caso de mover uma linha.

Figura 9 Pontos de juno no fluxo de execuo do editor de figuras.

12

2. Especificar os pontos de juno, atravs de conjuntos de juno. Por exemplo, o conjunto de juno especificado na Figura 10 identifica chamadas de mtodos que movem figuras.

Figura 10 Conjunto de juno que identifica chamadas de mtodos que movem figuras.

3.

Especificar as aes a serem combinadas (advice). Adendos definem cdigos que sero executados nos pontos de juno, podendo ser: before advice executado quando um ponto de juno alcanado e antes que a computao prossiga. after advice executado depois que a computao realizada no ponto de juno se encerra. around advice executado quando se chega no ponto de juno; pode possuir (ou no) controle explcito sobre a execuo da computao originalmente associada ao ponto de juno. Como exemplo, apresentada na Figura 11 a definio do AtualizaDaTela.

Figura 11 Exemplo de um conjunto de juno para o editor de figura.

4.

Definir o aspecto (aspect). Como concluso da seqncia dos passos sendo a modularizao do interesse transversal de

anteriores tem-se ento o ltimo passo que a definio do aspecto

AtualizaDisplay,

AspectJ, podendo conter declaraes de pontos de juno, adendos, declaraes inter-tipo (introductions), membros (atributos e mtodos) locais e uma hierarquia de aspectos. No caso do editor de figuras temos ento a seguinte implementao do editor de figuras utilizando aspectos na Figura 12. 13

Figura 12 Implementao do editor de figuras com AspectJ.

A.4 Concluso
A Programao Orientada a Aspectos trs vrios benefcios na resoluo de muitos problemas encontrados atualmente. Possibilita a construo de programas mais modulares, com a separao dos interesses transversais, evitando assim o entrelaamento e espalhamento do comportamento no cdigo. Alm disso, permite a

14

possibilidade de reutilizao de grande parte dos mdulos desenvolvidos. Desta forma, obtm-se ganhos com a manuteno e evoluo do software. A linguagem AspectJ uma extenso orientada a aspectos da linguagem Java, sendo uma abordagem clara e composta por construes simples e eficazes, capazes de modularizar interesses que anteriormente ficavam espalhados pelo cdigo dificultando o entendimento do sistema.

15

Referncias
[Beck, 2000] Beck, K. eXtreme Programming explained. Addison-Wesley, USA, 2000. [Brown et al., 1998] Brown, W. H.; Malveau, R. C.; McCormickIII, H. W.; Mowbray, T. J. AntiPatterns: Refactoring Software, Architectures and Projects in Crisis. Wiley Computer Publishing, John Wiley & Sins, Inc., 1998. [Deng et al., 2002] Deng, X., Dwyer, M. B., Hatcliff, J., Mizuno, M. Invariant-based specification, synthesis, and verification of synchronization in concurrent programs, ICSE02: Proceedings of the 24th International Conference on Software Engineering, ACM Press, pp. 442-452, Orlando, Florida, USA, 2002. [Dijkstra, 1969] Dijkstra, Edsger W. Notes on Structured Programming. In Structured Programming, Academic Press, London, U.K, 1969. [Dijkstra, 1976] Dijkstra, Edsger W. A Discipline of Programming. Prentice Hall, 1976. [Elrad et al., 2001] Elrad, T.; Kiczales, G.; Aksit, M.; Lieberher, k.; Ossher, H. Discussing Aspects of AOP. Communications of the ACM, v. 44, n. 10, p. 33-38, 2001. [Fowler et al., 1999] Fowler, Martin; Beck, Kent; Brant, John; Opdyke, William; Roberts, Don. Refactoring: Improving the Design of Existing Code. Addison-Wesley, June 1999. [Gurp and Bosch, 2002] Gurp, J. van; Bosch, J. Design Erosion: Problems & Causes. Journal of Systems & Software, 61(2), pp. 105-119, Elsevier, March 2002. [Gurp et al., 2003] Gurp, J. van; Bosch, J; Brinkkemper, S. Design Erosion in Evolving Software Products. In: International workshop on the Evolution of Large-scale Industrial Software Applications, ICSM 2003. [Gurp et al., 2005] Gurp, J. van; Brinkkemper, S.; Bosch, J. Design preservation over subsequent releases of a software product: a case study of Baan ERP. Journal of Software Maintenance And Evolution: Research And Practice, Vol. 17, pp. 277306, 2005. [Gradeck and Lesiecki, 2003] Gradeck, Joe; Lesiecki, Nicolas. Mastering AspectJ: aspect-oriented programming in Java. Indianopolis, Indiana. Wiley, 2003. [Katoen, 1999] Katoen, J. P. Concepts, algorithms, and tools for models checking. Book to appear, based on the lecture notes of the course Mechanised Validation of Paralled Systems (course number 10359) at the Friedrich-Alexander Universitt ErlangenNrnberg. [Kiczales et al., 1997] Kiczales, G; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C. V.; Loingtier, J.; Irwin, J. Aspect-Oriented Programming, Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland, Springer-Verlag LNCS 1241, June 1997. [Kiczales et al., 2001] Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J.; Griswold, W.G. An overview of AspectJ, In Knudsen, J. L., editor, proceedings of the European Conference on Object-Oriented Programming (ECOOP), Berlin, pg 327-353, Springer-Verlag, 2001.

16

[Kiselev, 2002] Kiselev, I. Aspect-Oriented Programming with AspectJ, Ed. Sams Publishing, 2002. [Laddad, 2003] Laddad, R. AspectJ in Action: Practical Aspect-Oriented Programming, Manning, Greenwich, 2003. [Lehman, 1998] Lehman, M. m. Software's Future: Managing Evolution, IEEE Software, v.15, n. 1, 40-44, Jan. 1998. [Lieberherr et al., 1994] Lieberherr, K. J.; Silva-Lepe, I.; Xiao, C. Adaptive ObjectOriented Programming Using Graph-Based Customization, Communications of the ACM, 37(5): 94-101, 1994. [McGregor and Sykes, 2001] McGregor, J. D.; Sykes, D. A. A practical guide to testing object-oriented software, Addison-Wesley, 2001. [Monteiro and Piveta, 2003] Monteiro, Elaine S.; Piveta, Eduardo K. Programao Orientada a Aspectos em AspectJ, Anais do V Encontro dos Estudantes de Informtica do Tocantins, Palmas, TO, pp. 313-322, October, 2003. [Ossher and Tarr, 1999] Ossher, H. and Tarr, P. Using subject-oriented programming to overcome common problems in object-oriented software development/evolution, In International Conference on Software Engineering, ICSE99, p. 688 - 698, ACM, 1999. [Royce, 1970] Royce, W.W. Managing the development of large software systems, In: Proceedings of IEEE WESCON, p. 1-9, 1970. [Schwaber et al., 2002] Schwaber, K. and Beedle, M., Agile Software Development with Scrum, NJ, Prentice-Hall, 2002. [Soares and Borba, 2002] Soares, S.; Borba, P. AspectJ - Programao orientada a aspectos em Java, In: VI Simpsio Brasileiro de Linguagens de Programao, Rio de Janeiro, 2002. [Tretmans, 1999] Tretmans, J. Testing concurrent systems: A formal approach, In CONCUR99 10th International Conference on Concurrency Theory, volume 1664 of Lecture Notes in Computer Science, pages 46-65, 1999.

17