Programação Orientada a Aspectos - Técnicas e paradigmas para a modularização de software.

Tamanho: px
Começar a partir da página:

Download "Programação Orientada a Aspectos - Técnicas e paradigmas para a modularização de software."

Transcrição

1 Programação Orientada a Aspectos - Técnicas e paradigmas para a modularização de software. Dissertação de Mestrado apresentada por Luís Filipe Félix de Sá Sob orientação do Prof. Doutor Ramiro Gonçalves e do Prof. Doutor Carlos Rabadão Universidade de Trás-os-Montes e Alto Douro Departamento de Engenharias 2008

2 "Controlling complexity is the essence of computer programming." (Brian Kernigan) II

3 III Dissertação apresentada por Luís Filipe Félix de Sá à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Informática, sob a orientação do Prof. Doutor Ramiro Manuel Ramos Moreira Gonçalves, Professor Auxiliar do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro e co-orientada pelo Prof. Doutor Carlos Manuel da Silva Rabadão, Professor Adjunto do Departamento de Engenharia Informática da Escola Superior de Tecnologia e Gestão do Instituto Politécnico de Leiria.

4 Aos meus Pais. IV

5 V AGRADECIMENTOS A todos os meus amigos e colegas Francisco Silva, Marta Pimenta, Diana Santos, Isabel Marcelino, Andreia Penedo, Ana Oliveira, Rúben Pedro, Rodrigo Selada, Bruno Alves, Márcia, Tiago Conde pela amizade, dedicação e apoio constantes. Aos meus orientadores Professor Doutor Ramiro Gonçalves e Professor Doutor Carlos Rabadão e Co-Orientador Professor Marco Monteiro, pela partilha de conhecimentos e experiência. A todos o meu muito obrigado! Luís Filipe Félix de Sá

6 VI RESUMO O desenvolvimento de software é uma tarefa complexa, onde se decompõe um problema localizando todas as suas preocupações. As tecnologias existentes para a implementação destas são limitadas devido à sua inadequação para as modularizar. Assim, deu-se o aparecimento de uma nova tecnologia, a Programação Orientada a Aspectos. Esta tecnologia não vem substituir mas sim estender as tecnologias existentes, melhorando-as, permitindo novas formas de modularidade, diminuindo o tempo de desenvolvimento e aumentando a reutilização de software.

7 VII ABSTRACT Software development is a complex task, where a problem is decomposed identifying all its concerns. The current technologies for implementing them are unable to modularize all of them. Therefore, a new technology was developed, Aspect Oriented Programming. This technology doesn t come to replace rather to improve current technologies, with new ways to achieve software modularity, resulting in a decrease of developing time and increased software reuse.

8 VIII INDICE GERAL AGRADECIMENTOS... V RESUMO... VI ABSTRACT... VII INDICE GERAL... VIII LISTA DE TABELAS... XII LISTA DE FIGURAS... XIII ACRÓNIMOS... XV 1. INTRODUÇÃO ENQUADRAMENTO TECNOLÓGICO OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS ESTRUTURAÇÃO DA DISSERTAÇÃO TÉCNICAS E PARADIGMAS DA PROGRAMAÇÃO PARADIGMA DE PROGRAMAÇÃO LINGUAGEM DE PROGRAMAÇÃO FORMAS DE SEPARAÇÃO Abstracção Ocultação de informação... 10

9 IX Encapsulamento PROGRAMAÇÃO ESTRUTURADA PROGRAMAÇÃO ORIENTADA A OBJECTOS Linguagens POO PROGRAMAÇÃO ORIENTADA A COMPONENTES PROGRAMAÇÃO PÓS-OBJECTOS META-PROGRAMMING SUBJECT-ORIENTED PROGRAMMING PROGRAMAÇÃO ADAPTATIVA FILTROS DE COMPOSIÇÃO PROGRAMAÇÃO ORIENTADA A ASPECTOS AspectJ SEPARAÇÃO MULTIDIMENSIONAL DE CONCERNS DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS COMUNIDADES E SITUAÇÃO EM PORTUGAL DESAFIOS, PROBLEMAS E OPORTUNIDADES PROGRAMAÇÃO ORIENTADA A ASPECTOS COMPORTAMENTOS GLOBAIS ANÁLISE DO PROBLEMA SISTEMA MODULAR SISTEMA POA METODOLOGIA DSOA ANATOMIA DA LINGUAGEM POA... 50

10 X 3.7 ESPECIFICAÇÃO DAS LINGUAGENS Software concerns Regras de combinação COMPOSIÇÃO DE SISTEMAS Weaving Weaver BENEFÍCIOS DA POA DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS Identificação de concerns Implementação DEVENVOLVIMENTO UTILIZANDO ASPECTJ Análise Ferramentas de Desenvolvimento POSTSHARP PostSharp LAOS Análise da Tecnologia PostSharp Core AspectJ vs. Postsharp LAOS Conclusões MODULARIZAÇÃO DE PADRÕES DE DESENHO Exemplo Observer Pattern Análise dos Estudos... 77

11 XI 3.14 MODULARIZAÇÃO DE EXCEPÇÕES FRAMEWORKS MÉTRICAS CONSIDERAÇÕES FINAIS BIBLIOGRAFIA ANEXOS... 95

12 XII LISTA DE TABELAS Tabela 1 Cronograma temporal da investigação sobre separação de concerns Tabela 2 - comparação da nomenclatura do AspectJ e Postsharp Laos Tabela 3 Comparação de pointcuts entre PostSharp Laos e AspectJ Tabela 4 - Comparação de pointcuts entre PostSharp Laos e AspectJ Tabela 5 comparação de tipos Tabela 6 Resumo das comparações dos padrões de desenho Tabela 7 Evolução da utilização de POO e POA, segundo as métricas de Sant Anna Tabela 8 - Comparação de métricas entre Java e AspectJ primeira parte Tabela 9 - Comparação de métricas entre Java e AspectJ segunda parte

13 XIII LISTA DE FIGURAS Figura 1 - Módulos com acesso concorrente aos dados Figura 2 - Hierarquia de classes Figura 3 Espalhamento de Concerns Figura 4 - Meta-programming Figura 5 - Subject-oriented programming Figura 6 - Filtros de composição Figura 7 Diagrama do exemplo Figura 8 - Interacção entre Módulos Figura 9 - Sobreposição de unidades elementares Figura 10 - Comportamentos Globais do Sistema Figura 11 - Metodologia POA Figura 12 Weaver de código fonte Figura 13 - Weaver de código intermédio Figura 14 - Comunicação normal entre objectos Figura 15 - Comunicação utilizando uma proxy Figura 16 Adição de comportamentos adicionais através de proxys

14 XIV Figura 17 - Sistema de Desenvolvimento de Software Orientado a Aspectos Figura 18 Incisão do estudo de Early-Aspects Figura 19 Processo de integração do Postsharp Figura 20 Padrão de Desenho Observer implementado em POO Figura 21 Padrão de desenho Observer implementado em POA Figura 22 - Modelo de Qualidade

15 XV ACRÓNIMOS Ao longo desta dissertação vão ser utilizadas algumas abreviaturas e designações que apenas serão apresentadas quando forem utilizadas pela primeira vez: POA POO DSOA POC GOF JVM IDE CME Programação Orientada a Aspectos Programação Orientada a Objectos Desenvolvimento de Software Orientado a Aspectos Programação Orientada a Componentes Padrões de Desenho Gang-of-Four Java Virtual Machine Intregrated Development Envionment Concern Manipulation Envionment

16 1 1. INTRODUÇÃO Em 1997 foi proposto um novo paradigma de programação, a Programação Orientada a Aspectos (POA), cujo principal objectivo era apresentar uma extensão aos paradigmas existentes até à data, retendo os pontos onde estes demonstraram a sua eficiência, o desenvolvimento das funcionalidades base de um sistema. Apresentando uma nova forma de modularidade onde os antigos paradigmas manifestavam reais fragilidades, esta nova extensão incide especialmente nos comportamentos transversais ao sistema (crosscutting concerns) [Kiczales, Lamping et al. 1997]. Este novo paradigma propõe a decomposição dos sistemas pelas suas variadas preocupações dividindo o software em concerns (preocupações) base (funcionalidades base do sistema) e transversais (funcionalidades globais ao sistema). É introduzido um novo conceito, o aspecto, que consiste numa unidade modular que possui uma visão global do sistema, o que lhe permite fazer a coordenação e comunicação entre concerns. Para estes, este processo é transparente. A transferência da coordenação e comunicação entre diferentes tipos de concerns para os aspectos, permite-os libertar de questões globais ao sistema tornando-os independentes. A composição de concerns é efectuada através de um compilador, Weaver, cujo resultado é um sistema onde existe uma clara separação e abstracção entre todos os concerns que definem o comportamento do sistema. O sistema torna-se claro de ler, escrever e manter, as

17 2 funcionalidades adicionais são simples de acoplar ao sistema e o desenho inicial é mais consistente com a sua implementação concreta. Outras tecnologias com objectivos semelhantes foram desenvolvidas: Programação Adaptativa [Lieberherr 1996], Filtros de Composição [Mehmet Aksit 1994], Subject Oriented Programming [Harrison and Ossher 1993], Separação Multidimensional de Concerns [Tarr, Ossher et al. 1999] e Programação Gerativa [Czarnecki, Eisenecker et al.]. A separação avançada de concerns 1 2, a Programação Pós-Objectos [Elrad, Filman et al. 2001; Hayes 2003] e o Desenvolvimento de Software Orientado a Aspectos 3 4 (DSOA) são as áreas de investigação em que a POA se enquadra. 1.1 ENQUADRAMENTO TECNOLÓGICO A separação de concerns é um princípio fundamental que determina a resolução de um concern de cada vez [Dijkstra 1976]. Em engenharia de software, o princípio da sua separação está normalmente relacionado com a decomposição e modularização de sistemas [Parnas 1972]: os sistemas de software complexos devem ser decompostos em unidades modulares menores e claramente separadas, cada uma lidando com um único concern. Sendo de destacar como benefícios a sua melhor compreensibilidade e um maior potencial para a evolução e reutilização em outros sistemas de software complexos. Os mecanismos de composição e abstracção que sucessivas gerações de linguagens de programação oferecem, evoluíram para permitir a 1 (Acedido, Julho 2008) 2 (Acedido, Julho 2008) 3 (Acedido, Julho 2008) 4 (Acedido, Julho 2008)

18 3 resolução de problemas do mundo real de forma mais natural, assim como, para possibilitar o alcance da separação de concerns ao nível do código-fonte. A Programação Orientada a Objectos (POO) tem sido a tecnologia de programação dominante sendo os seus benefícios amplamente reconhecidos. No entanto, a POO possui algumas limitações no tratamento de concerns, nomeadamente no que respeita aos requisitos que envolvam restrições globais e propriedades sistémicas, como é exemplo: a sincronização, a persistência, o tratamento de erros, entre outros. Estas limitações necessitam de uma tecnologia que permita uma rotura, ou seja, algo que esteja realmente para além dos objectos [Booch 2001]. Relativamente à POA, esta é uma tecnologia em evolução que oferece suporte a um novo tipo de separação de concerns no nível do código-fonte. É vista como sendo evolucionária porque considera as melhorias reconhecidas da sua separação, proporcionadas pelas tecnologias anteriores (principalmente, mas não apenas, a POO) enquanto oferece suporte a novos mecanismos para lidar com alguns concerns especiais que não são tratados adequadamente por essas tecnologias. A ideia central por trás da POA é que os mecanismos de abstracção e composição das tecnologias existentes não são suficientes para separar alguns concerns especiais encontrados em sistemas mais complexos. Denominados de crosscutting concerns, pois afectam a modularidade de vários elementos penetrando" os seus limites, estes, sem os meios apropriados para a separação e a modularização, tendem a ficar espalhados e entrelaçados com outros concerns. Como consequências naturais reporte-se uma menor compreensibilidade, uma menor capacidade de evolução e uma menor reutilização dos artefactos do código. Esta tecnologia utiliza aspectos para alcançar a modularização de crosscutting concerns e fornece mecanismos para a sua combinação em pontos bem definidos.

19 4 A POA e a maioria dos trabalhos existentes sobre a separação avançada de concerns tratam do fenómeno de crosscutting no nível de implementação, tendo recentemente muitos grupos de pesquisa começado a discutir a função dos aspectos em outras actividades do processo de desenvolvimento de software. Deste modo, o Desenvolvimento de Software Orientado a Aspectos (DSOA) revela-se uma área emergente cujo objectivo, é promover a separação avançada de concerns ao longo de todo o ciclo de vida do desenvolvimento de software. O Design Orientado a Aspectos (DOA) é assim, uma parte crítica do DSOA que se concentra em notações, técnicas e ferramentas para a identificação, a estruturação, a representação e a gestão de crosscutting concerns no projecto e arquitectura de software, oferecendo um linhagem desde os requisitos até a implementação com POA. 1.2 OBJECTIVOS E CONTRIBUTOS FUNDAMENTAIS O principal objectivo deste projecto de investigação é apresentar um documento, com vista a descrever paradigmas e técnicas que se propõem a melhorar a separação de concerns. São expostas as desvantagens da sua não separação, como é possível alcançar essa separação enumerando as suas vantagens e desvantagens. Este trabalho propõe-se ainda a detalhar princípios, metodologias e práticas de algumas linguagens e tecnologias POA, recorrendo à exemplificação prática, a exemplos de aplicações dessas tecnologias e à apresentação de estudos de investigação sobre análise de resultados empíricos, utilizando métricas bem conhecidas e documentando as principais ferramentas, linguagens e a sua forma de utilização.

20 5 1.3 ESTRUTURAÇÃO DA DISSERTAÇÃO Inicia-se este trabalho com uma pequena apresentação deste estudo, seguindo-se o seu enquadramento, bem como, os objectivos definidos para o seu prosseguimento. Desta forma no Capitulo 2 apresenta-se uma breve evolução das várias técnicas e paradigmas que contribuíram para o aparecimento e desenvolvimento do Paradigma Orientado a Aspectos. Descrevendo-se as técnicas e tecnologias que com mais ou menos complexidade permitem alcançar uma melhor modularidade nos sistemas de software. No Capítulo 3 é desenvolvido de forma prática o Paradigma Orientado a Aspectos, linguagens de programação e aplicações práticas do paradigma. Apresenta-se o Paradigma Orientado a Aspectos, o que é, que problemas se pretendem resolver e como pode ser implementado. É apresentada a linguagem AspectJ e, de seguida, a tecnologia PostSharp. Algumas aplicações da Programação Orientada a Aspectos nomeadamente a modularização de padrões de desenho, a modularização de excepções e estudos que apresentam métricas para possibilitar a quantificação empírica de programas POA também são apresentadas e descritas. Finalmente no 4º e último Capítulo exibem-se as principais conclusões deste projecto de investigação.

21

22 7 2. TÉCNICAS E PARADIGMAS DA PROGRAMAÇÃO No âmbito do objectivo deste trabalho de projecto, procurou-se aprofundar os conhecimentos relativos às diversas técnicas e paradigmas que possibilitam resolver o problema da separação de concerns. Para este fim tornou-se necessário a análise de uma variadíssima fonte bibliográfica alusiva a esta temática, possibilitando-nos assim, expor uma visão mais holística do estudo aqui em análise. 2.1 PARADIGMA DE PROGRAMAÇÃO Um paradigma da programação pode ser definido como um conjunto de teorias e métodos que representam uma forma particular de se tentar organizar o conhecimento numa dada área [Kuhn 1970], ou como, modelos ou exemplos, e abordagens organizacionais, que permitem conceptualizar o que se deve entender por computações, bem como se devem estruturar e organizar as tarefas que se pretendem ver realizadas por um computador [Floyd 1979]. Um paradigma da programação permite disponibilizar ao programador uma visão e uma forma de raciocinar de modo a que este consiga desenvolver e executar um programa de computador, podendo-se definir este último, como uma colecção de instruções na forma de

23 8 código e de variáveis que possibilitam a um computador manipular uma determinada informação. No âmbito deste projecto entende-se paradigma segundo a visão de Floyd. 2.2 LINGUAGEM DE PROGRAMAÇÃO Uma linguagem de programação possibilita que um programador especifique precisamente sobre quais dados, um computador vai actuar, como estes deverão ser armazenados ou transmitidos e que acções devem ser tomadas sob as mais variadas circunstâncias. Assim, linguagem de programação é entendida como um método normalizado para expressar instruções para um computador, ou seja, é um conjunto de regras sintácticas e semânticas usadas para definir um programa de computador. 2.3 FORMAS DE SEPARAÇÃO A evolução das linguagens de programação permitiu abstrair os programadores dos pormenores das plataformas e das máquinas em que os programas são executados, possibilitando mecanismos superiores de composição e abstracção, onde estes se ajustam aos problemas de uma forma mais natural, numa visão centrada no problema. Esta visão permite uma separação natural do problema por todos os seus concerns [Dijkstra 1976]. A separação de um sistema de software em módulos aumenta a flexibilidade, a compreensibilidade e diminui o tempo de desenvolvimento. Um módulo pode ser assim entendido como um pedaço de software independente, que faz parte de um programa de

24 9 computador, funcionando como uma caixa negra onde do exterior só é possível interagir com a sua interface (forma de ligação com o interior) [Parnas 1972]. Nesta continuidade, os módulos independentes podem ser desenvolvidos separadamente com informação mínima sobre outros módulos. As equipas de desenvolvimento que são atribuídas a cada módulo focam-se na sua especialidade (segurança, base de dados, etc.), o que provoca uma diminuição do tempo de desenvolvimento. Os módulos internamente podem ser redesenhados e implementados novamente para acomodar as alterações necessárias, sem que isto afecte o sistema, tornando-o flexível à evolução. A possibilidade de analisar e desenhar o sistema módulo a módulo torna-o mais compreensível. A sua separação pode ser alcançada através de vários conceitos tais como abstracção, ocultação de informação e encapsulamento como se poderá verificar nas secções seguintes Abstracção Estabelecida como um processo que extrai detalhes importantes de um item e suprime os não importantes, a abstracção também pode ser vista como um modelo ou visão que representa um item - por exemplo, as pessoas podem dizer diga-me só os pontos-chave, este facto representa uma forma de abstracção. Podemos ver abstracção como uma técnica que dita que informação é mais importante que outra, mas não especifica como lidar com a menos importante [Berard 2002].

25 Ocultação de informação O conceito de ocultação de informação para a construção de módulos é comum ser confundido com abstracção. Como anteriormente referido, a abstracção permite identificar a informação e posteriormente ocultar a menos importante, utilizando para este efeito técnicas de ocultação de informação disponibilizadas pelas linguagens de programação (funções, subrotinas, classes, etc.) [Berard 2002] Encapsulamento Designa-se por encapsulamento o agrupamento de um ou mais itens, não sendo definido a forma como ele é delimitado. Este processo não é o mesmo que o da ocultação de informação. Embora a informação esteja encapsulada, esta pode não estar escondida - por exemplo, uma estrutura encapsula uma determinada quantidade de informação mas esta pode ainda ser cedida, embora possam ser definidas regras para restringir esse acesso. Dito isto, o encapsulamento permite agrupar informação e definir qual ocultar ou qual tornar visível [Berard 2002]. 2.4 PROGRAMAÇÃO ESTRUTURADA Tendo-se iniciado para efectuar cálculos numéricos, os programas de computador começaram por ser desenvolvidos em código máquina através da introdução de novas linguagens de programação, entre elas o Fortran [Backus, Beeber et al. 1957], tornando possível elaborar sistemas de software mais complexos sem recorrer a este intrincado código.

26 11 Com o aumento da complexidade do processo de desenvolvimento de software levantaram-se problemas de fiabilidade e adaptabilidade, sugerindo-se assim, a eliminação das instruções goto das linguagens de programação de alto nível, substituindo-as por estruturas de sequência, de divisão e de iteração [Dijkstra 1968]. A utilização das instruções goto pode ter efeitos devastadores uma vez que podem surgir problemas devido ao facto de esta instrução alterar o fluxo do programa. Todavia, o seu comportamento não pode ser avaliado ao longo da fase de implementação utilizando um conjunto de manipulações matemáticas e lógicas que permitam demonstrar a existência de erros [Dijkstra 1976]. Enumeram-se assim, como principais Linguagens de Programação Estruturada: Fortran [Backus, Beeber et al. 1957], Pascal [Wirth 1971] e C [Kernighan and Ritchie 1988]. As principais características da Programação Estruturada consistem em: design descendente: decompõe-se o problema por etapas ou estruturas hierárquicas; recursos abstractos (simplicidade): consiste em decompor acções complexas noutras mais simples, capazes de serem resolvidas com maior facilidade, ou seja, as acções complexas são abstraídas em subrotinas ou em funções; estruturas básicas: o estrutura sequencial: a cada acção segue-se outra acção sequencialmente, isto é, a saída de uma acção é a entrada em outra acção; o estruturas de divisão: avaliam condições lógicas e, em função do resultado das mesmas, realizam uma acção ou outra; o estruturas de iteração: são sequências de instruções que se repetem um determinado número de vezes.

27 12 Para melhor alcançar a separação de concerns foi sugerida a introdução de critérios para a decomposição do sistema em módulos de maneira a permitir uma melhor flexibilidade e compreensibilidade do sistema, definindo quais os métodos mais efectivos da decomposição em módulos utilizando técnicas de abstracção e ocultação de informação fornecidas pela Programação Estruturada [Parnas 1972]. Todavia é de referir a existência de problemas na Programação Estruturada, sendo de destacar: o código espalhado das invocações aos vários módulos independentes, bem como, o facto de os módulos abstraírem os procedimentos, as instruções, mas não conseguirem abstrair o acesso aos dados (figura 1) resultando tal situação em programas maiores, menos flexíveis e mais difíceis de desenvolver e de reutilizar ao longo do tempo. Figura 1 - Módulos com acesso concorrente aos dados. (Adaptada de [Booch 1994])

28 PROGRAMAÇÃO ORIENTADA A OBJECTOS Nesta visão, o programa descreve estruturas e comportamentos de objectos e classes de objectos. Um objecto encapsula dados passivos e disponibiliza operações activas sobre esses dados, a estrutura dos dados do objecto define o seu estado e os métodos definem o seu comportamento. A execução de um programa orientado a objectos é a troca de mensagens entre objectos que modificam o seu estado [Booch 1994]. Na POO o problema é decomposto em classes e em objectos pertencentes ao domínio do problema, onde os dados e os procedimentos já não estão separados e os detalhes da sua interacção são encapsulados em objectos [Booch 1994]. Alguns fundamentos da POO são a herança e o polimorfismo, onde a primeira possibilita aos objectos herdar propriedades, permitindo a reutilização de comportamentos, de outros objectos. A existência de hierarquia de objectos (figura 2) facilita a compreensão do problema e, através do polimorfismo, permite-se o tratamento desses objectos de forma igual. O encapsulamento faculta assim a modificação do conteúdo interno dos objectos sem que essas alterações afectem outros objectos. Figura 2 - Hierarquia de classes

29 14 Em suma, alguns princípios usados na POO são: o Princípio open closed: especifica que o desenho e desenvolvimento do código deve permitir a extensão de novas funcionalidades (open) e minimizar alterações aos módulos existentes (closed). O sistema abre-se a novas funcionalidades mas deve estar encerrado a alterações que provocam incompatibilidades a módulos existentes; o Princípio da substituição de Liskov [Liskov and Wing 2001]: possibilita substituir referências de classes base por uma outra classe que derive desta sem afectar o normal funcionamento do módulo; o Princípios da inversão da dependência: módulos hierarquicamente superiores não devem depender de módulos hierarquicamente inferiores. Todos devem depender de abstracções e esta última não deve depender de detalhes. Enquanto que os detalhes devem depender de abstracções Linguagens POO Remontando à história da Linguagens POO dá-se especial destaque aos inícios dos anos 60 com o aparecimento da linguagem de programação Simula 67, criada por Ole-Johan Dahl e Kristen Nygaard. Nos anos 70 inicia-se o desenvolvimento do Smalltalk na Xerox PARC, alguns anos depois Bjarne Stroustrup cria o C++ e finalmente na década de 90 foi criado na empresa Sun o Java por James Gosling.

30 PROGRAMAÇÃO ORIENTADA A COMPONENTES A Programação Orientada a Componentes (POC) permite elaborar programas a partir de componentes de software pré-fabricados contidos em blocos de código executáveis. Os componentes têm de seguir padrões específicos predefinidos, incluindo a inclusão de uma interface e uma gestão de versões para garantir uma boa reutilização. O objectivo da POC, passa assim por desenvolver software combinando componentes pré-fabricados. Enquanto a POO dá ênfase a classes e objectos, a POC enfatiza interfaces e composição. Os clientes dos componentes não necessitam de possuir conhecimentos de como é que um componente é implementado, enquanto as interfaces de ligação continuam inalteradas, os clientes não serão afectados por alterações na implementação do componente [Szyperski 1998]. Brown sumaria algumas definições do que é um componente [Brown and Wallnau 1998]: A component is a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. (Philippe Krutchen, Rational Software) A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime. (Gartner Group) A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. (Clemens Szyperski)

31 16 A business component represents the software implementation of an autonomous business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system. (Wojtek Kozaczynski, SSA) A software component is a piece of self-contained, self-deployable computer code with well-defined functionality and can be assembled with other components through its interface. [Brown and Wallnau 1998] Um componente de software é um bloco de código executável, pronto a usar, com funcionalidades bem definidas, que pode ser combinado com outros componentes através de uma interface. Deste modo, um componente não é um objecto, mas disponibiliza recursos para os instanciar. Muitas vezes, um único componente disponibiliza interfaces para várias classes interrelacionadas, daí a POC focar-se na arquitectura e encapsulamento (packging) ao invés da intercooperação entre objectos[szyperski, Bosch et al. 1999]. Alguns dos seus princípios são [Löwy 2003]: o Separações da interface da implementação: alterações na implementação não devem ser reflectidas na interface de ligação com os clientes; o Compatibilidade entre binários: na POC os binários, geralmente não estão compilados com o código da aplicação, mas sim separadamente e são invocados pela aplicação. É permitido que os componentes possam ser substituídos por novas versões, deste modo deverá existir compatibilidade dos binários entre as várias versões;

32 17 o Independência da linguagem: a escolha de uma linguagem de programação não deve impedir o uso de um componente; o Transparência da localização: os componentes podem existir no mesmo processo do programa ou noutro local. Para os componentes, o lugar onde estes são executados deve ser transparente; o Gestão de concorrência: como não é possível prever o uso que os componentes irão ter por parte dos clientes, dever-se-á implementá-los de forma a prever o pior caso possível. Para tal, os componentes devem implementar mecanismos de sincronização de acesso; o Controlo de versões: novas versões de componentes não deverão afectar as aplicações dos clientes existentes. Deve existir uma tecnologia que permita a evolução dos componentes mas que ao mesmo tempo permita o acesso às suas versões mais antigas; o Segurança com base em componentes: os componentes devem apresentar garantias aos clientes de que estes não são comprometidos por ataques; Exemplos de algumas tecnologias que aplicam este paradigma: COM 5 - Component Object Model J2EE 6 - Java 2 Platform, Enterprise Edition CORBA 7 - Common Object Request Bro-ker: Architecture and Specifications COM+ 8 - Component Object Model Plus 5 (Acedido em Junho 2008) 6 (Acedido em Junho 2008) 7 (Acedido em Junho 2008)

33 18 DCOM 9 - Distributed Component Object Model ActiveX 10.NET Framework PROGRAMAÇÃO PÓS-OBJECTOS A POO apesar dos seus benefícios, apresenta algumas lacunas principalmente no que concerne aos requisitos globais e às propriedades sistémicas. Não é possível neste tipo de concerns decompô-los e organizá-los num único local. Assim estes tendem a estar espalhados e entrelaçados com outros concerns[elrad, Filman et al. 2001], tais como: a sincronização, as restrições em tempo real, a persistência e a recuperação de falhas [Hürsch and Lopes 1995]. Embora seja possível identificá-los na fase conceptual, poucas linguagens de programação, permitem mantê-los separados na fase de implementação. Por exemplo, é pretendido que num programa, quando existir uma actualização de uma linha ou de um ponto, essa alteração seja reflectida imediatamente no ecrã invocando um método (figura 3). Aponta-se a existência de diversas alternativas que permitem este comportamento, nomeadamente, a introdução de código no local onde são feitas as alterações dos valores. Para cada classe é introduzido o código necessário nos métodos para actualizar o ecrã. Este código adicional secundário tem como objectivo implementar um concern que é global ao sistema. É intrusivo nas classes, para além de se repetir de igual forma por várias classes. 8 (Acedido em Junho 2008) 9 (Acedido em Junho 2008) 10 (Acedido em Junho 2008) 11 (Acedido em Junho 2008)

34 19 Figura 3 Espalhamento de Concerns. (Adaptada de [Kiczales, Hilsdale et al. 2001]) Programar vários concerns ao mesmo tempo e ao mesmo nível, implica que o programador tenha de saber necessariamente todos os detalhes das áreas a desenvolver. Não existe uma forma de tornar as áreas independentes e separar as tarefas. Neste âmbito, nos anos 90 surgiram várias tentativas de simplificar a crescente complexidade do software, essencialmente a adição de novas necessidades a um projecto existente [Lopes 2002]. Desta forma, a POA surgiu com o ideal de que um sistema de software é superiormente programado especificando separadamente concerns, propriedades ou áreas de interesse do sistema e a descrição dos relacionamentos entre eles [Elrad, Filman et al. 2001]. Todavia é com Gregor Kiczales liderando uma equipa no centro de pesquisa de Palo Alto (PARC, subsidiária da Xerox na Califórnia nos Estados Unidos da América) que se desenvolve o conceito de POA. Este grupo começou por efectuar pesquisas na área da reflexão [Smith 1982] e meta-object protocols [Kiczales, des Rivieres et al. 1991], desenvolvendo algumas ferramentas e

35 20 linguagens orientadas a aspectos tais como: AML, RG [Mendhekar, Kiczales et al. 1997] e DJ [Lopes 1997] que culminaram na linguagem AspectJ [Kiczales, Hilsdale et al. 2001; Kiczales, Hilsdale et al. 2001] que hoje em dia é considerada a linguagem padrão da POA. Porém, outra tecnologia foi apresentada em 1999 no Centro de Pesquisa de T.J. Watson da empresa IBM, Hypersapces [Ossher and Tarr 1999; Tarr, Ossher et al. 1999; Ossher and Tarr 2001] como uma evolução de subject-oriented programming [Harrison and Ossher 1993]. Na tabela 1, aponta-se as principais datas que marcaram o aparecimento de tecnologias sobre separação de concerns. Ano Evento 1972 Parnas, decomposição de sistemas em módulos Dijkstra, Separação de concerns. 1970s Programação Estruturada 1980s Programação Orientada a Objectos 1992 Adaptive Programming (Lieberherr, Northeastern University) Composition Filters (Aksit, Twente University) 1993 Subject-Oriented Programming (Harrison e Ossher, IBM) 1995 Artigo - Separation of Concerns (HÄurch e Lopes) 1996 Programação Orientada a Aspectos (Kiczales, Xerox PARC) 1997 Primeira Workshop sobre Programação Orientada a Aspectos (ECOOP 97) Artigo - Programação orientada a Aspectos (Kiczales etal.) Linguagem de Programação AspectJ Tese - D: A Language Framework for Distributed Programming (Lopes) 1999 Artigo - Multi-dimensional Separation of Concerns (Tarr, Harrison e Ossher, IBM) Linguagem de Programação Hyper/J 2000 Primeira Workshop sobre Advanced Separation of Concerns (OOPSLA ) Artigo Aspect-Oriented Programming is Quantification and Obliviousness (Filman e Friedman) 2001 Edição Especial da ACM sobre Programação orientada a Aspectos Primeira conferência Internacional sobre Desenvolvimento de Software Orientado a Aspectos (DSOA) Evolução nas várias subáreas da DSOA Tabela 1 Cronograma temporal da investigação sobre separação de concerns

36 META-PROGRAMMING Este paradigma tem como base a reflexão computacional [Smith 1985; Maes 1987] que permite que um sistema mantenha informação sobre si e use essa informação para alterar o seu comportamento [Maes 1987]. No paradigma meta-programing [Okamura and Ishikawa 1994 ], um sistema está dividido em dois níveis: base-level e meta-level (figura 4). Os construtores básicos da linguagem de programação, classes ou invocação de objectos, são descritos no base-level e podem ser estendidos ou redefinidos pela meta-programming. Cada objecto é associado com um meta-object através de um meta-link. O meta-object é responsável pela semântica das operações no objecto base. A interface entre o programa, base-level, e as camadas de nível superior é efectuada por meta-object protocols. Este último estabelece interfaces para a linguagem de programação que permitem ao programador modificar o comportamento da linguagem de programação e a implementação. Os objectos base-level são responsáveis pelos algoritmos básicos do programa e os seus comportamentos são melhorados e adaptados através de meta-level objects de acordo com requisitos específicos. Através da captura de mensagens enviadas e recebidas para os objectos, meta-level objects, estes conseguem efectuar o trabalho de concerns [Hürsch and Lopes 1995].

37 22 Figura 4 - Meta-programming. (Adaptada de [Okamura and Ishikawa 1994 ]) 2.9 SUBJECT-ORIENTED PROGRAMMING Subject-Oriented programming é uma extensão para a POO possibilitar a composição de diferentes visões subjectivas do mesmo objecto, facultando o desenvolvimento de aplicações separadamente, bem como, efectuar posteriormente a sua composição. Estes objectos contêm assim, propriedades e comportamentos específicos que ao longo do tempo e com a evolução necessitam de ser alterados. Estas propriedades e comportamentos são subjectivas ao tipo de objectivo a que se destinam, o mesmo objecto pode ter representações diferentes dependendo do tipo de objectivo com que é idealizado e da entidade que o idealiza (figura 5).

38 23 Deste modo, a Subject-oriented programimng pretende facilitar o desenvolvimento e evolução de aplicações que colaboram entre si. Esta colaboração é alcançada partilhando subjects (objectos) que contribuem para a execução de operações. O desenvolvimento das aplicações é efectuado em separado e sem dependência entre aplicações, permitindo estender sem modificar o original [Harrison and Ossher 1993]. A composição combina hierarquias de classes a fim de produzir novos subjects que incorporam funcionalidades de subjects existentes. A Subject-Oriented programming oferece ferramentas de composição a fim de integrar os sujeitos [Kaplan, Ossher et al. 1996]. Esta tecnologia evoluiu para se tornar a Separação Multidimensional de Concerns (secção 2.13). Figura 5 - Subject-oriented programming. (adaptada de [Harrison and Ossher 1993])

39 PROGRAMAÇÃO ADAPTATIVA A Programação Adaptativa [Lieberherr 1996; Lopes 1997] é um modelo de programação com base em padrões de código, onde estes podem ser classificados em diferentes categorias, cada um capturando um tipo diferente de concern. Posteriormente os padrões de código são implementados como componentes de software de alto nível que interagem com os outros componentes de forma muito solta através da resolução de nomes [Lopes 2002]. Perante problemas como a elaboração de uma nova operação ou regra de negócio num sistema, é necessário colocar todo o código num só método, numa só classe, ou adopta-se a divisão do código da operação por várias classes. Porém o problema deste último método relaciona-se com a dependência na estrutura das classes, o que vai adicionar complexidade nos métodos e dificultar a evolução. A Programação Adaptativa resolve esta questão utilizando padrões de propagação, abstraindo o comportamento do concern num local e a estrutura das classes noutro. O comportamento é expresso a um alto nível utilizando uma estratégia transversal [Lieberherr, Orleans et al. 2001]. Nesta continuidade, a Programação Adaptativa pode ser definida em dois blocos: um bloco de estrutura implementado por um grafo do dicionário de classes, que contém a relação entre classes e um segundo bloco comportamental, implementado por um padrão de propagação que é depois composto com o grafo e que assim possibilita a interacção de forma flexível entre ambos.

40 FILTROS DE COMPOSIÇÃO Filtros de composição são uma extensão à POO através da adição de filtros ortogonais e modulares que permitem aumentar a adaptabilidade e a reutilização dos objectos [Aksit, Wakita et al. 1993; Bergmans and Aksit 2001]. Assim, são elaborados filtros que filtram as mensagens enviadas e recebidas pelos objectos e efectuam acções através da definição de condições para a aceitação ou rejeição de uma mensagem. Esta tecnologia consiste principalmente no interface e na implementação. Na parte de interface faz-se o tratamento das mensagens de chegada e de saída, composto de um ou mais filtros de entrada e saída, e opcionalmente, de objectos internos e externos e de declarações de métodos (figura 6). Os filtros são controlados por condições, nomes de filtros, nome das declarações de métodos e nomes das condições que são visíveis para os objectos clientes apesar da sua implementação ser invisível. Na parte de implementação estão as definições de métodos, instâncias de variáveis, definições de condições e opcionalmente operações de inicialização. Esta parte é totalmente encapsulada no objecto, possibilitando através deste, a alteração de mensagens e o seu redireccionamento para objectos internos ou externos. Assim pode ser alcançada a separação de concerns definindo um filtro por cada concern.

41 26 Figura 6 - Filtros de composição. (adaptada de [Aksit, Wakita et al. 1993]) 2.12 PROGRAMAÇÃO ORIENTADA A ASPECTOS. A origem do termo POA é resumida por Cristina Lopes, Não me consigo lembrar da data exacta quando decidimos chamar ao nosso trabalho Programação Orientada a Aspectos, mas lembro-me que o termo foi sugerido por Chris Maeda [ ]. No meu portátil a primeira referência a POA ocorre nos fins de Novembro de Em Janeiro de 1996, o meu portátil indica que estávamos a usar Open Implementation e POA ao mesmo tempo, embora para partes diferentes do trabalho do grupo. Em Junho de 1996 enviámos a proposta para o DARPA intitulada Programação Orientada a Aspectos, no fim de 1996 desaparecem todas as referências a Open Implementation do meu portátil. [Lopes 2002].

42 27 Gregor Kiczales como já referido, liderava uma equipa de investigação em Open implementaions [Kiczales 1996] e Metaobject Protocol [Kiczales, des Rivieres et al. 1991], à qual no verão de 1995 se junta Cristina Lopes, acrescentando conhecimentos de programação adaptativa [Lopes 1996]. Em 1997, Gregor Kiczales apresenta o seu trabalho em Programação Orientada a Aspectos na conferência ECOOP 97, expondo os primeiros termos, conceitos e análise dos problemas que se tentavam solucionar [Kiczales, Lamping et al. 1997]. Gregor Kiczales afirma que [ ] O objectivo deste trabalho é tornar possível que os programas consigam claramente capturar todos os aspectos importantes do comportamento do sistema [ ] [Kiczales, Lamping et al. 1997]. As linguagens de programação com base num só tipo de abstracção são inadequadas para sistemas complexos. Diferentes tipos de comportamentos do sistema tendem a ter a sua própria forma, enquanto um tipo de abstracção pode ser bom para capturar um tipo de comportamento do sistema, é insuficiente num outro tipo de comportamento [Kiczales, Lamping et al. 1997]. As Linguagens de POO conseguem capturar os comportamentos dos objectos mas falham em comportamentos secundários, comportamentos estruturais e comportamentos invariantes. Estes comportamentos não são possíveis de isolar num só local e dispersam-se pelos módulos do sistema, ou seja, são transversais aos módulos. Nesta mistura de comportamentos o resultado é código espalhado que leva à perda de modularidade e a uma possível perda de abstracção. Para combater estas fragilidades a POA apresenta uma nova forma de modularização que permite a implementação de cada aspecto do sistema separadamente na sua forma natural, e a sua composição usando uma ferramenta Aspect Weaver. As componentes funcionais continuam a ser implementadas nos paradigmas existentes enquanto as componentes não funcionais são

43 28 implementadas numa linguagem de aspectos. Criando-se uma solução de abrangência geral e independente do tipo de comportamento do sistema, funcionando como uma extensão. Assim, a POA define Crosscutting concern como um comportamento do sistema que atravessa vários módulos deste. Este é dividido em concerns base, comportamentos primários e crosscutting concern, comportamentos secundários e é adicionada uma nova unidade modular, o aspecto. A implementação de concerns é feita independentemente e a coordenação e comunicação entre eles é relegada para os aspectos. O programador, detentor da compreensão do sistema, fica responsável por explicitamente definir os aspectos, utilizando uma linguagem que deva permitir um nível abstracto adequado e com a localidade apropriada [Kiczales, Lamping et al. 1997] AspectJ Uma implementação do paradigma é o AspectJ 12 [Kiczales, Hilsdale et al. 2001; Kiczales, Hilsdale et al. 2001] que funciona com uma extensão à linguagem POO Java 13, adicionando-lhe conceitos práticos de POA e permitindo a implementação modular de crosscutting concerns. Acrescentando um novo conceito, o join point e alguns construtores: pointcuts, advice, inter-type declarations e aspects. AspectJ foi desenvolvido com a compatibilidade com a linguagem Java em mente, isto é, os programas em Java têm de ser válidos em AspectJ e os programas AspectJ deverão ser válidos na Java virtual machine (JVM) padrão [Lindholm and Yellin 1999]. As ferramentas de suporte 12 (Acedido, Julho 2008) 13 (Acedido, Julho 2008)

44 29 do Java foram alteradas para suportar a linguagem, tais como os Ambientes Integrados de Desenvolvimento (IDEs), bem como, as ferramentas de documentação. Assim, os programadores podem utilizar a extensão AspectJ de forma tão natural como o Java. Como já referido, o AspectJ adiciona: pointcuts e advices que permitem afectar dinamicamente o fluxo normal do programa, inter-type declarations que alteram estaticamente a hierarquia de classes do programa e aspectos que encapsulam todos os novos construtores. Outra adição a enumerar é o conceito de Join Point que define um ponto no fluxo do programa. Estes são utilizados por pointcuts para expor os locais de intercepção onde é necessária a adição de comportamentos transversais. Por sua vez, advice é o bloco de código que vai ser executado quando o join point for alcançado. Na sua conjuntura existem dois tipos de comportamentos possíveis: os comportamentos dinâmicos que avaliam condições definidas nos pointcuts em tempo de execução e os comportamentos estáticos onde as avaliações são feitas em tempo de compilação. Todavia acrescenta-se que os aspectos são as unidades modulares para a declaração dos crosscutting concerns, são similares às classes do Java mas incluem os construtores pointcut, advice e inter-type declaration. Nos próximos subcapítulos expõe-se uma breve introdução da linguagem, tendo como base a guia de programação (Acedido, Julho 2008)

45 Join Point Join Point é um ponto bem definido no fluxo do programa. Este modelo permite capturar: Chamadas a métodos; Execução de métodos; Criação de objectos; Execução do construtor do objecto; Inicialização de objectos; Pré inicialização de objectos; Referências e atribuição a variáveis; Tratamento de excepções PointCuts Tendo por base que os pointcuts permitem seleccionar e agrupar join points, e utilizando a figura 7 como exemplo de referência, pretende-se seleccionar todas as chamadas ao método setx com argumento int e retorno void da classe Point. Figura 7 Diagrama do exemplo.

46 31 Para se criar um Pointcut, utiliza-se o operador pointcut e declara-se o seu nome, a sua interface e o join point a capturar. No exemplo 1, expõe-se a utilização da primitiva call (identifica um join point do tipo chamada a método) para a captura de chamadas ao método setx da classe Point. pointcut move(): call(void Point.setX(int)) Exemplo 1 declaração de um pointcut. De modo a agregar vários join points num só pointcut, aplicam-se os operadores lógicos ou definido na linguagem com os símbolos, o operador e definido na linguagem com os símbolos && e o operador de negação definido na linguagem com o símbolo!. Para facilitar a atribuição de join points é possível definir o nome do fluxo (método, variável, excepção, etc.) a capturar, utilizando wildcards para os expressar. Denominando este tipo de pointcut, de Property-Based Primitive PointCut, este permite que numa só declaração se agrupem um conjunto de join points, pois estes seguem uma determinada sintaxe no seu nome. No exemplo 2 captura-se todos os métodos da classe Figure cujo nome comece por make com qualquer tipo de parâmetros mas só os métodos declarados com retorno void. call(void Figure.make*(..)) Exemplo 2 - Pointcut utilizando WildCards Advice Pointcuts seleccionam join points mas não exercem qualquer acção. Porém com o auxílio dos advices possibilita-se implementar o comportamento transversal associando assim, um pointcut a um bloco de código.

47 32 O bloco de código de um advice que está associado a um ou mais pointcuts pode ser executado em três momentos diferentes: antes (exemplo 3), depois (exemplo 4) ou ao invés de (exemplo 5). before():pointcut{ Bloco de Código Exemplo 3 Advice do tipo antes. after():pointcut{ Bloco de Código Exemplo 4 - Advice do tipo depois. around():pointcut{ Bloco de Código Exemplo 5 - Advice do tipo ao invés de Inter-type declarations Inter-Type declarations permitem adicionar comportamentos a classes e alterar as suas hierarquias, declarar membros de classes que se propagam por múltiplas classes ou alterar a relação de herança entre classes. Por exemplo, permite adicionar a uma classe atributos, métodos, ou implementar um padrão de desenho. No exemplo 6 é mostrado como adicionar métodos e variáveis necessárias à implementação do padrão de desenho Observer que posteriormente são compostos pelo Weaver com a classe Point. aspect PointObserving { private Vector Point.observers = new Vector(); public static void addobserver(point p, Screen s) { p.observers.add(s); public static void removeobserver(point p, Screen s) { p.observers.remove(s);... Exemplo 6 Implementação do padrão de desenho Observer.

48 Aspectos Como já mencionado, os aspectos encapsulam os pointcuts, advices e inter-type declarations, para além de poderem conter métodos e atributos. São as unidades modulares onde todo o comportamento relativo a um ou mais comportamentos transversais é implementado e fica localizado (exemplo 7). aspect OmeuAspecto{ //Dentro deste bloco é possível declarar //Métodos e declaração de atributos iguais ao java //pointcuts e advices e inter-type declarations referentes ao AspectJ Exemplo 7 declaração de aspectos SEPARAÇÃO MULTIDIMENSIONAL DE CONCERNS Separação multidimensional de concerns é um paradigma para modelar e implementar software artifacts, suportando a separação simultânea de concerns através da decomposição e composição de software artifacts ao longo de múltiplas dimensões, quebrando a tirania da decomposição dominante, sendo uma evolução da subject oriented programming [Tarr, Ossher et al. 1999]. Durante o desenho de um sistema são identificados requisitos e funcionalidades que na fase de implementação só são possíveis de decompor de uma forma: por objectos. Funcionalidades que afectem vários objectos vão espalhar-se por diversos outros implicando a evolução e compreensão do sistema. Futuras alterações são intrusivas no sistema ao invés de aditivas. Para alcançar a decomposição por concerns este paradigma utiliza Hyperslices.

49 34 Relativamente ao hyperslice, tido como um conjunto de módulos convencionais escritos num qualquer formalismo, têm a finalidade de encapsular concerns numa dimensão fora da dimensão dominante. Os módulos desta dimensão contêm todas as unidades que pertencem ou tratam do concern em causa. Sendo bem elaborada a separação de concerns, pode fornecer a muitos engenheiros de software diversos benefícios, entre eles: a complexidade reduzida, a reutilização e a evolução. A escolha dos limites da separação dos concerns depende dos requisitos do sistema e dos tipos de decomposição e composição que um dado formalismo suporta. As metodologias predominantes e formalismos disponíveis só suportam separação de concerns ortogonal, ao longo de uma única dimensão de decomposição e composição [Ossher and Tarr 2000]. Esta tecnologia evolucionou para Concern Manipulation Evironment (CME) [Harrison, Ossher et al. 2005; Harrison, Ossher et al. 2005] suportando a extracção e composição de concerns durante o ciclo de vida de um sistema de software, disponibilizando um conjunto de ferramentas para programadores. CME é assim, um projecto Eclipse 15 Open Source, que já não está em desenvolvimento e encontra-se arquivado DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS Para além de modularizar crosscutting concerns é necessário primeiramente, identificálos numa fase anterior à implementação. A POA tornou-se assim parte de uma área maior, o 15 (Acedido, Julho 2008) 16 (Acedido, Junho 2008)

50 35 Desenvolvimento de Software Orientado a Aspectos (DSOA), existindo duas grandes áreas nela inserida, a Early-Aspects 17 [Rashid, Sawyer et al. 2002] e a POA. A investigação na área Early-Aspects tem como objectivo identificar aspectos crosscutting numa fase inicial da elaboração do sistema, e determinar o impacto dos aspectos identificados em fases posteriores. A Early-Aspects foca-se na engenharia de requisitos. Para atingir um consenso nesta área é introduzido um modelo para a engenharia de requisitos, primeiro são identificados e especificados os concerns seguindo-se, a partir destes, a identificação dos potenciais aspectos que são especificados e atribuídos de uma prioridade. Finalmente é definida a dimensão em que se enquadram os aspectos. Os concerns que influenciem ou interajam com mais de um requisito são chamados aspectos candidatos, prosseguindo-se uma detalhada especificação dos aspectos candidatos, o que permite uma refinação de aspectos mais sucinta e que tipo de interacções e conflitos, entre aspectos existe. Para resolver conflitos entre aspectos é preciso atribuir-lhes prioridades COMUNIDADES E SITUAÇÃO EM PORTUGAL Existe uma associação de DSOA, a nível Mundial 18 e Europeu 19, que organiza todos os anos uma conferência Internacional 20 com Workshops 21 sobre esta temática. Em Portugal existe 17 (Acedido, Julho 2008) 18 (Acedido, Julho 2008) 19 (Acedido, Julho 2008) 20 (Acedido, Julho 2008) &CFTOKEN= (Acedido, Julho 2008)

51 36 um grupo de pesquisa na área de early-aspects 22, sediada na Universidade Nova de Lisboa sob a liderança da Professora Doutora Ana Moreira DESAFIOS, PROBLEMAS E OPORTUNIDADES A POA teve uma fase de evolução e amadurecimento desde que foi apresentada em 1997 até 2002, ano em que foi incorporada como uma subárea da DSOA. O desenvolvimento da investigação académica está na sua maioria focado na subárea early-aspects, desenvolvendo-se ferramentas para a identificação de aspectos na fase de desenho e como estes se deverão relacionar com o resto do sistema. Deste modo, estão a ser elaboradas ferramentas, que permitem a criação visual de aspectos de uma forma similar com o que é feito com UML para a POO. Na fase de implementação estão a ser elaboradas ferramentas que permitem visualizar a interacção dos aspectos com o resto do sistema e efectuar a depuração do código, aproveitando também o novo conceito de modularização através de bytcode weaving para criar sistemas mais modulares, onde existe adição ou remoção, em tempo de execução, de funcionalidades e requisitos consoante as necessidades. Alguns paradigmas apresentados posteriormente evoluíram e agora fazem parte integrante da POA, tais como o Adpatative programing [Lieberherr, Orleans et al. 2001]. Como tecnologia emergente, a POA tem a potencialidade de facilitar e diminuir o tempo de desenvolvimento de um sistema de software. Para o sucesso da tecnologia é necessário uma 22 (Acedido, Julho 2008)

52 37 maior adaptação ao nível comercial. Para tal, é essencial uma melhor integração com as tecnologias existentes, para que assim exista uma transição natural sentida como uma evolução. Esta evolução não pode ser só das linguagens de programação existentes, tem de envolver todas as ferramentas que são utilizadas com essa linguagem, entre outros, editores, documentação e depuradores. A constante transformação do mundo actual determina que o que é uma necessidade hoje, pode ser substituída por uma outra necessidade completamente diferente amanhã. O que influencia as empresas a estar em constante evolução e alterarem as suas regras de negócio. Toda esta conjuntura de factos em constante mudança, evidência a necessidade de uma nova forma de se conseguir desenvolver software que permita em tempo útil, acompanhar estas mudanças. A POA possibilita este facto através da adição de funcionalidades e regras de negócio, que não são intrusivas à evolução e/ou modificação dos sistemas. Devido à nova forma de modularidade é fundamental a existência de alguma coordenação das alterações que se possam efectuar no sistema, para que o seu comportamento seja previsível, ou seja, as alterações não devem conduzir a aspectos que deixam de interceptar pontos no fluxo ou estes fluxos deixem de ser o ponto de intercepção pretendido, tornando o comportamento do sistema imprevisível.

53 38

54 39 3. PROGRAMAÇÃO ORIENTADA A ASPECTOS Nos pontos que se seguem tentar-se-á abordar os problemas inerentes à POA, bem como, as suas primordiais vantagens e desvantagem que influenciaram a busca de soluções por parte da POA. Assim, incidir-se-á numa primeira análise do que se entende por um sistema POA, seguindo-se a exposição das tecnologias existentes, aplicações e estudos quantitativos inerentes a esta área de investigação. 3.1 COMPORTAMENTOS GLOBAIS A motivação do paradigma da Programação Orientado a Aspectos, é ajudar a modularizar múltiplos aspectos de um sistema de software, aplicando-lhe o princípio da separação de concerns. O sistema é composto por módulos independentes, raciocinando modularmente e sem as dificuldades e complexidades apresentadas por outras tecnologias de separação de concerns semelhantes. A partir da figura 8 mostra-se dois módulos da mesma aplicação, cada um dos módulos implementa uma determinada funcionalidade necessária pela aplicação, contudo existe ainda uma dependência explícita de entre os dois módulos. O módulo A necessita de conter referências ao módulo B, nas várias unidades que o compõem, deste modo os dois módulos não são totalmente independentes.

55 40 Figura 8 - Interacção entre Módulos. Na figura 9 pode verificar-se a existência de uma sobreposição de uma unidade elementar B1 pertencente ao módulo B a três unidades do módulo A. Esta dependência é em certo modo, criada pela forma como se estruturou o programa e por condicionantes introduzidas pelo paradigma que se está a utilizar na implementação, por exemplo, a hierarquia de classes no paradigma orientado a objectos. Esta dependência entre módulos vai condicionar a sua independência e reutilização para futuros projectos. Figura 9 - Sobreposição de unidades elementares. Existem comportamentos num sistema de software que se repetem sistematicamente em vários módulos do sistema, não sendo possíveis de se situarem num só local pois são uma

56 41 necessidade global do sistema, criada pela necessidade do sistema em ter um certo comportamento específico (figura 10). Figura 10 - Comportamentos Globais do Sistema 3.2 ANÁLISE DO PROBLEMA O primeiro problema que se pode identificar diz respeito ao desenho da arquitectura de um sistema de software. O engenheiro de software, quando lhe é atribuída a tarefa de criar um novo sistema de software, depara-se com uma série de dilemas que afectam a criação do sistema, nomeadamente o tempo de que se dispõe para criar o sistema e a evolução dos requisitos do sistema. Não existem certezas de que os requisitos não vão sendo alterados durante o desenvolvimento do sistema ou sua posteriori.

57 42 Dependendo dos factores anteriores criam-se sistemas que são mais rápidos de produzir, ou seja, têm um tempo reduzido para sair para o mercado, mas são difíceis de evoluir posteriormente e nem sempre apresentam garantias de qualidade. Por outro lado uma arquitectura do sistema mais cuidada permite uma melhor evolução do sistema, com maior qualidade, mas implicando maior tempo de desenvolvimento e gastos adicionais. Definir um meio-termo não é fácil, mas focando-se apenas nos requisitos presentes e desenvolvendo um sistema com base em tecnologias que permitam a acomodação modular de novos requisitos, ou as suas alterações, obtém-se assim uma solução que permitirá a elaboração de um sistema de melhor qualidade, em menos tempo e com menor custos. A tarefa de gerir projectos é contudo um factor crítico, devido à falta de modularidade implicando deste modo mais comunicação entre equipas, reuniões e debates o que encurta o tempo de desenvolvimento. Não obstante, outro problema inerente é o facto de que a tecnologia utilizada para a implementação produz um impacto negativo na modularização, ou seja, muitas vezes aquando do desenho do sistema para a fase de implementação perde-se modularidade. A tecnologia usada na implementação não permite implementar modularmente todas as preocupações desenhadas e identificadas e algumas acabam por se sobrepor a outras (exemplo 8).

58 43 public class SomeBusinessClass extends OtherBusinessClass { "Dados do módulo" "Stream de Registo" "Flag de consistência de dados" "Métodos redefinidos da super classe" (1) public void performsomeoperation(<informação da Operação>) { "Garantir autenticidade" "Garantir que a informação satisfaça contrato" "Bloquear o objecto para garantir consistência" "Garantir que a cache está actualizada" (2) "Fazer o registo do início da operação" "Realizar Operação" "Fazer o registo do final da operação" "Desbloquear o objecto" (3) public void save(<persistência de dados>) { "..." public void load(<persistência de dados>) (4) { "..." Exemplo 8 Intrusão em Classes.

59 44 No exemplo 8 as secções 1, 2, 3 e 4 não fazem parte da lógica primária da classe, são preocupações referentes a funcionalidades globais do sistema existindo uma invasão de código na classe, de funcionalidades que não contribuem para a implementação do seu objectivo primário. Este problema de modularização resulta dos comportamentos que são transversais aos objectos, são globais ao sistema e produzem espalhamento (scaterring) e intrusão (tangling) de código [Kiczales, Lamping et al. 1997]. Sendo o espalhamento um efeito causado por um comportamento transversal, que adiciona código extra em vários módulos do sistema de software, para implementar um determinado comportamento. E intrusão o efeito de ter vários comportamentos transversais na mesma secção de código, por exemplo num método, o que gera o denominado código esparguete. A falta de modularização no código produz efeitos negativos no desenvolvimento e evolução dos sistemas de software, tais como [Laddad 2003]: Baixa produtividade: o desenvolvimento de um módulo deixa de ser exclusivamente incidente numa só área específica para se alargar a outras. O programador tem de possuir conhecimento de todas essas áreas, aumentando assim o tempo que demora a desenvolvê-las. As revisões feitas no módulo têm de ser efectuadas com todos os especialistas das áreas abrangidas e quanto maior o grupo de pessoas, mais difícil se torna estabelecer um horário que permita a sua reunião; Baixa qualidade: o aumento do código necessário para implementar os módulos, devido ao aumento das áreas de foco de cada programador, aumenta a probabilidade da existência de erros e de secções elaboradas com menor rigor;

60 45 Baixa reutilização: as alterações feitas nos módulos, para introduzir os comportamentos transversais, são invasivas para a reutilização do módulo noutro projecto. Ter-se-á assim, de remover todos esses comportamentos adicionais das classes; Baixa evolução: a adição ou alteração de comportamentos poderá levar à reorganização ou modificação de vários módulos; Difícil compreensão: a leitura e compreensão de um módulo implica possuir um conhecimento global de todas as áreas que este implementa, ou seja, o sistema tem de ser compreendido na sua globalidade; Problemas de depuração: a depuração tem de ter em conta todas as áreas que o módulo implementa. Neste contexto, um exemplo de intrusão são os padrões de desenho. Embora estes melhorem a modularidade dos sistemas, algumas classes necessitam de ser modificadas para acomodarem as alterações. Com a POA os padrões de desenho são desenvolvidos separadamente e as alterações necessárias, nas classes, são implementados em aspectos, sendo posteriormente compostos com as classes (secção 3.15).

61 SISTEMA MODULAR A POA visa permitir modularizar, na sua forma natural, software concerns que não são adequadamente decompostos pelos paradigmas mais comuns, em especial o paradigma orientado a objectos. Como já exposto, um concern é uma funcionalidade ou requisito do sistema de software, e pode variar desde noções de alto nível como segurança e qualidade de serviço, até noções de baixo nível como caching e buffering. Os concerns podem ser funcionais ou não funcionais [Elrad, Filman et al. 2001]. Um módulo pode ser definido de várias formas, embora seja geralmente um componente de um sistema de software que opera independentemente de outros módulos. Assim, a modularização de todos os concerns de um sistema de software permite uma nova forma de raciocínio, de análise e implementação do sistema por módulos. Contudo o código de um concern torna-se modular se for possível [Kiczales and Mezini 2005]: Ser localizado textualmente; Existir uma interface de interacção bem definida com o resto do sistema; A interface ser uma abstracção da implementação, sendo possível alterar a implementação sem violar a interface; O módulo ser automaticamente composto, por um compilador (Weaver), loader, linker, em várias configurações, com outros módulos para produzir um sistema. Raciocinar modularmente permite tomar decisões em relação aos módulos focando-se apenas e só na sua implementação. É necessário analisar previamente o sistema na sua

62 47 globalidade e a POA assim o exige de maneira a permitir, depois de completa a análise global, o raciocínio modular. Desta forma, a POA permite estruturar o desenho e o código do sistema de acordo com o que os programadores pensam do sistema, possibilitando assim a decomposição e composição de software concerns, em especial a modularização de crosscutting concerns [Elrad, Aksit et al. 2001]. Crosscutting concerns são aspectos de um sistema de software que afectam outros concerns, ou seja, são concerns que são transversais a outros concerns [Kiczales and Mezini 2005]. A POA permite a implementação modular de crosscutting concerns, junto com os benefícios prévios da POO, funcionando como uma extensão do paradigma POO. A base do sistema de software contínua a ser implementada usando POO. Crosscutting concerns são igualmente implementados separadamente e encapsulados em unidades modulares chamadas aspectos. Com a ajuda de ferramentas os módulos crosscutting são combinados (Weaving) com os outros módulos base do sistema para gerar o programa final. 3.4 SISTEMA POA Para alguns autores, a POA pode ser entendida como o desejo de se fazer declarações quantificadas sobre o comportamento de programas, e conseguir com que essa quantificação estruture programas escritos por programadores alheios a essa quantificação [Filman and Friedman 2000].

63 48 Segundo a opinião dos autores Filman and Friedman existem duas propriedades necessárias para uma linguagem de programação ser considerada POA a quantificação e a alheabilidade [Filman and Friedman 2000]. A quantificação é uma atribuição na forma no programa P, quando se disputar qualquer condição C, efectua-se a acção A em P. Definindo as seguintes preocupações para o programador e/ou engenheiro de software: Quantificação: que tipo de condições C se podem especificar? Interface: como é que as acções A interagem com o programa base e entre eles? Entrelaçamento: como irá o sistema interligar a execução das acções base do programa P com as acções A? A quantificação pode ser estática, quantificação sobre programas na forma de texto, ou dinâmica que associa aspectos a eventos que acontecem durante a execução do programa. Quanto à alheabilidade, esta estipula que ao examinar o bloco de código de um módulo base, não se deve conseguir afirmar se o código de um aspecto irá ser executado. Não deve existir acomodação do módulo base. Em suma, um sistema POA será um sistema que permite quantificar acções e através de uma interface interagir com o programa base. A combinação das várias componentes é feita através da forma de texto ou de eventos, sendo o sistema base alheio a todo este processo.

64 METODOLOGIA DSOA O desenvolvimento de um software orientado a aspectos é geralmente feito em três etapas: 1. Decomposição aspectual: são identificados os requisitos do sistema, apontando os requisitos funcionais, denominados base concerns, e requisitos não funcionais, os crosscutting concerns; 2. Implementação de concerns: procede-se à implementação independente dos vários concerns. A implementação de cada concern é feita separadamente recorrendo a um paradigma de programação, sendo o paradigma mais utilizado a POO; 3. Recomposição aspectual: definem-se as regras de composição dos vários módulos do sistema previamente implementados. Estas regras são implementadas em unidades modulares chamadas aspectos. O processo de composição Weaver utiliza-as em conjunto com os módulos para produzir o sistema final. Estas regras são definidas numa linguagem de programação que implementa o paradigma orientado a aspectos. A partir da figura 11 é possível visualizar a interacção das várias etapas.

65 50 Figura 11 - Metodologia POA. (Adaptada de [Laddad 2003]) 3.6 ANATOMIA DA LINGUAGEM POA O Paradigma Orientado a Aspectos permite especificar, separadamente, como um módulo deve reagir a um evento que ocorre em outro módulo. Esta ideia permite a separação dos módulos já que estes não interagem directamente. Uma linguagem que implemente o paradigma tem de possuir: Uma especificação que descreva os construtores e a sintaxe que irá ser utilizada para combinar os crosscutting concerns com a lógica dos base concerns; Verificação da aderência do código à especificação da linguagem e gerar o programa, o que é geralmente feito por um compilador ou interpretador.

66 ESPECIFICAÇÃO DAS LINGUAGENS Uma implementação do Paradigma Orientado a Aspectos tem de possuir uma linguagem que permita a implementação dos software concerns e uma linguagem que permita definir regras de combinação dos vários softwares concerns Software concerns Para a implementação de software concerns em módulos são normalmente utilizadas linguagens orientadas a objectos tais como: Java, C++ e C# Regras de combinação As regras de combinação definem como interligar os software concerns previamente implementados, de forma a criar o sistema final. Alguns aspectos da combinação de concerns a levar em conta na especificação da linguagem são: Correspondência da linguagem: modo com o qual se descreve quais entidades serão compostas entre si. A correspondência pode ser implícita (determinada por regras da linguagem) ou explícita (descrita pelo programador); Semântica composicional: descreve o que deve acontecer com os elementos que correspondem. A linguagem pode definir diversas semânticas que em geral são escolhidas pelo programador;

67 52 Tempo de ligação: diz respeito ao momento em que a correspondência tem início. Pode ser estático (em tempo de compilação) ou dinâmico (em tempo de execução). 3.8 COMPOSIÇÃO DE SISTEMAS A implementação da linguagem permite combinar os software concerns, utilizando as regras de combinação e converter o resultado da combinação em código executável. O processo de combinação é chamado weaving e o executante, compilador deste processo, é denominado Weaver Weaving É o processo de composição do sistema de software concerns com aspectos. As regras de composição estão definidas nas unidades modulares, aspectos. Esta separação faculta que as alterações das regras permitam gerar novas formas de combinação e assim novos sistemas de software sem alteração dos software concerns. As regras lógicas possibilitam à linguagem a geração de eventos virtuais e responder com uma acção. Esta acção é associada a um crosscutting concern.

68 Weaver Weaver é o processo que efectua a combinação dos concerns. Dependendo da implementação do Weaver este pode permitir a combinação de código fonte, a combinação de código intermédio [Hilsdale and Hugunin 2004] (bytecode 23 ), ou estar incluído na própria maquina virtual. Por exemplo, a JVM 24 ao executar os programas em código intermédio, permite despontar eventos próprios para a introdução de comportamentos adicionais. Na combinação do código fonte (figura 12), o dos módulos é entrosado pelo Weaver com o dos aspectos, na linguagem de POA. O resultado é posteriormente fornecido ao compilador da linguagem de programação base. Neste método não é possível combinar bibliotecas que estejam pré-compiladas, já que não é possível ter acesso ao seu código fonte. Figura 12 Weaver de código fonte. Na combinação de código intermédio (figura 13), todos os concerns são previamente précompilados pelo compilador do paradigma base, para código intermédio e os aspectos são pré- 23 (Acedido em Julho 2008) 24 (Acedido em Julho 2008)

69 54 processados pelo compilador de aspectos e combinados com o código intermédio dos software concerns, para gerar o código executável ou código intermédio final. Neste método já é possível importar bibliotecas pré-compiladas. Figura 13 - Weaver de código intermédio Proxy Dinâmica O processo de weaving em alguns Weavers é baseado em Proxies dinâmicos 25. Um Proxy dinâmico encapsula um objecto. Invocações em métodos desse objecto são efectuadas no proxy que posteriormente invoca os métodos no objecto. Isto permite que o proxy permita executar tarefas (advices), antes, depois ou ao invés de. Numa situação normal, a classe do objecto é alheia a qualquer alteração não sendo executada nesta classe qualquer tipo de alteração (exemplo 9). 25 (Acedido em Julho 2008)

70 55 public class SimplePojo implements Pojo { public void foo() { //invocação directa this.bar(); public void bar() { //logica Exemplo 9- classe a ser interceptada. Do ponto de vista do objecto a comunicação entre objectos é directa (figura 14). Figura 14 - Comunicação normal entre objectos. Normalmente para se invocar um método num objecto instancia-se o objecto e invoca-se o método directamente (exemplo 10). public class Main { public static void main(string[] args) { Pojo pojo = new SimplePojo(); // invocação directa na referencia do objecto pojo.foo(); Exemplo 10 Invocação de métodos na classe normalmente. Para adicionar um Proxy é necessário alterar o código que instancia o objecto e adicionar toda a lógica referente ao proxy. Estas alterações são efectuadas automaticamente pelas

71 56 ferramentas de compilação POA. No exemplo 11 é possível verificar o tipo de alterações necessárias para invocar um método num objecto. O código da classe ProxyFactory não é exemplificado. public class Main { public static void main(string[] args) { ProxyFactory factory = new ProxyFactory(new SimplePojo()); factory.addinterface(pojo.class); factory.addadvice(new RetryAdvice()); Pojo pojo = (Pojo) factory.getproxy(); // chamada ao método mas no proxy! pojo.foo(); Exemplo 11 - Invocação de métodos utilizando uma proxy. Ao ser inserido o padrão de desenho Proxy, o programa primeiro invoca o método no proxy e este posteriormente invoca o método no objecto (figura 15). Figura 15 - Comunicação utilizando uma proxy. Desta forma é possível adicionar comportamentos adicionais (figura 16).

72 57 Código da Invocação Pojo.foo() Proxy 1) Foo() na Proxy Advices Advice 2) Execução de Advices Objecto 3) Foo() no Objecto Figura 16 Adição de comportamentos adicionais através de proxys. Esta solução acrescenta lógica adicional. Assim, a execução do programa vai ter mais instruções o que vai afectar a performance do programa, para além de que só permite a captura de fluxo dinâmicos. 3.9 BENEFÍCIOS DA POA Como benefícios da utilização do Paradigma Orientado a Aspectos pode-se enumerar: Código mais limpo: a separação modular de todos os softwares concerns permite efectuar a análise e leitura do código escrito módulo a módulo. Assim, ao ser

73 58 necessário, só ter em consideração uma área de cada vez é mais fácil de se perceber, editar e estender o código escrito; Modularização superior: para além das formas normais de modularização da linguagem base é possível modularizar e localizar textualmente, segundo a forma natural os crosscutting concerns; Fácil de evoluir: a nova forma de modularização em conjunto com a definição de regras de composição permite criar novos sistemas, com o mínimo ou mesmo nenhumas alterações dos módulos de software. A adição de módulos ou redefinição de regras para alterar, editar, ou melhorar um sistema de software é simplificado e as alterações facilmente localizáveis; Facilidade de adicionar requisitos de última hora: a separação de software concerns permite a alteração de código fonte, com o mínimo de repercussões ao nível da estrutura do sistema de software. Modificações, como por exemplo, para melhorar a performance ou adicionar/alterar regras de negócio, são facilmente acopladas ao sistema; Mais código reutilizável: a eliminação do efeito de intrusão e espalhamento permite que os módulos sejam mais facilmente acoplados a outros sistemas de software; Rápido de implementar: depois da análise e da definição de interfaces é mais fácil dividir por equipas e implementar os módulos paralelamente, não sendo necessárias reuniões para alterações de necessidades locais;

74 59 Redução de custos: a possibilidade de desenvolver o sistema mais rapidamente, distribuir tarefas paralelas e aumentar a reutilização tem como efeito a redução dos custos DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS Um paradigma de programação por si só não é suficiente para a elaboração de um sistema, é preciso possuir ferramentas e tecnologias que facilitem o desenho e posteriormente o desenvolvimento do sistema. Assim, a POA evoluiu para o Desenvolvimento de Software Orientado a Aspectos 26 (figura17). Figura 17 - Sistema de Desenvolvimento de Software Orientado a Aspectos. 26 (Acedido em Junho 2008)

75 Identificação de concerns Nesta etapa é feita a identificação e separação de software concerns que permitirá a separação de tarefas e reduzir a complexidade do desenho e da implementação. Nesta área em particular surge o termo Early-aspects 27 que refere a identificação de aspectos ao nível da arquitectura do sistema (figura 18). A investigação nesta área prende-se com o facto de que é necessário fazer uma identificação realista dos interesses do sistema e como os aspectos vão afectar o sistema, bem como, a sua evolução futura. Figura 18 Incisão do estudo de Early-Aspects Implementação A subárea encarregue da implementação dos sistemas é a POA. Para tal, existe uma ampla panóplia de linguagens de programação que estende as linguagens mais populares como 27 (Acedido em Junho 2008)

76 61 Java, C/C++, SmallTalk. Tornando-se a linguagem padrão e uma das mais populares dentro da comunidade, o AspectJ estende da POO Java DEVENVOLVIMENTO UTILIZANDO ASPECTJ AspectJ [Kiczales and Hilsdale 2001] é uma extensão à linguagem de programação Java e implementa conceitos práticos do paradigma orientado a aspectos. Tem suporte para dois tipos de implementações de crosscutting concerns: Dinâmicos: permitem acrescentar comportamentos adicionais em pontos bem definidos no programa; Estáticos: permitem alterar a estrutura de classes e/ou interfaces. A linguagem foi desenvolvida pelo grupo de Gregor Kiczales e actualmente o desenvolvimento da linguagem está a cargo do projecto Eclipse, que disponibiliza no website da plataforma, ferramentas de ajuda ao desenvolvimento em POA. Benefícios da linguagem AspectJ: Generalista; Fácil de aprender; Fácil de associar; Adopção por fases.

77 Análise A análise à linguagem AspectJ, que descreve os vários tipos de PointCut, tipos de Advices, inter-type-declarations e exemplos de utilização, pode verificar-se no anexo 1. Na versão 1.5 da linguagem de programação AspectJ foi introduzido um novo estilo de declarar aspectos, advices e pointcuts, mas mantendo contudo a mesma semântica (anexo 1). A este estilo de desenvolvimento foi 28, sendo semelhante às anotações do Java 5 e idêntico à aplicação de atributos da Framework.NET. Este estilo permite desenvolver aspectos como se de classes normais de Java se tratassem, posteriormente anotadas, utilizando a semântica do AspectJ. Os métodos dessas classes quando anotados tornam-se Advices. Assim, torna-se possível desenvolver programas de POA sem alterar as ferramentas de desenvolvimento, contudo é necessário incorporar manualmente o método de Weaving no processo de compilação do projecto, através por exemplo, de tarefas ANT 29. Se não existir integração do processo de compilação o projecto/programa compilado tem o comportamento normal POO. 28 (Acedido em Junho de 2008) 29 (Acedido em Junho 2008)

78 63 Neste âmbito, antes de se poder desenvolver programas POA utilizando este estilo, é necessário instalar primeiro a linguagem AspectJ 30 e importar as bibliotecas, ficheiros jar, ao projecto Java. A análise a este estilo de programação POA encontra-se no anexo Ferramentas de Desenvolvimento Para facilitar e complementar a utilização das tecnologias POA surgiram e/ou foram adaptadas ferramentas que auxiliam os programadores. Estas encontram-se enumeradas no anexo POSTSHARP PostSharp é uma tecnologia POA para a Framework.NET da Microsoft. AspectJ é só utilizável em projectos Java, não existindo soluções para outras populares linguagens e tecnologias. É ao encontro desta necessidade para a Framework.NET que o PostSharp foi criado. Postsharp 31 é uma plataforma de código aberto, que permite transformar e analisar assemblies da tecnologia.net da Microsoft. Uma assembly é um conjunto de módulos, 30 (Acedido em Junho 2008) 31 (Acedido, Julho 2008)

79 64 unidades unitárias, e com um cabeçalho que indica os módulos que compõem a assembly. Cada módulo é armazenado no formato portable executable (PE), código intermédio, MSIL. Postsharp Laos (Lightweight Aspect-Oriented System), é por sua vez, um weaver que permite criar atributos para a framework.net como se de aspectos se tratassem, sendo aplicados a classes, métodos ou variáveis. Os atributos são metadados que descrevem, ou anotam, elementos específicos tais como classes, métodos ou propriedades. Os metadados são adicionados à assembly e podem ser acedidos através da API Reflection da framework.net A tecnologia consiste, deste modo, num conjunto de assemblies que se registam na Framework.NET e um post-compiler para compor o sistema, o qual se integra no processo de compilação do Visual Studio, MSBuild. Postsharp Laos é um plug-in (figura 19) de uma plataforma maior: o Postsharp Core. Esta plataforma é uma infra-estrutura genérica, para a análise e transformação de programas, como AOP weavers, análise estática e optimizadores, podendo ser utilizada por investigadores e/ou programadores para se abstraírem dos problemas da infra-estrutura e se focarem na sua área de investigação. Figura 19 Processo de integração do Postsharp. (Adaptada do ficheiro de ajuda do Postsharp)

80 PostSharp LAOS O plug-in Postharp LAOS [Fraiteur 2008] permite de forma simples implementar funcionalidades práticas do Paradigma Orientado a Aspectos num projecto. NET Framework. A nomenclatura utilizada no Postsharp Laos foi adaptada para ser facilmente interpretada pela comunidade da Framework. NET, facilitando a sua utilização aos programadores menos familiarizados com os conceitos da POA. Na tabela 4 apresenta-se uma comparação entre os termos técnicos utilizados na linguagem de programação AspectJ e os utilizados no PostSharp Laos. AspectJ Join Point Pointcut PostSharp Laos Meta-evento Atribuição de um atributo a um tipo (classe, método ou propriedade). Meta-Handler Conjunto coerente de advices aplicados a um evento de um elemento alvo predefinido, geralmente encapsulados num atributo. Tabela 2 - comparação da nomenclatura do AspectJ e Postsharp Laos. Advice Aspecto Neste contexto, o PostSharp Laos disponibiliza classes que são consideradas aspectos e os métodos destas podem ser vistos como advices. O programador estende as classes e redefine os métodos de acordo com o comportamento pretendido. Como estas classes derivam da classe System.Atribute todas as classes que derivem destas são atributos, e ao serem aplicadas a um tipo, classe, método ou propriedade, definem um Pointcut. Do ponto de vista do programador do módulo base um aspecto não é mais que um atributo.net.

81 66 É disponibilizado pela Plug-in um Namespace 32, Postsharp.Laos, que contem um conjunto de classes que permitem implementar os atributos de acordo com o tipo de comportamento pretendido. Sendo assim, é possível capturar chamadas a métodos, declarar excepções, capturar acesso a variáveis e implementar métodos. Os atributos são aplicados a tipos. Um tipo pode ser um método, uma classe ou uma estrutura. Se um atributo for aplicado a uma classe e se este é do tipo advice para capturar chamadas a métodos, então fica aplicado a todos os métodos da classe caso não seja definido outro tipo de comportamento nas definições de atribuição do atributo Características do PostSharp Laos Aspectos reutilizáveis: os atributos são classes e como tal são reutilizáveis entre projectos; Aspectos não invasivos: não se quebra o encapsulamento, os aspectos são aplicados sem alterar o bloco de código a que estão aplicados. O PostSharp Laos envolve o bloco de código como uma caixa dentro de outra caixa; Aspectos parametrizáveis: podem ser adicionados parâmetros que são correctamente instanciados na fase de inicialização e posteriormente serializados para a assembly. 32 (Acedido em Julho 2008)

82 Limitações do PostSharp Laos Performance: o PostSharp Laos sofre das mesmas limitações dos weavers com base em proxys dinâmicos (capitulo ), influenciando negativamente na performance dos programas; Portabilidade: correntemente o PostSharp só é suportado para a plataforma. Net não o sendo nas plataformas. NET Compact Framework e Mono; Expressividade limitada: embora existam várias maneiras de expressar pointcuts, estas comparadas com outras ferramentas POA, mostram que PostSharp Laos é bastante limitado; Conjunto de advices limitados: PostSharp Laos embora possibilite um conjunto prático de advices, não oferece alguns tipos úteis, como por exemplo a introdução de variáveis Análise da Tecnologia No anexo 4 é descrita a forma de utilização das classes que o PostSharp Laos disponibiliza e um pequeno exemplo de utilização Ciclo de vida de um Aspecto Postsharp LAOS Desde a compilação até à execução, os aspectos desenvolvidos em PostSharp LAOS passam por várias fases: 1. Instanciação: nesta fase o weaver do PostSharp Laos instancia cada aspecto que está aplicado a um tipo;

83 68 2. Validação: verifica que a atribuição dos aspectos é feita correctamente, por exemplo, não permitir aplicar aspectos de chamada de métodos a variáveis. Esta validação é feita, em primeira instância, pelo weaver e numa segunda fase através da invocação de um método, que pode ser implementado em cada classe disponibilizada pelos PostSharp Laos, denominado de CompileTimeValidate, permitindo ao programador estabelecer regras (exemplo 12); public override bool CompileTimeValidate(object element) { //implementação das validações Exemplo 12 - Método CompileTimeValidate. 3. Inicialização: consiste na invocação do método CompileTimeInitialize presente em cada classe disponibilizada pelo PostSharp Laos (exemplo 13) e que permite efectuar alguns tipos de cálculos com os dados compilados até esta fase, para assim não os efectuar em tempo de execução; public override void CompileTimeInitialize(object element) { //implementação //atribuir variaveis com resultados pre calculados em compile time Exemplo 13 Método CompileTimeInitialize. 4. Serialização: todas as instâncias dos aspectos são serializadas como metadados na assembly;

84 69 5. Uso em tempo de execução: os atributos são lidos, serializados e utilizados no programa; PostSharp Core PostSharp Core é a base em que os plugins como PostSharp Laos são desenvolvidos, trabalhando ao mais baixo nível. O PostSharp Core compõe-se por: Um modelo de objectos em bytecode, que permite ao PostSharp ler e escrever assemblies.net framework; Infra-estrutura da plataforma, onde todas as tarefas a desempenhar pelos plugins ficam definidas em ficheiros XML; Weaver de baixo nível, que consiste num weaver que injecta instruções em assemblies e é a base para outros weavers de alto nível, como o do PostSharp Laos AspectJ vs. Postsharp LAOS Enquanto o AspectJ é uma extensão da linguagem de programação, por sua vez, o PostSharp é um componente que se adiciona à Framework.NET. Para tal é necessário ter uma compreensão extensiva da tecnologia para desenvolver plugins. Utilizar esses mesmos plugins é uma tarefa simples para programadores habituais da plataforma. De seguida são apresentadas as principais diferenças entre o AspectJ e o PostSharp Laos:

85 70 O AspectJ não possui restrições de licenças enquanto o PostSharp usufrui de vários tipos de licenças, dependendo porém da biblioteca em questão 33 ; O AspectJ é uma extensão à linguagem de programação java. O PostSharp Laos adiciona à framework.net namespaces e um compilador adicional; O AspectJ permite operadores lógicos em pointcuts ( &&,,! ). O PostSharp Laos permite a composição de aspectos de forma mais limitada; O AspectJ tem definições próprias para a implementação de aspectos. No PostSharp Laos a definição de aspectos é através de atributos para a plataforma.net; Em AspectJ os advices podem ser executados antes, depois e invés de. PostSharp Laos só permite este tipo de comportamento em certos aspectos; AspectJ e PostSharp integram-se transparentemente nas respectivas tecnologias Definição de Join Points O PostSharp permite criar atributos personalizados, sendo o local onde estes são aplicados definidos pelo programador, mas este está restringido às definições permitidas pelo plugin. Caso se esteja a utilizar a biblioteca Core, é possível definir qualquer tipo de Join Points. No AspectJ existe vários tipos de Join Points. Nas tabelas 7, 8 e 9 pode-se observar quais são as soluções apresentadas pelas duas tecnologias para os vários tipos de comportamentos. 33 (Acedido em Setembro de 2008)

86 71 PointCut AOP Invocação Inicialização Acesso Tratamento de Excepções AspectJ call/execution Staticinitialization/ initialization get / set handler Postsharp Laos OnMethodBoundar yaspect/ OnMethodInvocati onaspect N/A OnFieldAcces saspect Tabela 3 Comparação de pointcuts entre PostSharp Laos e AspectJ OnExceptionAs pect PointCut (continuação) AOP Controlo de fluxo Containment Condições contexto AspectJ Cflow/ cflowbelow Within/ withincode if this/ target/ args Postsharp Laos N/A N/A N/A Parametros Tabela 4 - Comparação de pointcuts entre PostSharp Laos e AspectJ Advices AOP AspectJ Postsharp Laos Advice Antes, Depois, ao invés de Antes, Depois, ao invés de (depende do tipo de pointcut) Tabela 5 comparação de tipos Definição de Aspectos Em AspectJ, os aspectos são desenvolvidos através de código Java encapsulando tanto o código normal do advice como a definição de pointcuts (exemplo 14).

87 72 public class HelloWorld { public void say ( String msg ) { System.out.println ( msg ); public static void main ( String[ ] args ) { new HelloWorld ( ).say ( "Hello, world! " ); public aspect HelloWorldAspect { pointcut saypoint ( ): execution (void HelloWorld.say ( String )); after( ): saypoint( ) { System.out.println( "Over!" ); Exemplo 14 exemplos de um aspecto em AspectJ. Por sua vez, em PostSharp Laos, os aspectos são desenvolvidos como atributos.net (exemplo 15), ficando isolados nestes, tendo a sua atribuição que ser declarada fora do atributo e no tipo ao qual se pretende capturar o comportamento (exemplo 16). using PostSharp.Laos; namespace TraceSample { [Serializable] class TraceAttribute: OnMethodBoundaryAspect { public override void OnExit(MethodExecutionEventArgs eventargs) { Console.WriteLine("On exit of {0.", this.methodname); Exemplo 15 Exemplo de um atributo com base em classes do PostSharp Laos.

88 73 class Program { static void Main(string[] args) { sayhello("world"); Console.ReadKey(); [Trace] static void sayhello(string name) { Console.WriteLine("Hello, {0.", name); Exemplo 16 Exemplo de aplicação de um atributo e um método Conclusões Na conclusão da comparação entre o AspectJ e o Postsharp LAOS verifica-se que no PostSharp LAOS todo o entrelaçamento é feito em tempo de compilação. As limitações apresentadas pelo PostSharp LAOS ao nível de join points, point cuts e advices, podem ser combatidas utilizando o PostSharp Core. Esta ultima solução é complexa e requer vastos conhecimentos técnicos e aprofundados da tecnologia PostSharp e da Framework.Net. Existem alguns projectos que correntemente utilizam a tecnologia PostSharp com sucesso. O PostSharp4EF 34 é um exemplo de que as limitações que o Postsharp Laos apresenta podem ser combatidas utilizando o PostSharp Core desenvolvendo plugins próprios. Por sua vez, o AspectJ possui um vasto leque de join points e mais tempo de existência consistindo nas razões pelas quais lhe é conferida uma maior solidez. Contudo possui uma 34 (Acedido em Setembro de 2008)

89 74 linguagem própria para a definição de pointcuts e advices que adiciona alguma complexidade, embora ao mesmo tempo torne a tecnologia mais flexível. O PostSharp é relativamente novo mas não possui linguagem própria, sendo mais simples de usar, embora mais limitado MODULARIZAÇÃO DE PADRÕES DE DESENHO Padrões de desenho Gang-of-Four [Gamma, Helm et al. 1995] (GOF) oferecem soluções flexíveis para problemas comuns no desenvolvimento de software orientado a objectos. Cada padrão é composto por um conjunto de partes que incluem: a intenção, a aplicabilidade, a estrutura da solução e um exemplo de implementação. Na figura 20, pode-se observar a implementação do padrão de desenho Observer. Este padrão de desenho permite que uma ou mais classes se registem para receber notificações e que outras classes enviem notificações a essas classes. Para permitir este comportamento é necessário adicionar métodos às classes que participam no padrão, ou seja, as classes que se registam e as classes que são notificadas.

90 75 Figura 20 Padrão de Desenho Observer implementado em POO A maioria dos padrões de desenho GOF envolve estruturas transversais na relação do padrão de desenho com as classes que participam nele. A implementação dos padrões de desenho tem efeitos no código do sistema, pois estes influenciam a sua estrutura. A sua implementação mistura-se com o código das classes, o que implica a perda de modularidade, dificultando deste modo, a tarefa de distinguir o sistema do padrão de desenho. Adicionar um padrão de desenho é uma tarefa invasiva e difícil de reverter. Enquanto que o padrão de desenho é reutilizável, a sua implementação num sistema não o é. Hannemann e Kiczales [Hannemann and Kiczales 2002] elaboraram um estudo, que compara a implementação de 23 padrões de desenho, desenvolvidos em POA na linguagem de programação AspectJ e em POO utilizando a linguagem de programação Java. As principais

91 76 ilações alcançadas pelos autores evidenciaram que 74 % dos padrões de desenho implementados utilizando POA, eram mais modulares e que 52% dos padrões se tornaram reutilizáveis noutros projectos. Sant Anna [Garcia, Sant'Anna et al. 2005] complementando o estudo anterior adicionou dados quantificados, utilizando métricas que permitem medir a separação de concerns, coesão e tamanho do código. As principais conclusões apontaram que nestes padrões de desenho, em particular a utilização de POA, ajuda a separação de concern, embora em alguns casos o acréscimo de operações aumente a complexidade interna do sistema e existam mais linhas de código por padrão de desenho. Na figura 21 é possível observar o desenho do sistema para a implementação do padrão de desenho Observer recorrendo a POA. Figura 21 Padrão de desenho Observer implementado em POA Exemplo Observer Pattern. No Anexo 6 é apresentada uma possível implementação para o sistema desenhado na figura 21.

92 Análise dos Estudos Hannemann e Kiczales [Hannemann and Kiczales 2002] analisaram 23 padrões de desenho sendo os resultados apresentados na tabela 9. Propriedades Modulares Padrão de Desenho Localizável Reutilizável Composição Transparente Removível Façade Implementações idênticas Abstract Factory Não não Não não Bridge não não Não não Builder não não Não não Factory Method não não Não não Interpreter não não n/a não Template Method (sim) não Não (sim) Adapter sim não Sim sim State (sim) não n/a (sim) Decorator sim não Sim sim Proxy (sim) não (sim) (sim) Visitor (sim) sim Sim (sim) Command (sim) sim Sim sim Composite sim sim Sim (sim) Iterator sim sim Sim sim Flyweight sim sim Sim sim Memento sim sim Sim sim Strategy sim sim Sim sim Mediator sim sim Sim sim Chain of Responsibility sim sim Sim sim Prototype sim sim (sim) sim Singleton sim sim n/a sim Observer sim sim Sim sim Tabela 6 Resumo das comparações dos padrões de desenho. A maioria dos padrões de desenho tornam-se localizáveis e removíveis sendo a sua composição transparente no sistema, implementando assim, vantagens na utilização da POA. Embora aparentemente existam vantagens para o programador, é necessário quantificá-las utilizando métricas que permitam verificar que existem melhorias ao nível da coesão, ligação e

93 78 tamanho do código desenvolvido. No estudo levado a cabo por Sant Anna [Garcia, Sant'Anna et al. 2005], utilizando métricas bem conhecidas, não foram obtidas conclusões gerais. Para estes padrões de desenho em concreto e efectuando a comparação entre as duas linguagens AspectJ e Java, o uso de aspectos ajudou a melhorar a ligação e coesão de alguns padrões de desenho, enquanto outros padrões aumentam a complexidade e desenho do sistema MODULARIZAÇÃO DE EXCEPÇÕES Os mecanismos de excepção permitem separar, de forma modular, o código normal do código para tratar situações excepcionais. Isto é, quando existe um acontecimento que não é planeado, é necessário criar código que o permita tratar e se possível continuar o programa de forma normal. Em POO este comportamento é alcançado através da utilização de excepções. Algumas considerações em relação a POA para a modularização do tratamento de excepções foram elaboradas por Filho [Castor Filho, Cacho et al. 2006]: Que atributos a POA promove e melhora para além da separação de concerns, por exemplo: melhora a ligação entre módulos, a coesão, o tamanho e o número de linhas de código, dos módulos? O tratamento de excepções em aspectos é reutilizável em sistemas de software de produção? Quando é benéfico utilizar aspectos para o tratamento de excepções e quando não o é?

94 79 Como é que os aspectos de tratamento de excepções afectam outras implementações de aspectos de outros concerns. A modularização de excepções utilizando POA consiste assim, em mover os blocos de código referente ao tratamento das excepções para aspectos, mantendo o código normal no método. No exemplo 17 é mostrada a estrutura típica de um método que trata uma excepção. public class C { void m() { try { //código normal catch (Exception E) { //tratamento da Excepção Exemplo 17 Código típico num método para o tratamento de uma excepção. Por sua vez, a modularização para aspectos consiste em primeiro manter no método o código normal e remover o tratamento da excepção (exemplo 18). public class C { void m() { //código normal Exemplo 18 Código POO sem tratamento de excepções. Deste modo, move-se todo o código referente ao tratamento para um aspecto, definindo um pointcut para interceptar esse método, um advice que permita executar (proceed) o código normal do referido método e em caso de ocorrer um erro tratar o mesmo dentro do advice (exemplo 19).

95 80 public aspect A { pointcut pcd() : execution(void C.m()); void around() : pcd() { try { proceed(); catch(exception e) { //tratamento da excepção declare soft : Exception : pcd(); Exemplo 19 Tratamento de Excepções. No método mantém-se o código normal e nos aspectos o código que trata das possíveis excepções, utiliza-se um advice para cada bloco try, englobando se possível no mesmo advice os vários blocos catch referentes a esse bloco try, utilizando-se o tipo de advice invés. No advice e no bloco try o operador proceed permite a execução do join point original. No caso de ocorrer uma excepção, os blocos catch definidos no advice tratam a excepção. Para evitar os erros em tempo de compilação, uma vez que o Java exige o tratamento obrigatório da maioria das excepções, utiliza-se o enfraquecimento de excepções (Anexo 1) para ultrapassar essa limitação. Castor Filho [Castor Filho, Garcia et al. 2005; Castor Filho, Cacho et al. 2006] testou a viabilidade da utilização da POA para modularizar o tratamento das excepções, quantificando os resultados utilizando métricas bem definidas, nomeadamente ligação, coesão e tamanho dos módulos. A análise dos testes efectuados no(s) artigo(s) sugere a utilização da POA para a modularização de excepções. Contudo, embora melhore a separação de concerns, tem desvantagens. Se o código para o tratamento da excepção não é uniforme e é extremamente dependente do contexto, ou muito complexo, a modularização recorrendo a POA pode ser mais prejudicial do que benéfica. Para um uso efectivo da POA é necessário um planeamento a priori

96 81 que tem de ser incorporado no processo de planeamento e desenvolvimento de software, para assim conseguir prever o impacto da modularização FRAMEWORKS Para além de linguagens de POA, existem frameworks que implementam o paradigma da POA de modo a facilitar a adição modular de funcionalidades. No anexo 5 referenciam-se duas Frameworks que utilizam a POA para oferecer novas formas de modularidade MÉTRICAS As métricas de software são o método mais efectivo para fornecer evidências empíricas, pois podem contribuir para o melhor entendimento das diferentes dimensões da complexidade do software [Briand, El Emam et al. 1995]. A separação de concerns de forma modular é vantajosa na maneira de pensar e implementar um software complexo, mas tem de existir resultados quantificados que demonstrem quais são as boas práticas de desenho e de implementação na utilização do Paradigma Orientado a Aspectos. Sant Anna [Sant'Anna, Garcia et al. 2003] utiliza um conjunto de métricas para analisar o desempenho da POA em relação a POO. Essas métricas, segundo ele, devem satisfazer os seguintes requisitos:

97 82 Quantificar atributos de software bem conhecidos, tais como: a separação de concerns, ligação, coesão e tamanho; Depender o mais possível das métricas tradicionais e de extensões das métricas de POO para POA; Capturar as diferentes dimensões da ligação e coesão do software orientado a aspectos; Suportar a identificação dos benefícios e desvantagens da utilização de aspectos num projecto de software, quando comparado com uma solução orientada a objectos para o mesmo problema. É proposto pelo autor um conjunto de métricas e um modelo (figura 35), que é composto por três diferentes elementos, e aos quais estão interligadas as métricas definidas. Os atributos do modelo são: Qualidades: são os atributos que primariamente se desejam num sistema software; Factores: são as qualidades de atributos secundários que influenciam os primeiros atributos definidos; Atributos Internos: estão ligados a princípios bem definidos da engenharia de software, sendo essenciais para alcançar a qualidade dos factores.

98 83 Figura 22 - Modelo de Qualidade. Neste âmbito, é elaborado pelos autores um conjunto de seis cenários evidenciando comparações entre POO e POA utilizando as várias métricas (tabela 10). Resultados dos Cenários Entidades Alteradas Operações alteradas Entidades Adicionada s Operações Adicionada s Evolução Reutilização Relações alteradas Relações Adicionada s LOCs adicionados LOCs alterados Entidades copiadsa LOCs copiados O AO O AO O AO O AO O AO O AO O AO O AO O AO O AO S S S S S S S Tabela 7 Evolução da utilização de POO e POA, segundo as métricas de Sant Anna. Noutro artigo, Ceccato [Ceccato and Tonella 2004] evolui as métricas usadas em POO e introduz novas, sendo que estas ajudam, na opinião do autor, a avaliar o efeito da POA:

99 84 WOM (Weighted Operations in Module): Número de operações num determinado módulo; DIT (Depth of Inheritance Tree): Comprimento do caminho mais longo para um determinado módulo até a raiz da classe/aspecto da hierarquia; NOC (Number Of Children): Número de subclasses ou sub-aspectos que um determinado módulo possui; CAE (Coupling on Advice Execution): Número de aspectos que contêm advices que sejam executados no disputar da execução de uma determinada operação num dado módulo; CIM (Coupling on Intercepted Modules): Número de módulos ou interfaces explicitamente definidas num pointcut de um dado aspecto; CMC (Coupling on Method Call): Número de módulos ou interfaces que declaram métodos que são possíveis de ser invocados por um dado módulo; CFA (Coupling on Field Access): Número de módulos ou interfaces que declaram atributos que são acedidos por um dado módulo; RFM (Response For a Module): Métodos e advices potencialmente executados em reposta a uma mensagem recebida por um dado módulo; LCO (Lack of Cohesion in Operations): Par de operações que trabalham em atributos de classes diferentes menos pares de operações que trabalham em atributos comuns (zero se negativo); CDA (Crosscutting Degree of an Aspect): número de módulos afectados por um pointcut e pela introdução de um dado aspecto.

100 85 Para testar as métricas desenvolveram uma ferramenta, usando o exemplo de padrões de desenho observer (anexo 6) [Hannemann and Kiczales 2002]. Os resultados (tabela 8 e 9) comparam a implementação AspectJ com a implementação em Java. Versão WOM DIT NOC CAE CIM Java AspectJ Tabela 8 - Comparação de métricas entre Java e AspectJ primeira parte. Versão CMC CFA RFM LCO CDA Java AspectJ Tabela 9 - Comparação de métricas entre Java e AspectJ segunda parte. Nos resultados é possível visualizar uma melhoria dos valores no global devido ao uso de um aspecto abstracto, mas o DIT aumentou, já que existem aspectos que herdam de outros aspectos.

101 86 4. CONSIDERAÇÕES FINAIS Nesta dissertação procurou-se abordar de forma prática a linguagem de programação AspectJ, a tecnologia Postsharp e as suas aplicações recorrendo a estudos científicos que permitem validar a aplicabilidade das tecnologias POA. Assim, as principais contribuições deste trabalho consistem na síntese da história das tecnologias que envolvem separação de concerns, descrição e análise dos estilos da linguagem de programação AspectJ e Postsharp. Este trabalho é ainda enriquecido com a apresentação de pesquisas no campo da modularização de padrões de desenho, modularização de excepções e métricas de comparação. A abordagem seguida foi da apresentação de exemplos práticos e alusões a aplicações reais de situações onde estes se podem aplicar. A tecnologia POA permite adicionar mecanismos para melhorar a implementação de crosscutting concerns através de vários tipos de aproximações, código fonte, código intermédio e máquinas virtuais. Estas tecnologias visam alcançar a separação de concerns permitindo implementar vários tipos de crosscutting concerns modularmente. As tecnologias foram evoluindo e presentemente existem ferramentas que já possuem integração nos mais variados tipos de ambientes de desenvolvimento, instalando-se como extensões naturais às linguagens existentes nesses ambientes. Estas ainda precisam de algum tempo para colmatar algumas falhas e apresentar ferramentas que permitam solucionar alguns problemas e melhorar a experiência do

102 87 programador, de maneira a permitir a depuração, garantir a exacta aplicação dos aspectos, bem como, manter a aplicabilidade dos aspectos quando existe a alteração ou evolução do código base, por exemplo através da utilização de refactoring. Para tal, são necessários estudos que sejam conclusivos e demonstrados com métricas quantitativas que permitam definir exactamente que tipo de crosscuting concerns a POA, tecnologicamente falando, melhora. Isto é, tem de existir a garantia que a nova forma de modularização não acarreta prejuízos tecnológicos. Podem-se enumerar alguns problemas que a POA acarreta, devido à falta de ferramentas ou à sua complexidade, tais como: Complexidade: como todas as novas tecnologias existe uma curva de aprendizagem aos novos conceitos. Os vários estilos de programação que existem em POA uns mais complexos que outros, com o tempo e o amadurecimento das linguagens de programação diminuirão a complexidade; Que tipos de comportamentos crosscutting são possíveis desenvolver, para além de transacções e registos; Padrões de desenho ou de frameworks evitam o uso de POA: estas técnicas e tecnologias não são uma solução genérica como a POA; Depuração: a depuração de aspectos é problemática, e em qualquer tecnologia a depuração é uma tarefa difícil sem as ferramentas adequadas, para tal em POA devem-se desenvolver ferramentas que permitam uma depuração mais simplificada; A evolução dos sistemas pode ser afectada pelos aspectos já desenvolvidos: a forma de desenvolver pointcuts pode limitar a evolução das classes ou criar um sistema onde os aspectos vão ter um comportamento incerto, já que as regras de

103 88 captura podem não se aplicar. As ferramentas de desenvolvimento devem ajudar a prevenir estas situações suportando avisos ou refactoring para adaptar os aspectos; Segurança, como prevenir que sistemas possam ser estendidos através de POA? Como benefícios da utilização do Paradigma Orientado as Aspectos podem-se enumerar: Código mais limpo: ao ser necessário só ter em consideração uma área de cada vez é mais fácil de perceber e editar o código escrito; Modularização superior: todos os concerns dos sistemas são separados de acordo com a sua forma natural; Fácil de evoluir: modificações para melhorar a performance de um sistema ou regras de negócio são facilmente acopladas ao sistema; Mais código reutilizável: a eliminação do efeito de intrusão e espalhamento permite que os módulos sejam facilmente acoplados a outros sistemas de software; Rápido de implementar: fácil divisão de tarefas e desenvolvimento paralelo em separado; Redução de custos: a possibilidade de desenvolver mais rapidamente e o aumento da reutilização tem como efeito a redução de custos; Existe um grande esforço e dedicação da comunidade académica na investigação nas várias áreas da DSOA, que trabalham para colmatar a falta de ferramentas e modelos para as várias etapas do desenvolvimento de software. Este esforço começa a ser recompensado com a

104 89 crescente implementação de tecnologias como o Postsharp e inclusão de Weavers em frameworks populares demonstrando que os problemas da tecnologia estão a ser corrigidos e que os conceitos mais práticos são viáveis, acarretando benefícios ao nível comercial nomeadamente na redução de tempo de implementação e custos, o que faz prever que a tecnologia continue a evoluir e amadurecer nas suas diversas áreas. O presente trabalho abre caminho como base de introdução à tecnologia POA na tentativa de se conhecer o problema que se tenta resolver, o modelo e as ferramentas que existem para o resolver, podendo ainda ser enriquecido com a adição de novos estudos quantitativos, tecnologias POA emergentes, outras formas de desenvolvimento e exemplo de aplicações reais da tecnologia.

105 90 5. BIBLIOGRAFIA Aksit, M., K. Wakita, et al. (1993). Abstracting Object-Interactions Using Composition-Filters. Object-Based Distributed Processing. R. Guerraoui, O. Nierstrasz and M. Riveill, Springer-Verlag Lecture Notes in Computer Science: Backus, J. W., R. J. Beeber, et al. (1957). "The FORTRAN automatic coding system." Western Joint Computer Conference: Berard, E. V. (2002). "Abstraction, Encapsulation, and Information Hiding." Bergmans, L. and M. Aksit (2001). "Composing Crosscutting Concerns Using Composition Filters." Comm. ACM 44(10): Booch, G. (1994). Object-oriented analysis and design with applications, Benjamin/Cummings Pub. Co Redwood City, Calif. Booch, G. (2001). "Through the Looking Glass." Software Development, July. Briand, L., K. El Emam, et al. (1995). "Theoretical and Empirical Validation of Software Product Measures." International Software Engineering Research Network, Technical Report ISERN Brown, A. W. and K. C. Wallnau (1998). "The current state of CBSE." Software, IEEE 15(5): Castor Filho, F., N. Cacho, et al. (2006). "Exceptions and aspects: the devil is in the details." Proceedings of the 13th ACM SIGSOFT 14th international symposium on Foundations of software engineering: Castor Filho, F., A. Garcia, et al. (2005). "A quantitative study on the aspectization of exception handling." Proceedings of the ECOOP 2005 Workshop on Exception Handling in Object- Oriented Systems.

106 91 Ceccato, M. and P. Tonella (2004). "Measuring the Effects of Software Aspectization." Proc. of the 1st Workshop on Aspect Reverse Engineering (CD-ROM), The Netherlands. Clement, A., A. Colyer, et al. (2003). "Aspect-Oriented Programming with AJDT." ECOOP Workshop on Analysis of Aspect-Oriented Software. Czarnecki, K., U. W. Eisenecker, et al. Beyond Objects: Generative Programming. Dijkstra, E. W. (1968). " Go To Statement Considered Harmful." Communications of the ACM 11: Dijkstra, E. W. (1976). A discipline of programming. Englewood Cliffs, New Jersey, Prentice- Hall. Elrad, T., M. Aksit, et al. (2001). "Discussing Aspects of AOP." Comm. ACM 44(10): Elrad, T., R. E. Filman, et al. (2001). "Aspect-Oriented Programming." Comm. ACM 44(10): Filman, R. E. and D. P. Friedman (2000). "Aspect-Oriented Programming is Quantification and Obliviousness." Workshop on Advanced Separation of Concerns Floyd, R. W. (1979). "The paradigms of programming." Communications of the ACM 22(8): Fraiteur, G. (2008). "User-friendly aspects with compile-time imperative semantics in.net: an overview of PostSharp." 9. Gamma, E., R. Helm, et al. (1995). Design patterns: elements of reusable object-oriented software. Garcia, A., C. Sant'Anna, et al. (2005). "Modularizing design patterns with aspects: a quantitative study." Aspect-oriented software development: Proceedings of the 4 th international conference on Aspect-oriented software development 14(18): Hannemann, J. and G. Kiczales (2002). Design pattern implementation in Java and AspectJ. Proceedings of the 17th ACM conference on Object-oriented programming, systems, languages, and applications, ACM Press. Harrison, W. and H. Ossher (1993). Subject-Oriented Programming---A Critique of Pure Objects. Proc Conf. Object-Oriented Programming Systems, Languages, and Applications.

107 92 Harrison, W., H. Ossher, et al. (2005). "Concern modeling in the concern manipulation environment." Proceedings of the 2005 workshop on Modeling and analysis of concerns in software: 1-5. Harrison, W., H. Ossher, et al. (2005). "Supporting aspect-oriented software development with the Concern Manipulation Environment." IBM Systems Journal 44(2): Hayes, B. (2003). "THE POST-OOP PARADIGM." American Scientist 91(2). Hilsdale, E. and J. Hugunin (2004). "Advice weaving in AspectJ." Proceedings of the 3rd international conference on Aspect-oriented software development: Hürsch, W. L. and C. V. Lopes (1995). Separation of Concerns. Boston, MA, College of Computer Science, Northeastern University. Kaplan, M., H. Ossher, et al. (1996). Subject-Oriented Design and the Watson Subject Compiler. Proc. OOPSLA'96 Workshop on Subjectivity. Kernighan, B. W. and D. M. Ritchie (1988). The C programming language, Prentice-Hall. Kiczales, G. (1996). "Beyond the black box: Open implementation." {IEEE Software 13(1): Kiczales, G., J. des Rivieres, et al. (1991). The Art of the Metaobject Protocol. Cambridge, Massachusetts, MIT Press. Kiczales, G. and E. Hilsdale (2001). Aspect-oriented programming. Proceedings of the 8th European Software Engineering Conference held jointly with 9th Acm Sigsoft Symposium on Foundations of Software Engineering, ACM Press. Kiczales, G., E. Hilsdale, et al. (2001). "Getting Started with AspectJ." Comm. ACM 44(10): Kiczales, G., E. Hilsdale, et al. (2001). An overview of AspectJ. Proc. ECOOP 2001, LNCS 2072, Berlin, Springer-Verlag. Kiczales, G., J. Lamping, et al. (1997). Aspect-Oriented Programming. 11th Europeen Conf. Object-Oriented Programming, Springer Verlag. Kiczales, G. and M. Mezini (2005). Aspect-oriented programming and modular reasoning. ICSE '05: Proceedings of the 27th international conference on Software engineering, New York, ACM Press. Kuhn, T. S. (1970). The Structure of Scientific Revolutions, University of Chicago Press.

108 93 Laddad, R. (2003). "AspectJ in Action." 512. Lieberherr, K., D. Orleans, et al. (2001). "Aspect-Oriented Programming with Adaptive Methods." Comm. ACM 44(10): Lieberherr, K. J. (1996). Adaptive Object-Oriented Software: the Demeter Method with Propagation Patterns, PWS Publishing Company, Boston. Lindholm, T. and F. Yellin (1999). Java Virtual Machine Specification, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA. Liskov, B. H. and J. M. Wing (2001). "Behavioural subtyping using invariants and constraints." Lopes, C. V. (1996). Adaptive parameter passing. 2nd Int'l Symposium on Object Technologies for Advanced Software, Springer-Verlag. Lopes, C. V. (1997). D: A Language Framework for Distributed Programming, College of Computer Science, Northeastern University. Lopes, C. V. (2002). AOP: A Historical Perspective (What's in a Name?): Löwy, J. (2003). Programming. NET Components, O'Reilly. Maes, P. (1987). "Concepts and experiments in computational reflection." Mehmet Aksit, K. W., Jan Bosch, Lodewijk Bergmans, Akinori Yonezawa (1994). "Abstracting Object Interactions Using Composition Filters." Mendhekar, A., G. Kiczales, et al. (1997). RG: A Case-Study for Aspect-Oriented Programming, Palo Alto Research Center. Okamura, H. and Y. Ishikawa (1994 ). "Object Location Control Using Meta-level Programming." Ossher, H. and P. Tarr (1999). Multi-Dimensional Separation of Concerns using Hyperspaces, IBM Research Report. Ossher, H. and P. Tarr (2000). "Hyper/J: multi-dimensional separation of concerns for Java." Proceedings of the 22nd international conference on Software engineering: Ossher, H. and P. Tarr (2001). "The Shape of Things To Come: Using Multi-Dimensional Separation of Concerns with Hyper/J to (Re)Shape Evolving Software." Comm. ACM 44(10): Parnas, D. L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules." Comm. ACM 15(12):

109 94 Rashid, A., P. Sawyer, et al. (2002). "Early aspects: a model for aspect-oriented requirements engineering." Requirements Engineering, Proceedings. IEEE Joint International Conference on: Rumbaugh, J., I. Jacobson, et al. (1996). "The Unified Modeling Language." Documentation Set 1. Sant'Anna, C. a., A. Garcia, et al. (2003). On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. XVII Brazilian Symposium on Software Engineering. Smith, B. C. (1982). "Procedural Reflection in Programming Languages." 762. Smith, B. C. (1985). "Prologue to "Reflection and Semantics in a Procedural Language''." Szyperski, C. (1998). Component Software: Beyond Object-oriented Programming, Addison- Wesley Professional. Szyperski, C., J. Bosch, et al. (1999). "Component-Oriented Programming." Object-Oriented Technology: ECOOP'99 Workshop Reader: ECOOP'99 Workshops, Panels, and Posters, Lisbon, Portugal, June 14-18, 1999: Proceedings. Tarr, P., H. Ossher, et al. (1999). N Degrees of Separation: Multi-Dimensional Separation of Concerns. Proc. 21st Int'l Conf. Software Engineering (ICSE'1999), IEEE Computer Society Press. Wirth, N. (1971). "The programming language pascal." Acta Informatica 1(1):

110 6. ANEXOS 95

111 96 ANEXO 1: LINGUAGEM ASPECTJ 6.1 PRESSUPOSTOS Para a demonstração prática da linguagem utilizar-se-á o diagrama UML [Rumbaugh, Jacobson et al. 1996] (figura 23). Figura 23 Diagrama UML do exemplo. AspectJ Para a elaboração dos exemplos foi utilizado o Eclipse 3.4, o java SDK 6 actualização 6 e

112 JOIN POINT Um elemento crítico no desenho de uma linguagem orientada a aspectos é o modelo de join point (Pontos de Junção). Este modelo permite disponibilizar um quadro comum de referência para definir a estrutura dos crosscutting concerns [Kiczales, Hilsdale et al. 2001]. Em AspectJ, join points são pontos bem definidos no fluxo do programa em execução. São disponibilizados pela linguagem acesso a vários tipos de join points, os que são mais frequentemente utilizados, visam capturar: chamadas aos métodos, capturar o contexto exterior do método e capturar o despontar de um método dentro do contexto de outro método. 6.3 POINTCUT PointCut (Secção) permite definir conjuntos de join points e expor informações de contexto desses join points. Por exemplo, o seguinte pointcut call (void Point.setX (int)) intercepta chamadas ao método setx da classe Point com argumento de entrada tipo int e sem argumento de saída, void, o tipo de join point usado foi o call que permite capturar chamadas a métodos. Em AspectJ a definição de pointcuts é definida pelo programador (exemplo 20). pointcut nome_do_pointcut ( arg1,..., argn ) : definição de join points Exemplo 20 - sintaxe para definir um pointcut em AspectJ. Na definição (exemplo 20) nome_do_pointcut é o nome atribuído pelo programador para identificar o pointcut, que cuja interface (a forma de interagir com o pointcut) tem por

113 98 argumentos arg1,, argn, os Join points encontram-se declarados na parte da definição. Existem vários tipos de operadores que identificam os vários Join points. O Join Point é associado a um ponto no fluxo do programa, para por exemplo se capturar uma chamada a um método, declara-se a assinatura do método a ser capturado (exemplo 21). pointcut secção_setxpoint: call(void Point.setX(int)); Exemplo 21 Exemplo de declaração de um pointcut Métodos e Construtores AspectJ disponibiliza dois tipos primitivos para capturar a chamada e execução de métodos ou construtores de classes. Chamadas a métodos e/ou construtores Efectua a captura de chamadas a métodos ou construtores, a captura ocorre depois da avaliação dos argumentos e, antes ou depois da execução do bloco de código do método ou construtor. Utiliza-se o operador call, que identifica o join point para capturar chamadas, fornecendo a assinatura do método ou construtor a ser capturado. No exemplo 22, é capturada a chamada ao método setx da classe Point com argumento de entrada do tipo int e sem argumento de saída. call( void Point.setX(int) ) Exemplo 22 Intercepção de métodos. Para capturar chamadas a um construtor de uma classe, ao invés de se declarar o nome do método, como no exemplo anterior, é definido pela linguagem que se deve utilizar o termo new e removido o argumento de saída da assinatura (exemplo 23).

114 99 call( Point.new(int, int) ) Exemplo 23 Intercepção de um construtor de uma classe. Execução de métodos e ou construtores A intercepção da execução de métodos ou construtores permite a captura do inicio ou do fim da execução do bloco de código interno desse método. A execução de métodos ou construtores é definida utilizando o operador execution, fornecendo a assinatura do método ou construtor (exemplo 24). execution( void Point.setX(int) ) Exemplo 24 Intercepção da execução de um método. Para definir o mesmo tipo de comportamento para um construtor de uma classe, é utilizado o termo new invés do nome do método e é removido o argumento de saída, analogamente ao que acontece com o pointcut do tipo call (exemplo 25). execution( Point.new(int, int) ) Exemplo 25 Intercepção de um construtor Atributos Atributos são variáveis definidas em classes, é possível capturar o acesso de leitura ou de escrita a atributos estáticos e não estáticos. Para capturar o acesso de leitura a um atributo utiliza-se o operador get (exemplo 26) e para capturar acessos de escrita, o operador set, junto com a assinatura do atributo (exemplo 27). get (Point.nome_atributo) Exemplo 26 - Intercepção do acesso de leitura a um atributo da classe Point.

115 100 set (Point.nome_atributo) Exemplo 27 Intercepção do acesso de escrita a um atributo da classe Point Tratamento de excepções Excepções permitem o tratamento de situações anómalas que ocorram durante a execução de um certo bloco de código. Para capturar a execução do tratamento de uma excepção, o bloco de código dentro da cláusula catch, utiliza-se o operador Handler fornecendo o tipo da excepção (exemplo 28). handler( DataFormatException ) Exemplo 28 Intercepção do tratamento de uma excepção Inicialização estática A inicialização estática permite definir valores, que são atribuídos aquando da execução do programa. Para capturar a inicialização de código estático utiliza-se o operador staticinitialization junto com o tipo, por exemplo o nome de uma classe (exemplo 29). staticinitialization( Point ) Exemplo 29 Inicialização estática Inicialização de objectos AspectJ permite capturar a execução da inicialização de objectos através dos operadores initialization e preinitialization fornecendo o nome da classe e a palavra new que identifica o construtor da classe. No exemplo 30 captura-se a inicialização de objectos:

116 101 initialization(point.new(..)) Exemplo 30 Inicialização de Objectos. No exemplo 31 captura-se da pré-inicialização de objectos: preinitialization(point.new(..)) Exemplo 31 Pre-inicialização de Objectos Lógica Booleana AspectJ permite agrupar vários Join Points num só pointcut, permitindo uma elaboração minuciosa na definição de situações de captura. Para agrupar vários join points utiliza-se a lógica booleana. Intercessão, definida pelos símbolos && ; União, definida pelos símbolos ; Inversão, definida pelo símbolo!. No exemplo 32, captura-se a chamada ao método setx ou ao método sety. pointcut secção_set(): call(void Point.setX(int)) call(void Point.setY(int) Exemplo 32 Agrupar vários Join Points. É possível construir condições lógicas com join points utilizando o operador de decisão if. Permitindo limitar a captura de join points com base num certo contexto. No exemplo 33, captura-se a chamada ao método setx, na classe Point cujo argumento de entrada seja do tipo int e este for de valor inferior a 0. call(void Point.setX(int)) && args(x) && if(x<0) Exemplo 33 - Utilização do operador, if.

117 Exposição do contexto É possível ter acesso ao contexto, ou seja, à informação de um determinado join point durante a execução do programa. Por exemplo é possível ter acesso aos argumentos, de entrada ou de saída, de um método. Os operadores que o permitem são this, target, e args. Estes operadores tem dupla funcionalidade, funcionam como join point de selecção e expor o contexto. No exemplo 34, define-se a captura de todos os métodos que tenham um único argumento de entrada do tipo int, permitindo o acesso a esse argumento que está declarado na interface do pointcut. pointcut intarg(int i): args(i) Exemplo 34 Pointcut args. Utilizando a lógica booleana é possível definir clausulas mais especificas. No exemplo 35, captura-se a chamada ao método setx e utiliza-se o operador args, para obter acesso ao argumento de entrada, tipo int, do método para por exemplo, implementar uma restrição nos valores que a função aceita. pointcut conjunto_setxpoint(int x):call(void Point.setX(int))&& args(x); Exemplo 35 Utilização da lógica booleana em pointcuts. É possível também utilizar o operador de decisão if. No exemplo 36, utiliza-se o operador if para filtrar o acesso ao contexto. Permitindo definir minuciosamente o pointcut, assim só serão capturadas todas as chamadas ao método setx da classe Point cujo argumento de entrada tenha um valor inferior a zero.

118 103 Pointcut conjunto_setxpoint(int x):call(void Point.setX(int)) && args(x) && if(x<0) Exemplo 36 Utilização do operador If. Para capturar um tipo de objecto é possível utilizar o operador this fornecendo o nome da classe. No exemplo 37, captura-se todos os join points que ocorram durante a execução a instâncias do tipo Point, não captura contexto estático. É um comportamento dinâmico. this(point) Exemplo 37 Operador this. Para capturar join points num objecto existe o operador target e que fornece o nome da classe. No exemplo 38, captura-se todo o comportamento da classe Point, chamadas a métodos e atribuições de atributos. É um comportamento estático. target(point) Exemplo 38 Operador target Redefinir assinaturas AspectJ possibilita utilizar símbolos (Wildacards) para ajudar a definir as assinaturas dos pointcuts, a tabela 10 mostra os símbolos permitidos. Símbolo Descrição.. Quaisquer números e tipo de argumentos. * Quaisquer palavras seguintes; Tipo de argumento de saída arbitrário; Tipo arbitrário de classe ou método. + Quaisquer subclasses. Tabela 10 Símbolos permitidos nas assinaturas.

119 104 No exemplo 39, é definido um pointcut que permite capturar a execução de métodos com o nome m com um número arbitrário de argumentos de entrada, utilizando o símbolo.., e sem argumentos de saída. pointcut allm(): execution(void m(..)) Exemplo 39 Utilização do símbolo... No exemplo 40, captura-se qualquer chamada a método (s) de nome m da classe MyClass com quaisquer tipo de argumento de saída, utilizando o símbolo *, e quaisquer número de argumentos de entrada, utilizando o símbolo... pointcut allm(): call(* MyClass.m (..)) Exemplo 40 Utilização do símbolo * e... No exemplo 41, o símbolo * é utilizado para captura o método mover, este pode estar implementado em quaisquer classe do programa, com quaisquer tipo de argumento de saída, e utilizando o símbolo.., qualquer número e tipo de argumentos de entrada. pointcut mover(): call(* *.mover(..)) Exemplo 41 Utilização do símbolo * e... No exemplo 42, permite utilizar o símbolo *, para capturar qualquer método da classe com quaisquer tipos de argumentos de saída e quaisquer números e tipo de argumentos de entrada. pointcut mover(): call(* Classe.*(..)) Exemplo 42 Utilização do símbolo *. No exemplo 43, o símbolo * é utilizado para completar o nome do método, capturando qualquer tipo de argumento de saída e quaisquer tipo e número de argumentos de entrada de qualquer método da classe, que comece por set, por exemplo agrupará setx e sety, etc.

120 105 pointcut mover(): call(* Classe.set*(..)) Exemplo 43 - Utilização do símbolo *. No exemplo 44, o símbolo * é utilizado para seleccionar qualquer tipo de atributo da classe que comece por id (idcliente, idxpto, etc.). pointcut id(): get(* Classe.id*) Exemplo 44 - Utilização do símbolo "*". No exemplo 45, utiliza-se o símbolo + para capturar a chamada ao construtor da classe Foo e de todos os construtores das subclasses que herdem de Foo. pointcut allnew(): call ( Foo+.new() ) Exemplo 45 Utilização do símbolo +. No exemplo 46, é utilizado os símbolos *, + e (..), para seleccionar todas as chamadas aos métodos que cujo nome comece por set e com um número arbitrário de argumentos de entrada da classe Figura e todas as subclasses que herdem dessa classe. pointcut allnew(): call (* Figura+.set*(..) ) Exemplo 46 Utilização do símbolo +, * (..) Modificadores É possível capturar métodos com base nos seus modificadores, public, static, para definir cláusulas mais específicas (exemplo 47). call(public final void C.foo() throws ArrayOutOfBoundsException) Exemplo 47 utilização do modificador public.

121 106 (exemplo 48). Também é possível utilizar o símbolo booleano da inversão (!) para definir join points call(!static * *(..)) Exemplo 48 utilização do modificador static em conjunto com a negação Estrutura Para definir join points em relação a estrutura dentro de uma classe, utiliza-se o operador within para capturar join points dentro do corpo de uma classe e declarações associadas a esse tipo de classe (exemplo 49). Exemplo 49 Operador Within. within( Point ) Outro operador withincode permite capturar join points no corpo de um método de uma classe fornecendo a classe e o método como assinatura (exemplo 50). withincode( void Device.update() ) Exemplo 50 Operador withincode Fluxo O operador clfow (exemplo 51) permite capturar todos os join points a partir de um determinado ponto, caso se queira excluir o join point inicial deve-se usar o operador cflowbelow (exemplo 52). cflow ( execution ( void device.update() ) ) Exemplo 51 Operador cflow. cflowbelow( execution ( void device.update() ) ) Exemplo 52 - Operador cflowbelow.

122 ADVICE Advices permitem definir um bloco de código que é associado a um pointcut. O bloco de código é o comportamento adicional onde é implementado o crosscutting concerns. Advices podem ser executados antes, depois ou ao invés de, permitindo definir o tempo em que é aplicado o comportamento ao join point. Advices estão associados a um pointcut, este pode estar previamente definido ou pode ser declarado anonimamente (exemplo 53). TipoDeAdvice [ Excepção ] : Pointcut { Bloco de codigo Exemplo 53 Sintaxe de declaração de um Advice Tipos de Advice Para definir um comportamento que é efectuado antes de um join point define-se o tipo de advice como before, na interface do advice devem ser colocados os argumentos que permitem ter acesso ao contexto do join point capturado (exemplo 54). Exemplo 54 Advice tipo antes. before ( arg1,, argn ) Para definir um comportamento depois de uma chamada a um método tem de se ter em conta que existem várias possibilidades para a forma de um método estar declarado. Este pode ser declarado para lançar uma excepção, devolver um objecto ou nenhuma das duas anteriores. Para definir um comportamento depois de uma chamada a um método e este devolver um argumento de saída (exemplo 55). after (arg1,, argn) returning [ (arg1,, argn) ] Exemplo 55 Advice tipo depois, com retorno de argumentos.

123 108 Para definir um comportamento depois de uma chamada a um método, e este método lançar uma excepção (exemplo 56). after (arg1,, argn) throwing [ (arg1,, argn) ] Exemplo 56 Advice tipo depois com declaração de excepção. Para definir um comportamento depois de uma chamada a um método (exemplo 57). after (arg1,, argn) Exemplo 57 Advice tipo depois. É possível substituir o bloco de código que é executado num determinado join point para definir esse comportamento deve ser usado o tipo around (exemplo 58). Tipo around (arg1,, argn) Exemplo 58 Advice tipo invés de Exemplo de advice No exemplo 59 é definido um pointcut que captura chamadas aos métodos setp1 e setp2 da classe Line. São implementados dois advices, um que executa antes e outro que executa depois. Por exemplo com este dois tipos de advices é simples implementar um sistema de anular e repor estados. ; pointcut chamada(): call(void Line.setP1(..)) call(void Line.setP2(..)) before(): chamada(){ System.out.println("antes"); after(): chamada(){ System.out.println("depois"); Exemplo 59 Exemplo da declaração de advices

124 Lançar excepções Excepções podem ser, opcionalmente, lançadas no bloco de código de um advice, mas existem regras bem definidas para quando é possível lançar excepções e quando não é: Execução ou chamadas a métodos ou construtores - só é possível lançar as excepções que estão declaradas no(s) método(s) ou construtor(es) em causa; Atribuição e leitura de atributos e inicialização estática - não é possível lançar qualquer excepção; Tratamento de excepções - as excepções que são possíveis lançar são do mesmo tipo que a capturada; Pré-inicialização e inicialização - é possível lançar as excepções que estão declaradas no construtor da classe que está a ser inicializada; Execução de advice - qualquer excepção que está declarada na clausula do advice Precedência Podem existir casos em que múltiplos advices estão aplicados a um mesmo join point, a ordem pela qual são aplicados pode ser definida pelo programador. Existem dois casos distintos: 1. Os advices estão em unidades modulares, aspectos, diferentes; 2. Os advices estão na mesma unidade modular. Se dois advices, A e B, estão aplicados a um mesmo join point mas estes advices encontram-se em aspectos diferentes, a precedência tem as seguintes condições:

125 110 Se o aspecto A é invocado antes que o aspecto B, especificando este comportamento com o operador declare precedence, então todos os advices aplicados ao mesmo join point no aspecto A, tem precedência aos do aspecto B; Se o aspecto A estende o aspecto de B, então todos os advices definidos no aspecto A tem precedência sobre os advices do aspecto B, a não ser que esteja especificado de outra forma, com o operador declare precedence por exemplo; Se não existir qualquer forma de declaração por parte do programador, então não é possível determinar qual dos aspectos tem precedência. Se dois advices aplicados a um mesmo join point se encontram declarados no mesmo aspecto, a precedência tem as seguintes condições: Se o advice é do tipo after, o advice que aparecer em último lugar no código do aspecto terá precedência; Para qualquer outro tipo de advice, o que aparecer em primeiro lugar no código do aspecto terá precedência. Sintaxe para a definição explícita de precedência de aspectos (exemplo 60). declare precedence : Lista de Aspectos; Exemplo 60 Sintaxe da precedência de aspectos. No exemplo 61, é declarada a precedência de alguns aspectos, de notar que se pode utilizar Wildcards declare precedence: *..*Security*, Logging+, *; Exemplo 61 Precedência de aspectos.

126 111 No exemplo 62, são definidos três aspectos. O aspecto Ordem define a ordem em que os outros dois aspectos são executados, já que esses dois capturam o mesmo ponto no fluxo do programa. aspect Ordem { declare precedence : CountEntry, DisallowNulls; aspect DisallowNulls { pointcut alltypemethods(line obj): call(* *(..)) && args(obj,..); before(line obj): alltypemethods(obj) { if (obj == null) throw new RuntimeException(); aspect CountEntry { pointcut alltypemethods(line obj): call(* *(..)) && args(obj,..); static int count = 0; before(): alltypemethods(line) { count++; Exemplo 62 Declaração de precedências. 6.5 INTER-TYPE DECLARATIONS Inter-type declarations, permitem alterar o comportamento estático do programa, a estrutura do código, como a introdução de atributos, métodos em classes e interfaces. Permitindo a modificação da hierarquia, a declaração de erros, advertências de compilação e enfraquecimento de excepções (secção 6.6).

127 Adição comportamentos AspectJ permite a introdução de novos atributos e métodos em classes e interfaces, e construtores em classes. A adição modular de comportamentos, evita redundância de código, e permite a implementação de comportamentos por omissão em interfaces, que posteriormente são compostos nas classes que as implementam. Adicionar Métodos. É possível adicionar métodos e declarar o seu bloco de código (exemplo 63) ou métodos abstractos (exemplo 64). [ Modificadores ] Tipo NomeClasse. nomemetodo( argumentos ) [ Excepção ] { Código Exemplo 63 Adição de um método. abstract [Modificadores] Tipo NomeClasse. nomemetodo ( argumentos ) [Excepção] ; Exemplo 64 Adição de um método abstracto. No exemplo 65 é adicionado um método a um interface. //definir a interface interface Iface { aspect A { private void Iface.m() { System.err.println("metodo da interface"); void worksoni(iface iface) { // invocar o método m. iface.m(); Exemplo 65 Exemplificação da adição de métodos. Adição de construtores A adição de construtores têm sintaxe semelhante à adição de métodos mas segue a regra que o nome tem de ser o termo new para a declaração de um construtor (exemplo 66).

128 113 [Modificadores] NomeClasse. new (argumentos) [Excepção] { Código Exemplo 66 Adição de um construtor a uma classe. Adição de atributos È possível também adicionar atributos às classes, a sintaxe para a declaração de atributos permite a atribuição de valores (exemplo 67) ou só a declaração do atributo (exemplo 68). [Modificadores] Type NomeClasse. nomeatributo = Expressão; Exemplo 67 Declaração de um atributo com atribuição de valor. [Modificadores] Type NomeClasse. nomeatributo; Exemplo 68 Declaração de um atributo. Modificar hierarquia AspectJ permite modificar a hierarquia das classes (exemplo 69), desde que esta não viole as regras de herança do Java, e declarar interfaces (exemplo 70). declare parents: NomeClasse extends TipoaEstender; Exemplo 69 Estender um tipo. declare parents: NomeClasse implements TipoaEmplementar; Exemplo 70 Implementar um tipo. No exemplo 71, o aspecto modifica a classe estendendo a hierarquia desta, implementado a interface runnable e adicionando os métodos que são obrigatórios implementar dessa interface run. aspect A { declare parents: SomeClass implements Runnable; public void SomeClass.run() {... Exemplo 71 Estender e implementar métodos em classes.

129 114 Declaração de erros e advertências em tempo de compilação É possível declarar erros e advertências em tempo de compilação. Quando se verifica um determinado comportamento definido num pointcut, o compilador avisa com um erro ou com uma advertência, emitindo uma mensagem que foi posteriormente definida pelo programador. O pointcut pode estar previamente definido ou declarado anonimamente. A sintaxe para declaração de erros é a do exemplo 72, enquanto a sintaxe para a declaração de advertências é a definida no exemplo 73. declare error: Pointcut: "Mensagem de erro" Exemplo 72 Atribuição de um erro a um pointcut. declare warning: Pointcut: "mensagem de aviso" Exemplo 73 Atribuição de uma advertência a um pointcut. No exemplo 74, define-se um erro para obrigar o programador a utilizar os métodos set dos atributos, e fornecendo um erro quando este não o faz. Assim quando dentro da classe se aceder directamente para escrever num atributo, o compilador ao compilar o programa emite um erro. declare error: set(int Point.*) &&!withincode(void Point.set*(int)): "use o método setter, mesmo dentro da classe."; Exemplo 74 exemplo da utilização da declaração de erros. 6.6 ENFRAQUECIMENTO DE EXCEPÇÕES Podem existir situações onde é obrigatório tratar excepções, mas essas excepções da forma que o código é implementado nunca irão ser despoltadas. O Java obriga a que seja declarado o tratamento da excepção, excepto se essa excepção estender a excepção

130 115 RuntimeException ou Error. AspectJ permite redefinir excepções da linguagem Java para que estas herdem da excepção RuntimeException, e assim evitar o tratamento da excepção (exemplo 75). declare soft: TipoExcepção: Pointcut; Exemplo 75 Sintaxe para a declaração de enfraquecimento de excepções. No exemplo 76, é utilizado o enfraquecimento de excepção para não tratar a excepção ClassNotFoundException. abstract pointcut softeningpc(); before() : softeningpc() { Class.forName("FooClass"); // erro: ClassNotFoundException declare soft : ClassNotFoundException : call(* Class.*(..)); Exemplo 76 - Exemplo do enfraquecimento de excepções. 6.7 ASPECTOS Aspectos são unidades modulares que contêm a implementação dos comportamentos transversais, são compostos por pointcuts, advices, inter-type declarations e código java normal. Aspectos não podem ser instanciados directamente, mas se for necessário é possível criar um construtor, mas este construtor não pode ter argumentos ou lançar excepções. Para se declarar um aspecto utiliza-se o termo aspect (exemplo 77). aspect Nome {... Exemplo 77 Declaração de um aspecto.

131 116 É possível que aspectos contenham outros aspectos internamente, estes aspectos que estão acoplados dentro de outros aspectos têm de ser obrigatoriamente declarados estáticos com o modificador static. Aspectos podem ser estendidos por outros aspectos da mesma forma que uma classe normal de Java, mas só se o aspecto base está declarado como abstracto. Aspectos podem estender classes ou interfaces, embora classes não possam estender aspectos. Aspectos não podem ser instanciados directamente, mas é possível aceder à sua instância através do método estático, aspectof, que está implementado em todos os aspectos concretos Aspectos Singleton Por omissão o aspecto só tem uma instância, que é transversal ao programa que está a ser executado, a este tipo de aspecto chama-se singleton. A sintaxe, normal, para a declaração de um aspecto singleton é a do exemplo 78. Opcionalmente pode-se usar a definição do exemplo 79. aspect Nome {... Exemplo 78 Declaração de um aspecto singleton. aspect Nome issingleton() {... Exemplo 79 - Declaração alternativa de um aspecto singleton Instanciar aspectos por objecto É possível associar um aspecto a um objecto concreto, e os advices pertencentes a esse aspecto só são aplicados a esse objecto. O aspecto é declarado e associado com um pointcut e, é

132 117 criado uma instância do aspecto por cada objecto que o pointcut intercepta. É possível definir comportamento estático (exemplo 80) ou dinâmico (exemplo 81). aspect Id perthis(pointcut) {... Exemplo 80 Instancia de aspectos por objectos dinamicamente. aspect Id pertarget(pointcut) {... Exemplo 81 - Instancia de aspectos por objectos estaticamente Aspectos por fluxo. É possível criar um aspecto por cada fluxo do programa a partir de um determinado joinpoint. O aspecto é associado com um pointcut. Quando se verificar esse poincut são instanciados um aspecto por cada fluxo diferente que se crie a partir desse fluxo. Sintaxe para a declaração a partir de um determinado fluxo (exemplo 82). aspect NomeAspecto percflow(pointcut) {... Exemplo 82 Definir aspecto por fluxo. É possível omitir o primeiro fluxo que ocorre no joinpoint (exemplo 83). aspect NomeAspecto percflowbelow(pointcut) {... Exemplo 83 Definir aspecto por fluxo, excepto o inicial Aspectos com privilégios Para possibilitar o acesso aos vários tipos de modificadores, em especial a métodos e atributos declarados como private, é possível declarar aspectos privilegiados (exemplo 84). privileged aspect Id {... Exemplo 84 definir aspecto com privilégios.

133 118 No exemplo 85, é demonstrado o acesso de um aspecto a atributos declarados private. class C { private int i = 0; void inci(int x) { i = i+x; privileged aspect A { static final int MAX = 1000; before(int x, C c): call(void C.incI(int)) && target(c) && args(x) { if (c.i+x > MAX) throw new RuntimeException(); Exemplo 85 Exemplo de Aspecto privilegiado.

134 ANEXO Na versão 1.5 da linguagem de programação AspectJ foi introduzido um novo estilo de declarar aspectos, advices e pointcuts, mas mantendo a mesma semântica. A este estilo de desenvolvimento foi 35, este estilo é semelhante às anotações do Java 5 e parecido à aplicação de atributos da Framework.NET. Este estilo permite desenvolver aspectos como se de classes normais de Java se tratassem, que depois são anotadas, utilizando a semântica do AspectJ. Os métodos dessas classes quando anotados tornam-se Advices. Este estilo permite que se possa desenvolver programas POA sem alterar as ferramentas de desenvolvimento, mas é necessário incorporar manualmente o processo de Weaving no processo de compilação do projecto, através, por exemplo, de tarefas ANT 36. Se não existir integração do processo de compilação o projecto, o programa compilado tem o comportamento normal POO. 35 (Acedido em Junho de 2008) 36 (Acedido em Junho 2008)

135 120 Antes de se poder desenvolver programas POA neste estilo, é necessário primeiro instalar a linguagem AspectJ 37 e importar as bibliotecas, ficheiros jar, ao projecto Java. 7.2 DECLARAÇÃO DE ASPECTOS Para declarar um aspecto, é necessário primeiro criar uma classe. Nesta classe é necessário importar a anotação org.aspectj.lang.annotation.aspect, com esta importação é possível anotar a classe com a por cima do nome da (exemplo 86). A ferramenta de desenvolvimento, IDE, mesmo sem alterações reconhece a anotação, devido a importação da anotação, e consegue detectar erros de sintaxe. import public class NotVeryUsefulAspect { Exemplo 86 - declarar um aspecto 7.3 DECLARAÇÃO DE POINTCUTS Para declarar um pointcut, primeiro importa-se a anotação org.aspectj.lang.annotation.pointcut, que permite ao IDE reconhecer a anotação e ao programador utilizar a mesma. Dentro da classe anotada como aspecto declara-se um método como o bloco de código em branco. Anota-se esse método com a e as 37 (Acedido em Junho 2008)

136 121 condições do pointcut. A semântica é igual ao estilo previamente descrito no anexo 1 como é possível verificar no exemplo 87. import transfer(..))")// comportamento private void anyoldtransfer() {// assinatura Exemplo 87 Declaração de um Pointcut É possível combinar vários pointcuts num só utilizando a lógica booleana (exemplo * *(..))") private void anypublicoperation() private void intrading() && intrading()") private void tradingoperation() { Exemplo 88 junção de pointcuts 7.4 DECLARAÇÃO DE ADVICES Neste estilo os advices são implementados através de métodos, os quais são anotados com a devida sintaxe. Para definir advices primeiro é necessário importar as anotações referentes ao tipo de comportamento pretendido, antes (.Before), depois (.After,.AfterReturning ou.afterthrowing) ou invés de (.Around). Para anotar o método que vai implementar o comportamento transversal, utiliza-se a sintaxe já previamente introduzida (exemplo 89). import org.aspectj.lang.annotation.aspect; import public class BeforeExample {

137 dataaccessoperation(..))") public void doaccesscheck() { //... Exemplo 89 criação de um advice do tipo antes Para definir um advice que seja invocado depois (After), a forma de declaração é idêntica aos passos anteriores. Implementa-se o método que irá ser invocado depois e anota-se as condições para dar ocorrência do comportamento e não esquecendo importar primeiro a anotação (exemplo 90). import org.aspectj.lang.annotation.aspect; import public class AfterReturningExample public void doaccesscheck() { //... Exemplo 90 - criação de um advice do tipo depois Também é possível aceder ao argumento de saída (returning) pelo método alvo depois da sua execução (exemplo 91). import org.aspectj.lang.annotation.aspect; import public class AfterReturningExample pointcut="com.xyz.myapp.systemarchitecture.dataaccessoperation()", returning="retval") public void doaccesscheck(object retval) { //...

138 123 Exemplo 91 - criação de um advice do tipo depois com acesso a contexto. É possível utilizar o tipo de advice ao invés de (Around) que permite por exemplo executar código invés do código do método alvo. No exemplo 92, é utilizado o tipo de advice ao invés de, para executar tarefas antes do código do método alvo executar, efectuar a execução do código do método alvo (proceed), e no fim executar outras tarefas. import org.aspectj.lang.annotation.aspect; import org.aspectj.lang.annotation.around; import public class AroundExample (* businessservice())") public Object dobasicprofiling(proceedingjoinpoint pjp) throws Throwable { // iniciar contador Object retval = pjp.proceed(); // parar contador return retval; Exemplo 92 - criação de um advice do tipo invés 7.5 INTER-TYPE DECLARATIONS Inter-type declarations neste estilo sofre de algumas limitações pois não é possível introduzir atributos e construtores, já que não é possível invocá-los antes de estes estarem tricotados com o resto do código. A implementação recorre a Interfaces, a estrutura que se pretende introduzir é definida em classes e interfaces, e os métodos e atributos dessas classes e interfaces são introduzidos no programa definindo aspectos anotados.

139 124 Nos exemplos 93,94 e 95 é mostrado como se procede a alteração da estrutura de uma classe, primeiro é necessário criar uma interface (exemplo 93). Em seguido é necessário criar uma implementação da interface (exemplo 94). Cria-se um aspecto onde é necessário definir qual a classe que vai ser alterada, fornecendo a classe que implementa a interface (exemplo 95). // Interface public interface Moody { Mood getmood(); ; Exemplo 93 Interface que contem os métodos ou atributos a ser compostos. // Implementação da Interface public static class MoodyImpl implements Moody { private Mood mood = Mood.HAPPY; public Mood getmood() { return mood; Exemplo 94 Implementação da interface do exemplo 97. //Aspecto que compõem a public class MoodIndicator { // Introduzir a interface em private Moody implementedinterface; //Invocar a implementação da *.*(..)) && this(m)") void feelingmoody(moody m) { System.out.println("I'm feeling " + m.getmood()); Exemplo 95 Aspecto para modificar a estrutura de uma classe

140 ANEXO 3: IDES 8.1 FERRAMENTAS DE DESENVOLVIMENTO A linguagem de programação orientada a aspectos AspectJ pode ser adicionada a qualquer projecto em Java como uma biblioteca. São disponibilizados por essa biblioteca um conjunto de ferramentas para a compilação, depuração e documentação, alternativamente pode estar incluída num plug-in para IDE, como o plug-in AJDT para Eclipse. Este Plug-in para além de adicionar o suporte para a linguagem de programação facilita o seu desenvolvimento com ajudas visuais. 8.2 PLUG-IN AJDT O Plug-in AJDT 38 [Clement, Colyer et al. 2003] para a plataforma Eclipse, adiciona à plataforma de desenvolvimento o suporte necessário para o desenvolvimento orientado a aspectos utilizando a linguagem AspectJ, e um conjunto de ferramentas visuais, para ajudar o programador no desenvolvimento de aspectos. 38 (Acedido em Julho de 2008)

141 126 AJDT possui a vista cross reference cujas indicações visuais permitem visualmente perceber a interacção dos advices com o programa. A perspectiva visualizer que permite ver o efeito dos aspectos no sistema, e o depurador que permite depurar passo a passo programas AspectJ [Clement, Colyer et al. 2003]. Na figura 24, pode-se observar a perspectiva Java, do lado direito o package Explorer que contem os ficheiros java ordenados por package. Ao centro o editor dos ficheiros java, e do lado esquerdo a vista outline e debaixo desta a vista cross reference. De notar do lado esquerdo do editor existem pequenos ícones que denotam informação sobre advices aplicados. Figura 24 Eclipse, perspectiva Java Nas figuras 25, 26 apresenta-se a perspectiva visualizer, que permite ter a percepção global de como os vários aspectos afectam o sistema. Como se pode verificar cada aspecto tem

142 127 uma cor diferente, que é utilizada para indicar os pontos no sistema onde estão esses aspectos aplicados. Figura 25 - Eclipse, Perspectiva visualiser Figura 26 Detalhe visualiser. A vista cross reference (figura 27) permite visualizar onde os advices do aspecto estão a ser aplicados. Os nomes por baixo de advices são navegáveis, o utilizador ao carregar num dos

143 128 nomes listados é levado para o editor de texto na linha onde é aplicado o advice. Caso se esteja a editar uma classe que contenha locais onde são aplicados advices, na vista cross reference são mostrados esses advices, e clicando nos advices ao utilizador é mostrado o ficheiro na janela do editor de texto e na linha que contem esse advice. Figura 27 Detalhe de cross references. A depuração de programas AspectJ está integrada na plataforma, a perspectiva de depuração, figura 28, permite depurar passo a passo aspectos e código normal java. Figura 28 Perspectiva de depuração.

144 FERRAMENTAS STANDALONE DA BIBLIOTECA ASPECTJ As ferramentas incluídas com a biblioteca normal da linguagem de programação AspectJ são: Ajc: o compilador (weaver); Ajdoc: ferramenta para gerar a documentação; Ajbrowser: para visualizar a interligação dos aspectos com o sistema de software; Todos os parâmetros e configurações podem ser consultados online na página de ajuda do projecto AspectJ (Acedido em Junho 2008) (Acedido em Junho 2008)

145 ANEXO 4: POSTSHARP 9.1 INTERCEPÇÃO DE CHAMADAS A MÉTODOS A classe OnMethodBoundaryAspect, permite interceptar chamadas a métodos e definir comportamentos a entrada, saída, em caso de sucesso ou em caso que seja lançada uma excepção pelo método a que é aplicado o atributo. Este comportamento só é valido para os métodos dentro do contexto do tipo (classe) ao qual é aplicado o atributo. Os métodos da classe que permitem definir advices são apresentados na tabela 11. Método OnEntry OnSuccess OnException OnExit Tipo de Advice Entrada no método alvo. Execução do método alvo com sucesso. Método alvo lança uma excepção. Saída do método alvo. Tabela 11 Métodos da classe OnMethodBoundaryAspect. No exemplo 96, o atributo Trace estende a classe OnMethodBoundaryAspect e re- implementa os quatro métodos que definem os tipos de advice. class TraceAttribute: OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionEventArgs args) { //entrada no metodo public override void OnExit(MethodExecutionEventArgs args) {

146 131 //saida do metodo public override void OnSuccess(MethodExecutionEventArgs args) { //metodo executado com sucesso public override void OnException(MethodExecutionEventArgs args) { //metodo lançõu uma excepção Exemplo 96 Exemplo de um atributo Trace. 9.2 INTERCEPTAR INVOCAÇÃO A MÉTODOS A classe OnMethodInvocationAspect, contem um método que permite receber notificações de invocações a métodos que não estão no contexto da assembly, em que o atributo está associado. O nome do método do advice é OnInvocation. Os atributos podem ser aplicados no local onde os métodos são invocados. O único comportamento permitido é quando o método é invocado, isto é antes de o método alvo ser executado. No exemplo 97, mostra-se o código necessário para estender a classe. Este atributo deve ser aplicado a uma classe ou método que contenha a invocação ao método alvo. class TraceAttribute: OnMethodInvocationAspect { public override void OnInvocation(MethodInvocationEventArgs args) { //metodo foi invocado Exemplo 97 Exemplo de um atributo para invocação de métodos

147 INTERCEPTAR TRATAMENTO DE EXCEPÇÕES A classe OnExceptionAspect, fornece o advice que permite receber notificações no caso de lançamento de excepções. O método que define o advice é OnException (exemplo 98). class TraceAttribute: OnExceptionAspect { public override void OnException(MethodExecutionEventArgs args) { //Tratar a excepção Exemplo 98 - Exemplo de um atributo para tratar excepções. 9.4 INTERCEPTAR ACESSO A VARIÁVEIS Os métodos da classe OnFieldAccessAspect permitem interceptar acessos de leitura e escrita a variáveis. Os métodos que definem os advices são apresentados na tabela 12. Metodo OnGetValue SetValue Descrição do advice Notificação de quando o valor da variável é lido. Notificação de quando o valor da variável é escrito. Tabela 12 Métodos da classe OnFieldAccessAspect No exemplo 99, são implementados pelo atributo os métodos para a notificação da escrita e do acesso de leitura. O atributo deve ser atribuído a uma classe. class TraceAttribute: OnFieldAccessAspect { public override void OnGetValue(FieldAccessEventArgs eventargs) { //variavel foi acedida public override void OnSetValue(FieldAccessEventArgs eventargs) { //novo valor atribuido à variavel

148 133 Exemplo 99 exemplo de atributo de acesso a variáveis. 9.5 IMPLEMENTAÇÃO DE MÉTODOS A classe ImplementMethodAspect, permite implementar métodos abstractos ou extern, deferindo a execução desses métodos para o método OnExecution. O bloco de código que é executado é o que está definido no atributo. Se o atributo é aplicado a um método com um bloco de código, este código não irá ser executado. O comportamento é semelhante ao invés dos advices de AspectJ (exemplo 100). class TraceAttribute: ImplementMethodAspect { public override void OnExecution(MethodExecutionEventArgs args) { //implementação do método Exemplo 100 exemplo de um atributo para implementar um método. 9.6 IMPLEMENTAR E COMPOR INTERFACES A classe CompositionAspect, permite implementar uma interface e por composição aplica-la a numa classe. É necessário implementar a interface numa classe, separadamente, e em runtime devolver um objecto com a implementação da interface no método CreateImplementationObject. O PostSharp necessita que em tempo de execução lhe seja devolvido o tipo da interface que é implementada através do método GetPublicInterface.

149 134 No exemplo 101, são mostrados os dois métodos que são preciso implementar. class TraceAttribute : CompositionAspect { public override object CreateImplementationObject(InstanceBoundLaosEventArgs eventargs) { //devolver objecto contendo a implementação da interface public override Type GetPublicInterface(Type containertype) { //devolver que interface que é implementada Exemplo 101 exemplo de atributo para compor interfaces. 9.7 APLICAÇÃO DOS ATRIBUTOS A aplicação dos atributos é efectuada de igual forma que os atributos normais da plataforma.net, não existindo diferenças na atribuição dos atributos definidos pelos programadores. No exemplo 102, o atributo Trace é aplicado a uma classe, se por exemplo o aspecto implementado pelo atributo é do tipo chamadas a métodos, o aspecto captura todos os métodos desta classe. [Trace] class Program Exemplo 102 Aplicar atributo a uma classe. No exemplo 103, o atributo é aplicado a um só método [Trace] static void sayhello(string name) { Console.WriteLine("Hello, {0.", name); Exemplo 103 Aplicar atributo a um método. No exemplo 104, o atributo é aplicado a todos os métodos da classe, mas só aqueles que comecem pelas letras say. [Trace(AttributeTargetMembers="say*")]

150 135 class Program Exemplo 104 Aplicar atributo definindo a quais métodos. 9.8 ATRIBUIÇÃO A MÚLTIPLOS TIPOS. O PostSharp permite a atribuição de um atributo a múltiplos tipos, classes por exemplo, no exemplo 105, o atributo Log é aplicado a todo o Namespace BusinessObjects [assembly: Log(AttributeTargetTypes = " MyApp. BusinessObjects.*", AttributeTargetMemberAttributes = MulticastAttributes.Public)] Exemplo 105 Atribuição de um atributo a múltiplos tipos. 9.9 EXEMPLO DE UTILIZAÇÃO Para ilustrar uma utilização do PostSharp LAOS, desenvolvemos um projecto, que de forma simples permite imprimir uma mensagem antes e depois de um determinado método ser invocado, este tipo de comportamento é útil para fazer registos, segurança, transacções, anular e repor estados de objectos. Este exemplo está disponível em vídeo 41 na página oficial do PostSharp No Visual Studio 2005 cria-se um projecto C# do tipo Console Application (figura 29). 41 (Acedido em Junho 2008) 42 (Acedido em Junho 2008)

151 136 Figura 29 Visual Studio criar Projecto 2. Importar a referência das assemblies PostSharp.public e PostSharp.Laos para o projecto (figura 30). Ficando estas referencias associadas ao projecto (figura 31). Figura 30 - Visual Studio importar Referencias.

152 137 Figura 31 - Visual Studio, referencias no projecto. 3. Criar os atributos estendendo as classes fornecidas pelo Namespace PostSharp.Laos. Criando uma nova Classe, e estender essa classe da classe OnMethodBoundrayAspect e implementar os métodos necessários, no exemplo 106 são os métodos onentry e onexit. No exemplo também se utiliza o método CompileTimeInitialize para se obter o nome do método logo na fase de compilação evitando assim que em tempo de execução se tenha de calcular o nome do método. using System; using System.Collections.Generic; using System.Text; using PostSharp.Laos; namespace TraceSample { [Serializable] class TraceAttribute: OnMethodBoundaryAspect { string methodname; public override void CompileTimeInitialize(System.Reflection.MethodBase method) { this.methodname = method.declaringtype.name + "/" + method.name; public override void OnEntry(MethodExecutionEventArgs eventargs) { Console.WriteLine("On entry of {0.", this.methodname); public override void OnExit(MethodExecutionEventArgs eventargs)

153 138 { Console.WriteLine("On exit of {0.", this.methodname); Exemplo 106 Exemplo prático de um Atributo desenvolvido em PostSharp Laos. 4. Criados os atributos, estes agora precisam de ser aplicados aos métodos, existem várias formas de o fazer, no exemplo 107 é aplicado o atributo à classe e definido que só deve ser aos métodos dessa classe que comecem pelas palavras say. using System; using System.Collections.Generic; using System.Text; namespace TraceSample { [Trace(AttributeTargetMembers="say*")] class Program { static void Main(string[] args) { sayhello("world"); saygoodbye("world"); Console.ReadKey(); static void saygoodbye(string name) { Console.WriteLine("Good bye, {0.", name); static void sayhello(string name) { Console.WriteLine("Hello, {0.", name); Exemplo 107 Exemplo prático da aplicação de um Atributo. 5. Completada a implementação do código efectua-se a compilação. O processo de compilação do PostSharp é automaticamente inserido a quando da instalação no

154 139 processo de compilação do visual Studio O programador quando compila o programa pode verificar no output o resultado da compilação, exemplo Rebuild All started: Project: TraceSample, Configuration: Debug Any CPU. Compile complete -- 0 errors, 0 warnings PostSharp 1.0 [ ] - Copyright (c) Gael Fraiteur, TraceSample -> C:\...\bin\Debug\TraceSample.exe ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== Exemplo 108 Resultado do Weaving. 6. Completada a compilação o resultado da execução do programa é mostrado na figura 32. Figura 32 Resultado do programa de exemplo.

Aspect-Oriented Programming AOP. Comentários Sérgio Crespo

Aspect-Oriented Programming AOP. Comentários Sérgio Crespo Aspect-Oriented Programming AOP Comentários Sérgio Crespo Separation of Concerns O princípio de Separation of Concerns já é utilizado por engenheiros de software para o gerenciar a complexidade de sistemas

Leia mais

Separaçã. ção Multi-Dimensional de Interesses

Separaçã. ção Multi-Dimensional de Interesses OD 2002 Uma nova abordagem para modelagem de requisitos Separaçã ção Multi-Dimensional de Interesses Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos 1. Discutir as limitações existentes no

Leia mais

2 Desenvolvimento de Software Orientado a Aspectos

2 Desenvolvimento de Software Orientado a Aspectos 2 Desenvolvimento de Software Orientado a Aspectos Separação de concerns é um princípio bem estabelecido da engenharia de software que diz que, para se dominar a complexidade do desenvolvimento de software,

Leia mais

Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com

Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com Resumo: Demonstrar de forma clara e prática como a Programação Orientada a Aspectos pode ajudar a

Leia mais

Programação Orientada a Aspectos

Programação Orientada a Aspectos Programação Orientada a Aspectos Uma Breve Introdução Universidade Estadual do Oeste do Paraná Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Prof. Luiz Antonio Roteiro Introdução Evolução

Leia mais

Identificação de Interesses Transversais: Uma Visão Geral

Identificação de Interesses Transversais: Uma Visão Geral Identificação de Interesses Transversais: Uma Visão Geral Paulo Afonso Parreira Júnior paulojunior@jatai.ufg.br 24 de Maio de 2013 Agenda Breve Histórico sobre Desenvolvimento de Software Separação de

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

Programação Avançada

Programação Avançada Índice 1.1 - Introdução História A plataforma Java 1.2 - Conceitos Fundamentais na programação por objectos Objectos Encapsulamento Classes Herança Polimorfismo Interfaces Pacotes 1/24 1.1 Introdução 1.1

Leia mais

OUTROS PARADIGMAS: PROGRAMAÇÃO

OUTROS PARADIGMAS: PROGRAMAÇÃO OUTROS PARADIGMAS: PROGRAMAÇÃO CONCORRENTE, MODELO DE DADOS RELACIONAL (SQL), REDES DE PETRI, ORIENTAÇÃO A ASPECTOS Luenne Nailam e Uendson Teles PROGRAMAÇÃO CONCORRENTE PROGRAMA O que é um Programa? O

Leia mais

AspectJ em 20 minutos

AspectJ em 20 minutos AspectJ em 20 minutos Diogo Vinícius Winck (diogo.winck@gmail.com) Vicente Goetten (goetten@gmail.com) 1. Introdução A Orientação a Objetos está consolidada. Entretanto, nem todas as promessas que este

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

CAPITULO 1 - PROGRAMAÇÃO ORIENTADA A OBJETOS

CAPITULO 1 - PROGRAMAÇÃO ORIENTADA A OBJETOS 11 INTRODUÇÃO A programação orientada a objetos foi motivada devido a necessidade de desenvolvimento de software de qualidade, para uma maior reutilização e níveis de manutenção, e assim aumentar a produtividade

Leia mais

Introdução à Programação. Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR

Introdução à Programação. Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR Introdução à Programação Orientada a Objetos Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR Fev/2014 Histórico das linguagens de programação ENIAC (1944) Programação

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Desenho de Software. Desenho de Software 1

Desenho de Software. Desenho de Software 1 Desenho de Software Desenho de Software 1 Sumário Caracterização Conceitos fundamentais Desenho funcional e desenho OO Qualidades Desenho de Software 2 Bibliografia Pfleeger, Capítulo 6 Design the Modules

Leia mais

Paradigmas de Linguagens de Programação

Paradigmas de Linguagens de Programação Paradigmas de Linguagens de Programação Faculdade Nova Roma Cursos de Ciências da Computação (6 Período) Prof Adriano Avelar - Site: wwwadrianoavelarcom Email: edsonavelar@yahoocombr PROGRAMAÇÃO ORIENTADA

Leia mais

Programa Analítico. Introdução. Origens da programação Orientada a Objetos. Paradigma procedural. Paradigma Orientado a Objetos.

Programa Analítico. Introdução. Origens da programação Orientada a Objetos. Paradigma procedural. Paradigma Orientado a Objetos. Programação II Prof. Gustavo Willam Pereira e-mail: gustavowillam@gmail.com ENG10082 Programação II 1 Ementa Programação orientada a objetos: classes e objetos, atributos e métodos, especificadores de

Leia mais

Programação com Objectos. Processamento de Dados I. 3. UML (Unified Modeling Language)

Programação com Objectos. Processamento de Dados I. 3. UML (Unified Modeling Language) Programação com Objectos Processamento de Dados I 3. UML (Unified Modeling Language) 1 Modelo UML Diagrama de classes Programação com Objectos / Processamento de Dados I 2 Modelo O desenvolvimento de programas

Leia mais

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Baseado nos materiais dos profs: Prof.: Edilberto M. Silva http://www.edilms.eti.br Edna Canedo Marcio de Carvalho Victorino Brasília-DF,

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas)

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas) ENIAC Introdução aos Computadores e à ção (Noções Básicas) Introdução aos Computadores e à ção (Noções Básicas) 1 Introdução aos Computadores e à ção (Noções Básicas) 2 O transistor foi inventado em 1947

Leia mais

Bibliografia. Desenvolvimento Orientado a Objetos. Introdução. Bibliografia. O que você vê?

Bibliografia. Desenvolvimento Orientado a Objetos. Introdução. Bibliografia. O que você vê? Bibliografia Desenvolvimento Orientado a Objetos Prof.: Edson dos Santos Cordeiro LARMAN, Graig. Utilizando UML e padrões. Porto Alegre: Bookman, 2000. STAA, Arndt von. Programação modular. Rio de Janeiro:

Leia mais

7 Trabalhos Relacionados A idéia é tentar dar todas as informações que ajudem os outros a julgar o valor da sua contribuição; não apenas as informações que levem o julgamento a uma direção em particular.

Leia mais

UML Unified Modeling Language

UML Unified Modeling Language UML Unified Modeling Language Linguagem de Modelagem Unificada A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem para especificação, É uma linguagem para

Leia mais

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos Programação Estruturada e Orientada a Objetos Fundamentos Orientação a Objetos 2013 O que veremos hoje? Introdução aos fundamentos de Orientação a Objetos Transparências baseadas no material do Prof. Jailton

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

UML 01. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED UML 01 Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Referências BARBIERI, Carlos. Análise e Programação

Leia mais

Processo de análise estruturada - Abordagem clássica

Processo de análise estruturada - Abordagem clássica Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo

Leia mais

POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA

POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA Lincoln S. Rocha (lincoln@great.ufc.br) POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA Background Artigo do Kiczales 2 3 1 Objetivo da Programação?

Leia mais

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões

Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Capítulo 7 Linguateca e Processamento de Linguagem Natural na Área da Saúde: Alguns Comentários e Sugestões Liliana Ferreira, António Teixeira e João Paulo da Silva Cunha Luís Costa, Diana Santos e Nuno

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS. João Gabriel Ganem Barbosa

CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS. João Gabriel Ganem Barbosa CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS João Gabriel Ganem Barbosa Sumário Motivação História Linha do Tempo Divisão Conceitos Paradigmas Geração Tipos de Dados Operadores Estruturada vs

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 4 Estilos Arquitetônicos Estilos Arquiteturais Dataflow

Leia mais

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD) Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica,

Leia mais

PROGRAMAÇÃO JAVA. Parte 1

PROGRAMAÇÃO JAVA. Parte 1 PROGRAMAÇÃO JAVA Parte 1 O que é um programa? Um algoritmo (sequência de operações elementares - instruções) convertido para uma linguagem que possa ser executada por um computador Programa = Algoritmos

Leia mais

Elsa Cardoso, DCTI - ISCTE

Elsa Cardoso, DCTI - ISCTE Elsa Cardoso, DCTI - ISCTE 25 Maio 2004 elsa.cardoso@iscte.pt Sumário Perspectiva de Desenho do Sistema: Diagrama de classes numa perspectiva de Desenho: Estereótipos Relação de Dependência Relação de

Leia mais

Programação Orientada a Objetos

Programação Orientada a Objetos Programação Orientada a Objetos Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Introdução ao Paradigma OO

Leia mais

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008.

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. Common Object Request Broker Architecture [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. From: Fintan Bolton Pure CORBA SAMS, 2001 From: Coulouris, Dollimore and

Leia mais

Utilização da Metodologia de Desenvolvimento Orientado a Aspectos no Mercado Local

Utilização da Metodologia de Desenvolvimento Orientado a Aspectos no Mercado Local Universidade Federal de Pernambuco (UFPE) Centro de Informática (CIN) Mestrado Profissionalizante em Ciência da Computação Orientadora: Profª Carina Alves Utilização da Metodologia de Desenvolvimento Orientado

Leia mais

Tutorial de Programação Orientada a Objeto

Tutorial de Programação Orientada a Objeto Universidade Federal Fluminense Centro Tecnológico Escola de Engenharia Curso de Engenharia de Telecomunicações Programa de Educação Tutorial Grupo PET-Tele Tutorial de Programação Orientada a Objeto (Versão:

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Bases de Dados. Bibliografia. 1. Parte I Componente Teórica. Pedro Quaresma

Bases de Dados. Bibliografia. 1. Parte I Componente Teórica. Pedro Quaresma Índice Bases de Dados Pedro Quaresma Departamento de Matemática Universidade de Coimbra 2010/2011 1. Parte I Componente Teórica 1.1 Introdução 1.2 Modelo ER 1.3 Modelo Relacional 1.4 SQL 1.5 Integridade

Leia mais

Capítulo 8. Software de Sistema

Capítulo 8. Software de Sistema Capítulo 8 Software de Sistema Adaptado dos transparentes das autoras do livro The Essentials of Computer Organization and Architecture Objectivos Conhecer o ciclo de desenvolvimento da linguagem Java

Leia mais

Análise e Design OO com UML

Análise e Design OO com UML Análise e Design OO com UML Histórico de revisões Data Versão Descrição Autor 03/01/2015 1.3 Revisão e atualização HEngholmJr 24/12/2011 1.0 Criação da primeira versão HEngholmJr 9/1/2012 1.1 Correção

Leia mais

UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C#

UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C# UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C# Robson Bartelli¹, Wyllian Fressatti¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil robson_lpbartelli@yahoo.com.br,wyllian@unipar.br

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

Design Pattern Implementation in Java and AspectJ

Design Pattern Implementation in Java and AspectJ Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales In Proceedings of 2002 ACM SIGPLAN conference on OOPSLA. NY, USA. Introdução 2 Introdução 3 Introdução 4 Introdução 5 Introdução

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

Portal AEPQ Manual do utilizador

Portal AEPQ Manual do utilizador Pedro Gonçalves Luís Vieira Portal AEPQ Manual do utilizador Setembro 2008 Engenharia Informática - Portal AEPQ Manual do utilizador - ii - Conteúdo 1 Introdução... 1 1.1 Estrutura do manual... 3 1.2 Requisitos...

Leia mais

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos

SOFTWARE PROCESSES. Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos SOFTWARE PROCESSES Ian Sommerville, 8º edição Capítulo 4 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Introduzir modelos de processo de software Descrever uma variedade de modelos de processo

Leia mais

Introdução. Aulas. ltodi.est.ips.pt/es. Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas

Introdução. Aulas. ltodi.est.ips.pt/es. Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas Sumário Introdução Joaquim Filipe João Ascenso Engenharia de Software 2005/06 EST, Setúbal Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas 2

Leia mais

Unified Software Development Process

Unified Software Development Process 59/170 Unified Software Development Process Sumário Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unified Process) 60/170 Breve História do Unified

Leia mais

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos.

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. 1. Introdução aos Sistemas de Bases de Dados Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. O conceito de base de dados faz hoje parte do nosso

Leia mais

Introdução ao Projeto. Projeto de Software. 1) Objetivos. 2) Importância. Análise e Projeto - Diferenças. Importância. Silvia Regina Vergilio - UFPR

Introdução ao Projeto. Projeto de Software. 1) Objetivos. 2) Importância. Análise e Projeto - Diferenças. Importância. Silvia Regina Vergilio - UFPR Introdução ao Projeto Projeto de Software Silvia Regina Vergilio - UFPR 1. Objetivos 2. Importância 3. Fundamentos 4. O processo de projeto 5. Métodos de projeto 6. Analisando a estrutura do software 1)

Leia mais

Introdução ao Design

Introdução ao Design Introdução ao Design João Arthur e Guilherme Germoglio Coordenação de Pós-graduação em Informática - COPIN 16/10/2008 João Arthur e Guilherme Germoglio 1/ 33 Roteiro 1 Introdução Objetivos 2 Definições

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Departamento de Engenharia Informática DISTRIBUTED PROBLEM SOLVING

Departamento de Engenharia Informática DISTRIBUTED PROBLEM SOLVING Departamento de Engenharia Informática DISTRIBUTED PROBLEM SOLVING 1000833 Henrique de Meireles Morais Maio de 2008 Disciplina: Sistemas Baseados em Agentes Professor: António Pinto de Sousa e Silva Mestrado

Leia mais

Informática II Cap. 3

Informática II Cap. 3 Cap. 3 1 Tradicionalmente, programar significava apenas a escrita de um programa, que resolvesse o problema pretendido de uma forma aparentemente correcta. Problema Problema Programa Programa Desvantagens:

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS. Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms.

ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS. Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms. ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms. Mauricio Duarte 2 Centro Universitário Euripides de Marilia UNIVEM FATEC Faculdade de

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan

Leia mais

Instituto Superior Politécnico de VISEU. Escola Superior de Tecnologia

Instituto Superior Politécnico de VISEU. Escola Superior de Tecnologia 1 Tradicionalmente, programar significava apenas a escrita de um programa, que resolvesse o problema pretendido de uma forma aparentemente correcta. Problema Problema Programa Programa Desvantagens: Programas

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 RESUMO Atualmente o cenário mundial cuja dependência do software está cada vez mais evidente requer que

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Separação de Interesses Programação Estruturada e Programação Orientada a Objetos Entrelaçamento de Código Espalhamento de Código

Separação de Interesses Programação Estruturada e Programação Orientada a Objetos Entrelaçamento de Código Espalhamento de Código Análise e Projeto Orientados a Aspectos Alcides Pamplona alcides.pamplona@gmail.com Tópicos Separação de Interesses Programação Estruturada e Entrelaçamento de Código Espalhamento de Código 1 Separação

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2 Estrutura de Repetição. Ex. 2 A ESTRUTURA Enquanto faça{} É MELHOR UTILIZADA PARA SITUAÇÕES ONDE O TESTE DE CONDIÇÃO (V OU F) PRECISA SER VERIFICADO NO INÍCIO DA ESTRUTURA DE REPETIÇÃO.

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde Software Orientadaa Objetos com UML Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para

Leia mais

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

Framework utilizando reflexão e aspectos para persistência de objetos em java

Framework utilizando reflexão e aspectos para persistência de objetos em java Framework utilizando reflexão e aspectos para persistência de objetos em java Antonio Carlos Rolloff (UNIPAR) acrolloff@gmail.com Arthur Cattaneo Zavadski (UNIPAR) arthur@datacoper.com.br Maria Aparecida

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

WebSphere_Integration_Developer_D_Jan06 Script

WebSphere_Integration_Developer_D_Jan06 Script WebSphere_Integration_Developer_D_Jan06 Script 1a Nesta demonstração, Will Dunlop, um programador de integração da JK, utiliza o IBM, [ IBM], ou WID para construir um novo serviço orientado para os processos

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

Guião de Introdução ao Eclipse IDE Índice

Guião de Introdução ao Eclipse IDE Índice Índice 1. Introdução... 2 1.1. O que é um ambiente de desenvolvimento (IDE)?... 2 1.2. Visão geral sobre o Eclipse IDE... 2 2. Iniciar o Eclipse... 3 2.1. Instalação... 3 2.2. Utilizar o Eclipse... 3 3.

Leia mais

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 Segundo Exame 16 de Julho de 2010, 9:00H 11:30H (Versão A) Nome:

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

ELAINE DA SILVA MONTEIRO. Implementação de um Aplicativo Utilizando AODM, Java e AspectJ

ELAINE DA SILVA MONTEIRO. Implementação de um Aplicativo Utilizando AODM, Java e AspectJ ELAINE DA SILVA MONTEIRO Implementação de um Aplicativo Utilizando AODM, Java e AspectJ Palmas TO 2004 ii ELAINE DA SILVA MONTEIRO Implementação de um Aplicativo Utilizando AODM, Java e AspectJ Monografia

Leia mais

Programação I. Departamento de Engenharia Rural Centro de Ciências Agrárias

Programação I. Departamento de Engenharia Rural Centro de Ciências Agrárias Departamento de Engenharia Rural Centro de Ciências Agrárias Programação I Prof. Bruno Vilela Oliveira bruno@cca.ufes.br http://www.brunovilela.webnode.com.br Programas e Linguagens Para executar uma tarefa

Leia mais

USE CASES: continuação

USE CASES: continuação USE CASES: continuação Balcão de Companhia Aérea Fazer Check-in de Passageiro Funcionário Inserir Reserva de Voo Cancelar Reserva de Voo Os primeiros diagramas de Use Case (DUC) de um Sistema, descrevem

Leia mais