Uma Proposta de Critérios de Manutenibilidade para
Modelos de Projetos de Software Orientados a Aspectos
André Amâncio1,3, Rodrigo Santos2, Paulo Parreira Junior4,Heitor Costa1, Cláudia Werner2, Antônio Resende1, Fábio Silveira5
1
Grupo PqES/DCC/UFLA, Universidade Federal de Lavras, Brasil Caixa Postal 3037 – CEP 37.200-000 – Lavras, MG
2
COPPE/UFRJ – Universidade Federal do Rio de Janeiro, Brasil Caixa Postal 68511 – CEP 21.945-970 – Rio de Janeiro, RJ
3
DCC/UFMG, Universidade Federal de Minas Gerais, Brasil CEP 31.270-010 – Belo Horizonte, MG
4
Grupo GDMS/DC/UFSCar, Universidade Federal de São Carlos, Brasil Caixa Postal 676 – CEP 13.565-905 – São Carlos, SP
5
DCT/UNIFESP, Universidade Federal de São Paulo, Brasil CEP 04.020-041 – São José dos Campos, SP
afancio@dcc.ufmg.br, rps@cos.ufrj.br, paulo_junior@dc.ufscar.br, heitor@ufla.br, werner@cos.ufrj.br, tonio@dcc.ufla.br, fsilveira@unifesp.br
Abstract. Software modeling is an important activity for maintenance, because it
makes the software understanding and evolution, correction and adaptation tasks easier. In this sense, maintainability should be incorporated into the artifacts produced during software modeling, aiming to design software with characteris-tics that make the maintenance less arduous. This paper shows a proposal of maintainability criteria to build aspect-oriented software design models, elabo-rated from Maintainability Criteria for Implementation Model, conventions of aSideML language, and according to ISO/IEC 9126 standard.
Resumo. A modelagem de software corresponde a uma atividade importante para
a manutenção, pois pode facilitar a compreensão do software e suas atividades de evolução, correção e adaptação. Nesse sentido, a manutenibilidade deveria ser incorporada aos artefatos produzidos nessa atividade, visando projetar software com características que tornem a sua manutenção menos dispendiosa. Este tra-balho apresenta uma proposta de critérios de manutenibilidade para a constru-ção de modelos de projetos de software orientados a aspectos, elaborada a partir dos Critérios de Manutenibilidade para Modelo de Implementação, das conven-ções da linguagem de modelagem aSideML e sob a luz da norma ISO/IEC 9126.
1. Introdução
A modelagem de software consiste na construção de modelos para auxiliar o desenvol-vimento e/ou análise de um sistema, podendo expor oportunidades de simplificação e de reutilização [Larman, 2007]. Na Engenharia de Software, a modelagem se apresenta como uma atividade importante para a manutenção de software, pois pode facilitar sua compreensão, evolução, correção e adaptação, sobretudo considerando o papel da ma-nutenção no ciclo de vida [Schach & Tomer, 2000]. Esse cenário ressalta a importância das pesquisas sobre o processo de manutenção e a necessidade de considerá-la durante o processo de desenvolvimento, notadamente na organização de produtos de software não-triviais, como aqueles orientados a aspectos, uma vez que estes tipos de software visam a manutenibilidade e a reusabilidade ao propiciarem a separação de interesses [Kiczales et al., 1997]. Ou seja, uma estratégia consiste na incorporação da manutenibi-lidade aos artefatos produzidos durante a modelagem, a fim de construir software com
características que tornem a sua manutenção menos dispendiosa. Nesse sentido, as sub-características de manutenibilidade da norma ISO/IEC 9126, analisabilidade, estabili-dade, modificabilidade e testabilidade, podem realçar atributos que evidenciam o es-forço para realizar modificações em software [ISO Std. 9126, 1991] [ISO Std. 9126, 2001], pois esta norma é referente à avaliação da qualidade do produto (software).
Nesse contexto, o objetivo deste trabalho é apresentar uma proposta de critérios de manutenibilidade para a construção de modelos de projetos de software (i.e., soft-ware design models) orientados a aspectos. A proposta se baseia nos Critérios de Ma-nutenibilidade para construção de Modelos de Implementação Orientados a Aspectos desenvolvidos por Santos (2007), nas convenções da linguagem de modelagem aSideML desenvolvida por Chavez (2004) e na definição da característica de manuteni-bilidade presente na norma ISO/IEC 9126. Para isso, a Seção 2 discorre sobre a funda-mentação teórica, a Seção 3 apresenta a proposta de critérios de manutenibilidade, a Seção 4 ilustra a aplicação dos critérios e a Seção 5 exibe as considerações finais.
2. Fundamentação Teórica
Em decorrência da complexidade da organização de produtos de software “não-triviais”, novas tecnologias são estudadas e aplicadas ao processo de desenvolvimento, como a orientação a aspectos (OA). A OA visa complementar paradigmas de desenvolvimento existentes, buscando prover a separação de interesses transversais (crosscutting con-cerns), e contribuir para a compreensão, o desenvolvimento e a manutenção de software [Kiczales et al., 1997]. Apesar das melhorias almejadas, alguns pontos podem dificultar a atividade de manutenção (e.g., inversão de dependência e inconsciência) [Santos et al., 2007], o que requer estudos que a relacionem com o Desenvolvimento de Software Orientado a Aspectos (DSOA), dado o crescimento das pesquisas nessa área. Dentre as tecnologias de DSOA, destaca-se AspectJ, uma extensão da linguagem Java para a im-plementação de aspectos. A Tabela 1 mostra os principais elementos de AspectJ.
Tabela 1 – Principais Elementos de AspectJ (Fonte: [Santos et al., 2008b])
Elemento Descrição
join points (pontos de junção) Trechos de código na execução de um produto de software nos quais os aspectos são aplicados. Conceitos abstratos em AspectJ.
pointcuts (conjuntos de junção) Declarações responsáveis por selecionar join points, ou seja, detectam quais join points o aspecto deve interceptar.
advices (adendos ou comportamentos transversais)
Utilizado para implementar interesses transversais – trechos de código executados a cada ocorrência de join point descrito no pointcut.
introductions ou inter-type
declaration (declaração intertipos)
Modificam uma classe estruturalmente, acrescentando-lhe novos membros e relaciona-mentos por meio da cláusula declare parents.
aspects (aspectos) Encapsulam pointcuts, advices e introductions em uma unidade modular de im-plementação, definidos de maneira semelhante às classes.
2.1. aSideML: Linguagem de Modelagem para Software OA
Para especificar e comunicar projetos OA, Chavez (2004) desenvolveu a linguagem de modelagem aSideML, que oferece notações semânticas e regras para tratar a modela-gem conceitual de sistemas em termos de aspectos e de elementos transversais1. Em aSideML, os elementos de modelagem definidos pelo usuário podem ser estruturais ou comportamentais. aSideML também possui elementos de modelagem composicionais para descrever elementos do processo de combinação (e.g., woven collaborations) e
1
define novos e enriquece diagramas da UML (Unified Modeling Language) para apre-sentar os elementos transversais e os seus relacionamentos com os elementos base2: • Diagrama de Aspectos. Este diagrama exibe a descrição de um aspecto que
incor-pora as interfaces transversais3, as características locais (atributos e métodos) e os relacionamentos de herança. Cada característica transversal comportamental4 pode ser visualizada em um Diagrama de Colaboração Aspectual5;
• Diagrama de Classes Estendido. Este diagrama apóia a representação gráfica da visão de projeto estático do software. Além disso, ele permite visualizar cada as-pecto, em detalhe e separadamente, no Diagrama de Aspecto correspondente, e re-presenta uma coleção de elementos de modelagem estrutural, como aspectos, clas-ses, interfaces e seus relacionamentos, conectados entre si como um grafo;
• Diagrama de Seqüência Aspectual. Este diagrama fornece uma representação grá-fica de um conjunto de mensagens organizadas em seqüência temporal (mensagens denotam invocações a operações de aspectos) e suporte à visão de interação;
• Diagrama de Processo de Combinação. Este diagrama fornece representação grá-fica para um grupo de elementos combinados (elementos base adornados para enfa-tizar as melhorias proporcionadas pelos elementos transversais). Esses elementos podem ser especializados para cada modelo de implementação disponível;
• Diagrama de Colaboração Aspectual. Este diagrama provê representação gráfica de uma colaboração aspectual, com suporte à visão da interação, que envolve instân-cias de aspectos e elementos base. Uma colaboração aspectual possui uma parte es-tática (descreve papéis que objetos e instâncias de aspecto exercem) e uma parte di-nâmica (mostra fluxos de mensagens para realizar o comportamento transversal).
Embora não haja consenso sobre qual linguagem de modelagem OA usar, aSideML se apresentou adequada por propor um modelo de aspectos em alto nível (in-dependente de linguagem de programação) e contemplar os principais conceitos, propri-edades e arquitetura introduzidos pelo projeto OA. A notação Theme/UML [Clarke, 2001], apesar de ser independente de uma abordagem de implementação, não oferece tantos recursos (diagramas e elementos de modelagem) para depuração e teste estrutural como aSideML. AODM (Aspect-Oriented Design Model) [Stein, 2002] foi considerada específica demais para AspectJ e, portanto, pouco útil para descrever soluções de alto nível que possam ser implementadas em outras linguagens [Garcia et al., 2004]. A nova versão de aSideML está em desenvolvimento para atualizar e acrescentar funções para atender a demanda de seus usuários, contando com duas ferramentas plugins da IDE Eclipse para gerar modelos aSideML a partir de programas em AspectJ [Souza, 2007] e para representar e editar estes modelos [Lima, 2007].
2.2. Trabalhos Relacionados
Alguns trabalhos apontam que um desnível de abstração entre os modelos de projeto e de implementação dificulta a manutenção, pois o primeiro não retrata o segundo. Fiutem & Antoniol (1998) apresentam uma abordagem para verificar as características de soft-ware orientado a objetos (OO), que consiste em: i) obter um projeto a partir do código; ii) comparar os projetos (original e obtido); e iii) tratar inconsistências, localizando
2
A terminologia usada neste trabalho está de acordo com Chavez (2004).
3
Conjuntos de características transversais com nome associado, que caracterizam o comportamento transversal.
4
Operações que descrevem melhorias no comportamento de componentes do sistema.
5
Descrição da organização geral de objetos e instâncias de aspectos que interagem em um contexto, a fim de implementar o comportamento transversal de uma característica transversal comportamental.
giões não comuns entre os dois projetos. Harrison et al. (2000) apresentam um método de implementação, utilizando Java e UML, para transformar os elementos de modela-gem nos conceitos e nas propriedades do paradigma OO, a partir dos diagramas em alto nível de abstração. Murphy et al. (2001) apresentam uma abordagem que define um modelo em alto nível de abstração e especificam como o modelo é mapeado para có-digo. Entretanto, esses trabalhos se concentram no desenvolvimento OO ou focam na manutenibilidade considerando apenas o modelo de implementação.
Costa (2005) propõe critérios e diretrizes para a verificação do Modelo de Aná-lise e para a construção dos Modelos de Projeto e de Implementação de software OO, baseados no uso dos padrões de projeto Singleton e State, nas convenções das lingua-gens Eiffel, Java e Smalltalk e na norma ISO/IEC 9126. No entanto, a abordagem se restringe a OO e não provê extensão ou aplicação em DSOA. Santos et al. (2008b) es-tenderam este trabalho, definindo padrões ou exigências para guiar a construção de arte-fatos do Modelo de Implementação (código) de software OA, a fim de agregar manute-nibilidade, denominados Critérios de Manutenibilidade para o Modelo de Implemen-tação (Maintainability Criteria for Implementation Model – MC_IM). Esses critérios foram divididos em categorias, para facilitar sua aplicabilidade, e foram elaborados a partir de características das linguagens Java e AspectJ e de pesquisas acerca de conven-ções de programação extraídas de uma amostra de trabalhos da literatura, baseando-se na manutenibilidade (ISO/IEC 9126). A descrição dos MC_IMs pode ser obtida em [Santos, 2007]. Essas pesquisas proveram a base para a realização do presente trabalho, cujo diferencial está no tratamento da manutenibilidade em Modelos de Projetos OA.
3. Critérios de Manutenibilidade para o Modelo de Projeto OA
O contexto de pesquisa deste trabalho envolve o desenvolvimento de uma abordagem relativa à incorporação da manutenibilidade aos modelos gerados no DSOA, mediante a elaboração de critérios que guiem a construção e/ou a avaliação/adaptação dos artefatos de software, além de diretrizes e facilitadores que auxiliem a aplicação dos critérios a artefatos de maior nível de abstração [Santos et al., 2008a]. Busca-se reduzir o esforço de transição dos artefatos entre os diferentes níveis de abstração. Estendendo os traba-lhos de Costa (2005) e de Santos (2007) para tratar a manutenibilidade no nível de mo-delo no DSOA, a abordagem apresenta um conjunto de padrões de manutenibilidade que visa guiar a construção de artefatos do Modelo de Projeto (modelos/diagramas) de produtos de software OA manuteníveis. Esses critérios são denominados Critérios de Manutenibilidade para o Modelo Projeto (Maintainability Criteria for Design Model – MC_DM) [Amâncio et al., 2008] e foram elaborados a partir dos MC_IMs, das conven-ções e características da linguagem de modelagem aSideML e das pesquisas acerca de bom estilo e guidelines de modelagem presentes em [Filman et al., 2004], sob a luz da característica de manutenibilidade definida na norma ISO/IEC 9126.
Procurou-se manter um conjunto de critérios que cobrisse questões importantes da construção de um Modelo de Projeto OA, a fim de favorecer a aplicabilidade e a ca-libragem (i.e., ajustes após a execução de estudos de caso). Os critérios apresentam a seguinte estrutura (Figura 1): i) critério: identifica o MC_DM, com número e descrição; ii) justificativa: justifica o uso do MC_DM; iii) subcaracterística(s): lista a(s) subca-racterística(s) de manutenibilidade definida(s) na norma ISO/IEC 9126 as quais o MC_DM visa melhorar. O conjunto dos MC_DMs (Tabela 2) pode ser usado em duas situações: i) construção do Modelo de Projeto (guiar as decisões de projeto); e ii)
avali-ação/adaptação de um Modelo de Projeto existente (verificar o projeto, para adequá-lo aos padrões dos critérios). A descrição detalhada dos MC_DMs pode ser obtida em [Amâncio, 2008]. Ainda, visando manter a rastreabilidade entre MC_IMs e MC_DMs e apoiar a manutenção de um produto de software OA coeso, composto por artefatos de análise, projeto e implementação válidos, foi construída uma matriz que relacionasse esses critérios [Amâncio, 2008]. Busca-se a manutenibilidade com foco na abstração, a fim de minimizar o esforço para manter o conjunto de artefatos atualizado e real, em diferentes níveis de abstração (documentos textuais, modelos e código).
MC_DM 9 – Os subaspectos definem uma pequena quantidade de novas características locais ou sobrepõem poucas características locais existentes.
Justificativa: Torna as tarefas de manutenção e de testes menos árduas em relação a uma hierarquia de herança, uma vez que há poucos métodos de subaspectos reescritos (overriding). Caso contrário, pode ocorrer um problema de projeto, havendo violação da abstração do superaspecto que refletirá na implementação, resultando em uma hierarquia de herança fraca. Além disso, aumenta a quantidade de testes necessários para verificar a corretude do software.
Subcaracterística(s): Analisabilidade, Modificabilidade e Testabilidade.
Figura 1 – Exemplo de MC_DM
Tabela 2 – Critérios de Manutenibilidade para o Modelo de Projeto OA
Critérios de Manutenibilidade para o Modelo de Projeto (MC_DMs)
MC_DM 1 – O Modelo de Projeto é constituído pelo Diagrama de Aspectos, Diagrama de Classes Estendido, Diagrama de Seqüência Estendido, Diagrama de Colaboração Aspectual, Diagrama de Seqüência, Diagrama de Classes Combinadas, Diagrama de Colaboração Combinada e Diagrama de Seqüência Combinada.
MC_DM 2 – A implementação dos aspectos é fácil de ser localizada.
MC_DM 3 – As mensagens emitidas pelo software ao usuário estão alocadas em um aspecto específico.
MC_DM 4 – O identificador de aspectos, pointcuts e introductions permite rápido reconhecimento destes elementos. MC_DM 5 – Apenas o aspecto tem acesso aos seus atributos, no sentido de atribuir ou recuperar os seus valores. MC_DM 6 – O aspecto mantém atualizados os atributos da classe na qual ele atua.
MC_DM 7 – Os relacionamentos entre os aspectos estão dispostos de maneira a minimizar a quantidade de árvores de hierarquia de herança, mantendo-se aquelas estritamente necessárias.
MC_DM 8 – Os atributos, os métodos e as interfaces transversais dos aspectos estão localizados de maneira a reduzir a altura das árvores de hierarquia de herança.
MC_DM 9 – Os subaspectos definem uma pequena quantidade de novas características locais ou sobrepõem poucas características locais existentes.
MC_DM 10 – Os subaspectos definem uma pequena quantidade de novas características transversais, organizadas em novas interfaces transversais ou como extensões de interfaces transversais existentes.
MC_DM 11 – Os relacionamentos entre aspectos estão dispostos de maneira a minimizar o acoplamento entre eles. MC_DM 12 – Os aspectos devem possuir apenas um interesse transversal.
4. Um Exemplo de Aplicação dos MC_DMs
Para exemplificar a aplicabilidade dos MC_DMs, decidiu-se por utilizá-los para guiar a construção do Modelo de Projeto do Sistema do Domínio Bancário (SDB). O SDB ge-rencia operações de uma agência bancária: efetuar login e logoff, cadastrar e remover clientes, alterar senha, ver saldo, realizar transferência e efetuar depósito e saque. Os usuários são classificados em administrador e cliente. Foram modelados os aspectos APersistencia (persistência), ATransacoes e ATransacoesBancarias (controle de transação), AIUsuario (declare parents), ALogging (histórico de acessos), ATracing (controle de fluxo de execução) e APreEPosCondicoes (suporte à verifi-cação de pré e pós-condições). A seguir, o uso de alguns MC_DMs é apresentado.
Para modelar o aspecto APreEPosCondicoes e compô-lo com outros elemen-tos de modelagem, os seguintes passos foram realizados: i) descrever o aspecto APreEPosCondicoes em um Diagrama de Aspecto; ii) descrever colaborações as-pectuais para cada característica transversal em Diagramas de Colaboração Asas-pectuais; e iii) descrever o comportamento de cada interesse transversal usando Diagramas de
Seqüência. A Tabela 3 descreve brevemente os aspectos do SDB, além de representar o comportamento transversal entre cada um deles e outros aspectos/classes.
Tabela 3 – Descrição dos Aspectos do SDB [Amâncio, 2008]
Aspecto Classes Atingidas Aspectos Relacionados Descrição
APersistencia Banco, Conta e Usuario Nenhum Armazena os objetos das classes persistentes em um meio persistente
ATransacoes RepositorioContas e
ConexaoBD Nenhum Efetua o controle de transações da aplicação
ATransacoesBancarias RepositorioContas e
ConexaoBD ATransacoes
Herda características de ATransacoes e fornece implementação aos métodos abstratos deste aspecto AIUsuario Administrador e Cliente Nenhum Declara a herança entre as classes Administrador e Cliente e a classe base Usuario
ALogging Banco Nenhum Controla o histórico do sistema
ATracing Banco Nenhum Controla o rastreamento da aplicação
APreEPosCondicoes Administrador e Cliente Nenhum Verifica as pré e pós-condições de um caso de uso
Em [Amâncio, 2008], foram construídos os diagramas requeridos pelo MC_DM 1, que destaca o conjunto dos artefatos do Modelo de Projeto OA necessários para construção do Modelo de Implementação OA, sendo que alguns desses diagramas são apresentados nos próximos exemplos. Pode ser observado na Figura 2 que, na declara-ção do aspecto APreEPosCondicoes, o símbolo losango facilita a sua identificação e localização na implementação (uso do MC_DM 2). O MC_DM 11 e o MC_DM 12 também estão visualmente aplicados, pois cada implementação de aspecto deve possuir apenas uma interface transversal, e APreEPosCondicoes apresenta apenas um inte-resse transversal, com uma baixa interação com outros aspectos e classes, indicando que possui um baixo acoplamento.
{Transferencia, SaldoInsuficienteException , Transferencia} APreEPosCondicoes Transferencia Refinements _SaldoInsuficienteException() Transferencia_() Additions + APreEPosCondicoes() + repositorioContas() + saldoOriginalContaDeOrigem() + saldoOriginalContaDeDestino()
Figura 2 – Diagrama de Aspecto de APreEPosCondicoes
No aspecto ATransacoesBancarias, o MC_DM 9 e o MC_DM 10 foram ob-servados, uma vez que este aspecto define uma pequena quantidade de características locais ou sobrepõem poucas características locais (retângulo menor tracejado), além de uma pequena quantidade de novas características transversais em novas interfaces transversais ou como extensões de interfaces transversais (retângulo interno) (Figura 3). O MC_DM 7 e o MC_DM 8 contribuem para tornar as tarefas de manutenção e de tes-tes menos árduas, em relação a uma hierarquia de herança, pois primam por poucos métodos de subaspectos reescritos e por baixa altura na árvore hierárquica de herança. A Figura 4 e a Figura 5 apresentam, respectivamente, o Diagrama de Colaboração Aspectual e o Diagrama de Seqüência Aspectual, que descrevem o comportamento transversal e mostram a instância do aspecto APreEPosCondicoes interagindo com instâncias de classes ou aspectos base afetados. Os demais critérios de manutenibilidade não foram apresentados, devido ao escopo do SDB. Entretanto, seu uso está previsto em novas aplicações. Ao todo, 8 MC_DMs foram aplicados, cobrindo 67% dos critérios. Analisando o contexto do SBD, pode-se verificar que foi utilizado um conjunto de critérios que agregava importância aos modelos necessários pela equipe de manutenção.
Figura 3 – Diagramas de Aspecto de ATransacoes e ATransacoesBancarias APreEPosCondicoes Administrador Cliente aspect aspect base base
Figura 4 – Diagrama de Colaboração Aspectual de APreEPosCondicoes
Figura 5 – Diagrama de Seqüência Aspectual de APreEPosCondicoes
5. Considerações Finais
A manutenção se torna inevitável em produtos de software [Zvegintzov & Parikh, 2005]. Visando melhorar a compreensão, evolução, correção e adaptação do software, faz-se importante considerar a manutenibilidade no processo de desenvolvimento. Mais especificamente, ao lidar com os artefatos do Modelo de Projeto, a incorporação do ideal de manutenção durante a sua construção pode contribuir para melhorar o perfil dos stakeholders, ao serem influenciados pela cultura de desenvolvimento de software de maior qualidade [Sneed & Brossler, 2003]. Assim, foi proposto um conjunto de critérios de manutenibilidade para guiar a construção de Modelos de Projetos OA (MC_DMs), parte de uma abordagem relativa à definição de critérios, diretrizes e facilitadores de manutenibilidade para cada modelo gerado no DSOA [Santos et al., 2008a].
Os MC_DMs buscam explorar e explicitar informações importantes para entender modelos OA e para facilitar a sua manutenção, cuja exemplificação se deu através da construção de um sistema de domínio bancário. A partir disso, pretende-se aplicar os MC_DMs para verificar a sua aplicabilidade, por meio de estudos de caso em aplicações de maior porte que incluam atividades de manutenção (e.g., perfectiva, corretiva etc.) e definição e uso de parâmetros para medição ou análise qualitativa. Com isso, almeja-se verificar se os MC_DMs melhoram a manutenibilidade. Por fim, tornam-se interessantes estudos sobre a manutenibilidade no Modelo de Análitornam-se.
Agradecimentos
Os autores agradecem ao CNPq pelo apoio financeiro na realização deste trabalho.
Referências
Amâncio, A. F. (2008) “Critérios de Manutenibilidade para Construção do Modelo de Projeto Orientado a Aspectos”. Monografia. DCC/UFLA, Lavras, Brasil, 44p.
Amâncio, A. F.; Santos, R. P.; Costa, H. A. X.; Resende, A. M. P.; Silveira, F. F. (2008) “Maintainability Criteria for Aspect-Oriented Software Design Model”, In: II LA-WASP, SBES, Campinas, Brasil, 90-91. Chavez, C. F. G. (2004) “Um Enfoque Baseado em Modelos para o Design Orientado a Aspectos”. Tese
(Doutorado). DI/PUC-Rio, Rio de Janeiro, Brasil, 298p.
Clarke, S. (2001) “Composition of Object-Oriented Software Design Models”. PhD Thesis. Dublin City University, Dublin, Ireland, 273p.
Costa, H. A. X. (2005) “Critérios e Diretrizes de Manutenibilidade para a Construção do Modelo de Projeto Orientado a Objetos”. Tese (Doutorado). Escola Politécnica da USP, São Paulo, Brasil, 199p.
Filman, R. E.; Elrad, T.; Clarke, S.; Aksit, M. (2004) “Aspect-Oriented Software Development”. Addison-Wesley, 800p.
Fiutem, R.; Antoniol G. (1998) “Identifying Design-Code Inconsistencies in Object-Oriented Software”, In: 14th ICSM, Bethesda, Maryland, 94-102.
Garcia, A.; Chavez, C.; Soares, S.; Piveta, E.; Penteado, R.; Camargo, V. V.; Fernandes, F. (2004) “Relatório do 1º Workshop Brasileiro de Desenvolvimento de Software Orientado a Aspectos”, In: I WASP, SBES, Brasília, Brasil, 10p.
Harrison, R.; Counsell, S.; Nithi, R. (2000) “Experimental Assessment of the Effect of Inheritance on the Maintainability of Object-Oriented Systems”. Journal of Systems and Software 52, 2-3 (June), 173-179. ISO Std. 9126 (1991) “Information Technology – Software Product Evaluation – Quality Characteristics and
Guidelines for their Use”. International Organization for Standardization.
ISO Std. 9126 (2001) “Software Engineering – Product Quality Part 1: Quality Model”. International Organization for Standardization.
Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C. V.; Loingtier, J. M.; Irwin, J. (1997) “Aspect-Oriented Programming”, In: 11th ECOOP, Jyväskylä, Finland. LNCS 1241, 220-242.
Larman, C. (2007) “Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Desenvolvimento Interativo”, 3. ed., Bookman, 696p.
Lima, L. M. (2007) “Um Editor Gráfico para Criação de Modelos aSideML”. Monografia. IM-DCC/UFBA, Salvador, Brasil.
Murphy, G. C.; Notkin, D.; Sullivan, K. J. (2001) “Software Reflexion Models: Bridging the Gap between Design and Implementation”. Transactions on Software Engineering 27, 4 (April), 364-380.
Santos, R. P. (2007) “Critérios de Manutenibilidade para Construção e Avaliação de Produtos de Software Orientados a Aspectos”. Monografia (Projeto Final). DCC/UFLA, Lavras, Brasil, 92p.
Santos, R. P.; Silva, M. C. O.; Werner, C. M. L.; Murta, L. G. P. (2007) “Questões e Desafios de Orientação a Aspectos no Contexto da Reutilização de Software”, In: I LA-WASP, SBES, João Pessoa, Brasil, 185. Santos, R. P.; Costa; H. A. X.; Júnior, P. A. P.; Amâncio, A. F.; Resende, A. M. P.; Werner, C. M. L. (2008a)
“Uma Abordagem Baseada em Critérios de Manutenibilidade para Construção do Modelo de Implementação de Produtos de Software Orientados a Aspectos”. INFOCOMP Journal of Computer Science, Special Edition, 11-20.
Santos, R. P.; Werner, C. M. L.; Costa; H. A. X.; Júnior, P. A. P.; Amâncio, A. F.; Resende, A. M. P. (2008b) “Critérios de Manutenibilidade para Construção de Produtos de Software Orientados a Aspectos”, In: V WMSWM, SBQS, Florianópolis, Brasil, 1-9.
Schach, S. R.; Tomer, A. (2000) “A Maintenance-Oriented Approach to Software Construction”. Journal of Software Maintenance: Research and Practice 12, 1 (January-February), 25-45.
Sneed, H.M.; Brossler, P. (2003) “Critical Success Factors in Software Maintenance: A Case Study”, In: 19th ICSM, Amsterdam, The Netherlands, 190-198.
Souza, R. R. G. (2007) “REAJ: Uma Ferramenta para Engenharia Reversa de Código AspectJ”. Monografia (Projeto Final). IM-DCC/UFBA, Salvador, Brasil, 58p.
Stein, D. (2002) “An Aspect-Oriented Design Model Based on AspectJ and UML”. Master Thesis. University of Duisburg-Essen, Essen, Germany, 186p.
Zvegintzov, N.; Parikh, G. (2005) “60 years of Software Maintenance: Lessons Learned”, In: 21st ICSM, Budapest, Hungary, 726-727.
