Um Perfil UML para Projeto de Frameworks Transversais · 2. Conceitos Fundamentais Fazendo o uso da UML 2.0, Evermann (2007) desenvolveu um meta-modelo que é um perfil UML específico

Um Perfil UML para Projeto de Frameworks Transversais

José Uetanabara Júnior*, Valter Vieira de Camargo#

*Centro Universitário Eurípides de Marília – UNIVEM Marília – São Paulo, Caixa Postal 2041 CEP 17.525-901

#Departamento de Computação da Universidade Federal de Lavras (DCC-UFLA)

Campus Universitário, Lavras, Minas Gerais CEP 37.200-000

[email protected], [email protected]

Abstract. This paper presents a UML profile to support the modeling of Crosscutting Frameworks, which makes evident their main characteristics. The profile was developed based on an existing profile for aspect-oriented programming, on some idioms for the development of crosscutting frameworks and on a conventional framework profile called UML-F. The profile provides uniformity of the vocabulary used by the developers, eases the understanding of the framework and application architectures and serves as a guide for creating good crosscutting framework designs. The proposed profile was evaluated through its application in a persistence crosscutting framework.

Resumo. Neste artigo é apresentado um perfil UML para a modelagem de Frameworks Transversais que evidencia suas características importantes. O perfil foi desenvolvido com base em um perfil existente para programação orientada a aspectos, em alguns idiomas para implementação de frameworks transversais e em um perfil para frameworks convencionais chamado UML-F. Sua utilização propicia uniformidade do vocabulário usado pelos projetistas, facilita a compreensão da arquitetura do framework e da aplicação desenvolvida e serve como guia para a obtenção de bons projetos de FTs. O perfil proposto foi avaliado por meio de sua aplicação em um FT de persistência.

1. Introdução

Depois do surgimento da programação orientada a aspectos (POA) (Kiczales et al.,1997), alguns frameworks orientados a aspectos (FOAs) começaram a aparecer na literatura (Pinto et al., 2002; Rashid et al., 2003; Soares et al., 2004; Camargo e Masiero, 2008) e também foi proposto um conjunto de idiomas (idioms) para o projeto e implementação desses frameworks (Hanenberg et al., 2003). Esses idiomas auxiliam na estruturação do código e fornecem soluções genéricas de programação que são úteis no desenvolvimento desse tipo de software. No contexto deste artigo, um Framework Transversal (FT) é um tipo de FOA que encapsula apenas um tipo de interesse transversal, como por exemplo, persistência, segurança ou concorrência (Camargo e Masiero, 2008).

Os FTs são usados como apoio para o desenvolvimento de novas aplicações ou de partes de novas aplicações. De forma geral, o desenvolvimento com apoio de frameworks

* Esta pesquisa é apoiada pela CAPES. # Esta pesquisa é parcialmente apoiada pelo CNPq: Projeto Latin-AOSD - PROSUL-Proc. no. 490478/2006-9.

II Latin American Workshop on Aspect-Oriented Software Development

70

resulta em arquiteturas complexas, pois envolve conjuntos de unidades que pertencem ao framework e à aplicação. Também, há muitos detalhes específicos que não ocorrem no desenvolvimento tradicional, detalhes que são características essenciais que não podem ser modelados com a UML convencional. No contexto de FTs, o problema se torna ainda mais grave, pois o desenvolvimento de uma aplicação pode ser apoiado por vários FTs, já que cada um envolve um único interesse transversal. Os modelos de análise e projeto que representam a arquitetura final da aplicação são complexos e dificultam a compreensão e, consequentemente, os processos de manutenção e evolução (Camargo e Masiero, 2008).

Além disso, o processo de utilização e construção de um framework exige compreensão de sua estrutura e da interação entre suas classes/componentes. Esse processo pode ser facilitado se a documentação do framework fornecer indícios claros tanto de sua estrutura quando do processo de instanciação. Essa documentação geralmente é formada por um manual que descreve o processo de instanciação do framework, e por artefatos de análise e de projeto que geralmente são expressos em alguma linguagem de modelagem, como por exemplo, a UML. Uma notação pode auxiliar tanto o engenheiro do framework quanto o engenheiro de aplicação. Contudo, a UML padrão não apóia a representação de características específicas de frameworks (por exemplos: os pontos de instanciação do framework). Uma possível solução é a criação de perfis. Um perfil (profile) é um conjunto de elementos notacionais, como estereótipos (stereotypes) e etiquetas valoradas (tagged values) que estendem o meta-modelo da UML para representar mais adequadamente características específicas de um domínio. A UML-F (UML-Framework), por exemplo, é um perfil da UML específico para a modelagem de Frameworks Orientados a Objetos (FOO) que fornece elementos notacionais que representam características específicas desse tipo de framework (Fontoura et al., 2002). Contudo, os elementos notacionais da UML-F não são suficientes para modelar todas as características de um FT, pois esse tipo de framework possui conceitos adicionais aos FOO.

Neste trabalho é apresentado um perfil UML para modelagem de FTs. O perfil proposto é uma adaptação do perfil de Evermann (2007) e também utiliza conceitos já definidos no perfil UML-F, proposto por Fontoura (2002). Além disso, dois dos idiomas propostos por Hanenberg (2003) são representados na forma de estereótipos e um na forma de tipo enumerado. Foi utilizado um framework de persistência (Camargo e Masiero, 2008) como estudo de caso modelado com a ferramenta Magic Draw. A aplicação do perfil no estudo de caso torna mais explícita as partes que interessam ao engenheiro do framework e as que interessam ao engenheiro de aplicação, pois há estereótipos que evidenciam características específicas para esses dois profissionais. Essa separação facilita a manutenção e o reúso do framework.

Este artigo está estruturado da seguinte forma: na Seção 2 são apresentados os conceitos fundamentais; na Seção 3 é apresentado um perfil para projeto de frameworks transversais; na Seção 4 é mostrado o estudo de caso com o framework de persistência; na Seção 5 os trabalhos relacionados e na Seção 6 é feita a conclusão e trabalhos futuros.


71

2. Conceitos Fundamentais

Fazendo o uso da UML 2.0, Evermann (2007) desenvolveu um meta-modelo que é um perfil UML específico para AspectJ. O autor escolheu essa linguagem pelo fato da maturidade que ela possui para implementação de aspectos.

Por questões de espaço, na Figura 1 é mostrado tanto o perfil original de Evermann, quanto as adaptações realizadas. Ao invés de especializar as meta-classes da UML por meio da criação de novas meta-classes, Evermann (2007) estendeu as meta-classes existentes da UML por meio da criação de estereótipos. Essa extensão é visualizada por meio dos colchetes ([]). Por exemplo, o estereótipo Aspect possui Class entre colchetes, indicando que esse estereótipo, estende a meta-classe Class. Assim, cada classe que aparece na Figura 1, é um estereótipo que pode ser utilizado em nível de modelo. Atributos dos estereótipos se tornam etiquetas quando o perfil é aplicado em nível de modelo.

Figura 1. Meta-modelo adaptado de Evermann (2007).

Esse perfil foi utilizado como base para a criação do perfil proposto pelo fato de ser o perfil que reúne as principais características de um sistema orientado a aspectos implementado em AspectJ. Além disso, esse perfil é uma extensão light-weight da UML.

A UML-F (Fontoura et al., 2002) contém elementos notacionais que descrevem certas características básicas em FOOs. Na UML-F, tanto os estereótipos quanto as etiquetas valoradas da UML foram agrupados em um único elemento chamado de “etiqueta


72

UML-F”. A representação dessa etiqueta é a mesma de um estereótipo da UML, contudo ele também pode possuir um valor, assim como as etiquetas valoradas. Essas etiquetas são divididas em três categorias. Na Tabela 1 são mostradas algumas das etiquetas propostas.

Tabela 1. Etiquetas da UML-F

Etiqueta Descrição Categoria de Etiquetas de Modelagem de Framework

<<application>> O elemento pertence à aplicação e não ao framework <<framework>> O elemento pertence ao framework e não à aplicação. <<utility>> O elemento pertence a uma classe de biblioteca. <<fixed>> O elemento é fixo, isto é, nenhuma alteração pode ser feita nele. <<adapt-static>> O elemento deve ser modificado durante o projeto; durante a execução ele é fixo. <<adapt-dyn>> O elemento pode ser modificado em tempo de execução.

Categoria de Etiquetas para Princípios Essenciais de Construção de FOO <<template>> O método é um método gabarito ou a classe possui um método gabarito. <<hook>> A existência desta etiqueta denota que o método é um método gancho

Categoria de Etiquetas para Padrões utilizados em Frameworks <<PatternName-ClassName>> Onde: “PatternName” deve ser substituído pelo nome do padrão que está sendo utilizado e

ClassName pelo nome da classe que determina o papel do padrão.

A categoria “Etiquetas de Modelagem de Framework” possui etiquetas que auxiliam a documentação do framework, principalmente para o projetista/desenvolvedor de aplicações. Essas etiquetas permitem identificar as classes do framework e as da aplicação, métodos fixos e adaptáveis etc. A categoria “Etiquetas para Princípios Essenciais de Construção de FOO” possui etiquetas que representam dois papéis impostos pela utilização do padrão de projeto método gabarito (template method): os métodos gabarito e os métodos gancho (hook method). Essas etiquetas facilitam a identificação dos pontos de instanciação do framework e são utilizadas pelo perfil proposto pelos autores. A categoria “Etiquetas para Padrões Utilizados em Frameworks” agrupa etiquetas que denotam o papel de cada classe nos padrões de projeto utilizados no framework (exemplos: estratégia e composição).

Hanenberg (2003) propôs um conjunto de oito idiomas para a linguagem AspectJ com o objetivo de estruturar o código para alcançar bons níveis de reúso e abstração. Embora os idiomas também possam ser utilizados para desenvolvimento de software convencional, sua maior utilidade é para o desenvolvimento de frameworks, pois visam a abstrair os detalhes da aplicação para deixar o código genérico e independente. Os oitos idiomas propostos por Hanenberg são: Recipiente de Introdução (Container Introduction), Interface Marcadora (Marker Interface), Conjunto de Junção Composto (Composite Pointcut), Conjunto de Junção Abstrato (Abstract Pointcut), Adendo Gabarito (Template Advice), Método de Conjunto de Junção (Pointcut Method), Adendo Encadeado (Abstract Chain) e Adendo Fábrica (Factory Advice). Desses oitos idiomas propostos, três deles são utilizados nesse trabalho: recipiente de introdução, interface marcadora e adendo gabarito. O idioma recipiente de introdução permite que atributos e métodos sejam inseridos nas classes de aplicação em tempo de composição. O idioma interface marcadora consiste na existência de um tipo base para todos os objetos da aplicação para que o conjunto de junção apenas referencie esse tipo base. O idioma adendo gabarito fornece diferentes comportamentos para um adendo. O idioma conjunto de junção composto, não foi adicionado por já haver um estereótipo para ele no perfil de Evermann.


73

3. Um Perfil para Projeto de Frameworks Transversais

Nesta seção é apresentado o perfil para FTs proposto pelos autores. Na Figura 1 é mostrado o meta-modelo proposto que é resultado da adaptação do perfil de Evermann. Os retângulos que possuem uma bolinha preenchida representam a parte do meta-modelo que foi adicionada pelos autores desse trabalho (os estereótipos). Já o retângulo que possui um quadrado preenchido representa a parte que foi modificada (tipos enumerados).

No total, foram criados treze estereótipos e adicionados cinco tipos enumerados ao tipo enumerado AdviceExecutionType. Dos treze estereótipos criados, oito são mostrados na Tabela 2 e os outros cinco são mostrados na Tabela 3.

Tabela 2. Estereótipos Descritivos para o Projeto de FOAs

Estereótipos para Projeto Físico Estereótipo Classes Base Meta-modelo Aplicado a

<<aspect-App>> Aspect Evermann Aspectos <<aspect-F>> Aspect Evermann Aspectos <<class-App>> Class UML Classes <<class-F>> Class UML Classes <<interface-F>> Interface UML Interfaces <<interface-App>> Interface UML Interfaces <<pointCutHook>> StructuralFeature UML Conjuntos de Junção <<hook>> Operation UML Métodos, conjuntos de junção e declarações entre tipos.

Os estereótipos aspect-App e aspect-F foram criados para representar se o aspecto pertence à aplicação ou ao framework, respectivamente. A parte que interessa ao engenheiro da aplicação são as classes e os aspectos que são criados durante o processo de reutilização do framework. A parte que interessa ao engenheiro de framework consiste em classes e aspectos que pertencem à estrutura interna do framework e que sofrem manutenção no sentido de evoluir o framework, como por exemplo, a adição de variabilidades. Esses dois estereótipos evitam que haja confusão na identificação dos aspectos por parte desses engenheiros. Eles herdam as características da classe base Aspect do meta-modelo de Evermann (2007). O mesmo vale para os estereótipos interface-App, interface-F, porém, eles herdam da meta-classe Interface da UML. Por fim os estereótipos class-app e class-F são semelhantes aos apresentados, porém, eles são aplicados a classes e estendem da meta-classe Class da UML.

O estereótipo pointCutHook foi criado para indicar que o conjunto de junção estereotipado deve ser redefinido se a variabilidade referente a ele for necessária na aplicação. Este estereótipo herda da meta classe StructuralFeature já que o estereótipo PointCut do meta-modelo de Evermann (2007) herda dessa meta-classe da UML.

O último estereótipo hook foi herdado da UML-F e denota que o método é um método gancho; um método que deve ser concretizado pelo engenheiro de aplicação.

Os estereótipos mostrados na Tabela 2 não informam detalhes de implementação e organização de código, já os tipos enumerados e estereótipos mostrados na Tabela 3 representam a utilização dos idiomas template advice, marker interface e container introduction propostos por Hanenberg (2003). Eles podem auxiliar um desenvolvedor a estruturar o código para alcançar bons níveis de reúso. Além dos benefícios oriundos da


74

utilização de padrões de projeto e dos idiomas, outro grande benefício é a uniformidade de vocabulário para comunicação entre desenvolvedores.

Tabela 3. Tipos Enumerados para a Representação de Idiomas

Tipos Enumerados para a Representação de Idiomas Idioma Tipo Enumerado

before-template after-template around-template

after-returning-template

Adendo Gabarito

after-throwing-template Idioma Estereótipos

Interface Marcadora <<markerInterface>> e <<aspectSpecification>> Recipiente de Introdução <<container>>, <<containerConnector>> e <<containerLoader>>

Os tipos enumerados before-template, after-template, around-

template, after-returning-template e after-throwing-template, representam a maneira que o método-gabarito será afetado. O tipo enumerado before-template representa que o método gabarito será afetado no contexto “antes”. O tipo enumerado after-template representa que o método gabarito será afetado no contexto “depois”. O tipo enumerado around-template representa que o método gabarito será afetado no contexto “durante”. O tipo enumerado after-returnig-template representa que o método gabarito será afetado no contexto “após o retorno”. Por fim o tipo enumerado after-throwing-template representa que o método gabarito será afetado no contexto “após o lançamento”. O estereótipo markerInterface especifica características transversais dependentes de uma interface, que são conectadas a aplicação mais tarde. As características transversais são especificadas pelo estereótipo aspectSpecification. O estereótipo container encapsula um número de características extrínsecas que são introduzidas mais tarde em uma classe alvo. O estereótipo containerLoader especifica essas características extrínsecas e o estereótipo containerConnector faz a ligação entre container e a classe alvo.

4. Estudo de caso

Na Figura 2 é apresentado um estudo de caso com a aplicação do perfil proposto. Um framework de persistência (Camargo e Masiero, 2008) é usado juntamente com uma aplicação de oficina eletrônica. É possível observar que a Figura 2 está dividida em três partes: a parte que compete ao engenheiro do framework, a parte que compete ao engenheiro da aplicação e a parte da aplicação base. A parte do engenheiro do framework é a parte onde se localiza o framework de persistência, que é a parte onde esse engenheiro pode realizar a manutenção do framework. A parte do engenheiro de aplicação possui os aspectos concretizados que afetarão a aplicação base. Essa divisão auxilia no trabalho dos engenheiros de framework e de aplicação deixando explícita apenas a parte do framework que lhes interessa. É ressaltado que na Figura 2, essas partes estão separadas por meio da linha tracejada para facilitar o entendimento da aplicação do perfil. Na prática, em sistemas de maior porte isso não ocorre: as classes e aspectos estarão misturados e os estereótipos identificam se determinada classe ou aspecto é de interesse do engenheiro do framework ou do engenheiro de aplicação, melhorando a legibilidade.


75

Figura 2 – Estudo de caso.

A parte do engenheiro do framework, onde se encontra o framework de persistência, utiliza os estereótipos aspect-F, class-F, interface-F. Esses estereótipos indicam respectivamente que o aspecto, a classe e a interface são de interesse do engenheiro de framework. Já a parte do engenheiro de aplicação é a parte onde ocorre o reúso e a instanciação do framework. A instanciação é o processo de reúso do framework feita pelo engenheiro de aplicação. Os estereótipos aspect-App e class-App indicam um aspecto e uma classe respectivamente que são de interesse do engenheiro de aplicação. A facilidade que esses estereótipos proporcionam na identificação das classes/aspectos, facilita o trabalho desses engenheiros na realização de suas tarefas.

Note-se que o aspecto DirtyObjectController faz uso do estereótipo <<CrossCuttingFeature>>. Esse estereótipo representa que alguns métodos e atributos


76

estão sendo adicionados em uma classe ou aspecto. A expressão <<StaticCrossCuttingFeature>> -Dirty : boolean {onType =

PersistentRoot} representa a adição de um atributo denominado Dirty do tipo boolean na interface PersistentRoot. Já a expressão <<StaticCrossCuttingFeature>> +isDirty ( ) {onType =

PersistentRoot} representa a adição de um método denominado isDirty na interface PersistentRoot. O mesmo raciocínio é válido para a expressão <<StaticCrossCuttingFeature>>+setDirty( ){onType = PersistentRoot}.

Os aspectos abstratos PersistentEntities e ConnectionCompositon fazem uso do estereótipo <<PointCutHook>>. A expressão <<PointCutHook>>

OpenConnection() representa que o conjunto de junção gancho OpenConnection() é abstrato e deve ser concretizado pelo engenheiro de aplicação em um aspecto concreto. O aspecto abstrato PersistentEntities é utilizado pelo engenheiro de aplicação (quando concretizado) para definir os métodos persistentes. Já o aspecto abstrato ConnectionCompositon é utilizado para definir os adendos com os respectivos conjuntos de junção que atuarão sobre os métodos persistentes (quando for concretizado). O aspecto abstrato PersistentEntities possui também o estereótipo <<containerLoader>> pois esse aspecto possui métodos que são adicionados à interface PersistentRoot. Assim a interface PersistentRoot recebe o estereótipo <<container>> já que essa interface encapsula esses métodos. O aspecto concreto MyPersistentEntities possui o estereótipo <<containerConnector>> por referenciar onde os métodos de PersistentEntities serão encapsulados.

O aspecto XOORelationalMapping é uma interface de entrecorte (Crosscutting Interface) (Griswold et al., 2006) . Esse aspecto possui só os conjuntos de junção e o aspecto OORelationalMapping possui só os adendos. Assim, o aspecto OORelationalMapping é estereotipado com <<aspectSpecification>> por especificar as características do entrecorte. Isso estereotipa a interface PersistentRoot com <<markerInterface>> por especificar as características de entrecorte dependentes de uma interface. O relacionamento de dependência entre os aspectos indica que os adendos dependem dos conjuntos de junção declarados no aspecto XOORelationalMapping.

A classe abstrata ConnectionManager define a maneira pelo qual será feita a conexão pelo banco de dados. O engenheiro de aplicação poderá definir o banco de dados apropriado quando ele concretizar a classe abstrata OdbcConnection.

O aspecto MyPersistentEntities que está na parte do engenheiro de aplicação, possui a etiqueta declaredImplements. Ela permite a declaração de interface do tipo “realize”. Dessa forma declaredImplements = myImplementation mostra que as classe employee, event, baseSalary e function “realizes” PersistentRoot. Isso é notado pelos relacionamentos de cada uma das classes com a interface PersistentRoot.

Os aspectos ConnectionComposition e MyConnectionComposition utilizam dois estereótipos: <<Advice>> e <<ExecutionPointCut>> respectivamente. A expressão <<ExecutionPointCut>>-openConnection {operation =


77

registerEvent} representa que um conjunto de junção denominado openConnection foi criado e que o método que ele afeta é o registerEvent. O estereótipo <<Advice>> é utilizado para denotar adendos, assim a expressão <<Advice>> +open(){poinCut = openConnection, adviceExecution = BeforeAdvice} representa que o conjunto de junção openConnection será afetado no contexto “antes”. É assim que os estereótipos atuam nos métodos da aplicação. Não são utilizados relacionamentos de entrecorte.

É interessante perceber que a utilização dos idiomas facilitam a compreensão e a análise do modelo. Por exemplo, quando o projetista percebe a existência do estereótipo <<container>> em alguma interface, automaticamente deve existir no modelo um aspecto que introduz propriedades nessa interface e que deve possuir o estereótipo <<containerLoader>>. Da mesma forma, quando alguma interface possui o estereótipo <<markerInterface>> automaticamente procura-se por um aspecto que faz o papel de <<aspectSpecification>>. Isso auxilia bastante na compreensão dos modelos e também do funcionamento do framework.

5. Trabalhos Relacionados

Embora vários tenham sido os pesquisadores que propuseram linguagem de modelagem para POA (Aldawud et al., 2003; Barra et al., 2004; Evermann et al., 2007; Groher e Baumgarth, 2004), apenas um deles propôs uma técnica específica para FOA. Rausch (2004) propôs modelos nos níveis de requisitos e projeto para frameworks orientados a aspectos. Também foi desenvolvida uma técnica para “colar” os modelos. Esta técnica utiliza das setas bidirecionais e “notas” que contém uma OCL. Cada hot spot (ex. pontos de junção, introductions) é especificado dentro das notas. Por meio da OCL os elementos do pacote da aplicação são ligados com os hot spots do framework.

O trabalho de Rausch (2004) possui algumas deficiências, algumas delas reconhecidas pelos próprios autores: a ausência de um meta-modelo impossibilita o desenvolvimento de uma ferramenta. Uma ferramenta para auxiliar a junção dos modelos é necessária e ela deve ser consistente com a junção do código da POA; um perfil UML completo para POA precisa ser desenvolvido, para que a partir dele possa ser proposto um perfil para frameworks orientados a aspectos; uma linguagem de ligação mais apropriada deve ser desenvolvida para evitar trechos complexos de OCL.

6. Conclusão

Os elementos notacionais criados nesse trabalho visam auxiliar tanto o desenvolvedor do framework quanto o desenvolvedor da aplicação evidenciando características importantes do desenvolvimento e da utilização de frameworks. Ressalta-se que é perfeitamente possível que FTs possam ser desenvolvidos e utilizados sem que esses elementos sejam utilizados. Entretanto, sua utilização traz benefícios de manutenibilidade, reusabilidade e produtividade para os profissionais envolvidos no processo.

A arquitetura final de uma aplicação que foi desenvolvida com o apoio de vários FTs é complexa. A existência de estereótipos que ajudem identificar as partes importantes dessa complexa arquitetura é importante para a utilização da aplicação.


78

O perfil para FTs apresentado necessita ser aprimorado. Um estudo de caso maior, que utilize todos os estereótipos e idiomas para FOAs, avaliando de forma mais precisa a semântica do perfil será realizado em trabalhos futuros. Os conflitos que podem ocorrer entre os estereótipos criados também serão analisados em trabalhos futuros. Uma comparação entre a manutenibilidade de um framework modelado com de maneira convencional e com o perfil proposto também será feito em trabalhos futuros.

Referências Bibliográficas

Aldawud, O., Elrad, T., Bader. A. UML Profile for Aspect-Oriented Software Development. In: Proceedings of Workshop of Aspect Oriented Modeling with UML of Aspect Oriented Software Development Conference (AOSD), 2003.

Barra, E., Génova, G. and Llorens, J. 2004. An approach to aspect modeling with UML 2.0. In Proc. 5th Int. Workshop on Aspect-Oriented Modeling, October 2004.

Camargo, V.V.; Masiero, P.C. A Pattern to Design Crosscutting Frameworks. In: Proceedings of the 23rd Annual ACM Symposium on Applied Computing (ACM-SAC'08), Fortaleza, Brasil, 2008.

Evermann, Joerge. 2007. A Meta-Level Specification and Profile for AspectJ in UML. Victoria University Wellington, Wellington, New Zealand. AOSD 2007.

Fontoura, M., Pree, W., Rumpe, B. The UML Profile for Framework Architectures. Addison Wesley, 2002.

Griswold, W.G., Shonle, M., Sullivan, K., Song, Y., Cai, Y., Rajan, H. Modular Software Design with Crosscutting Interfaces, IEEE Software, pp 51-60, 2006.

Groher, Iris, Baumgarth, Thomas. 2004. Aspect-Orientation from Design to Code. Munich, Alemanha. 2004.

Hanenberg, S., Unland, R., Schmidmeier, A. AspectJ Idioms for Aspect-Oriented Software Construction. In: Proceedings of 8th European Conference on Pattern Languages of Programs (EuroPLoP), Irsee, Germany, 25th–29th June, 2003.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irving, J. Aspect Oriented Programming. In: Proceedings of ECOOP. pp. 220-242, 1997.

Pinto, M., Fuentes, L., Fayad, M.E, Troya, J.M. Separation of Coordination in a Dynamic

Aspect Oriented Framework. In: Proceeding of the 1st International Conference on Aspect-Oriented Software Development, April 2002.

Rashid, A., Chitchyan, R. Persistence as an Aspect. In: Proceedings of 2nd International Conference on Aspect Oriented Software Development – AOSD. Boston – USA, 2003.

Rausch, A., Rumpe, B., Hoogendoorn, L. Aspect-Oriented Framework Modeling. In: The 4th AOSD Modeling With UML Workshop. 2004.

Soares, S., Laureano, E., Borba, P. Implementing Distribution and Persistence Aspects with AspectJ. In: Proc. the 17th ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), pp 174-190, November, 2002.


79

Documents

Um Perfil UML para Projeto de Frameworks Transversais · 2. Conceitos Fundamentais Fazendo o uso da UML 2.0, Evermann (2007) desenvolveu um meta-modelo que é um perfil UML específico