Uma abordagem modular para projeto de software orientado a aspectos

Texto

(1)Pós-Graduação em Ciência da Computação. “Uma abordagem modular para Projeto de Software Orientado a Aspectos” Por. Marcos Barbosa Dósea Dissertação de Mestrado. Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao. RECIFE,29 DE FEVEREIRO DE 2008.

(2) Dósea, Marcos Barbosa Uma abordagem modular para projeto de software orientado a aspectos / Marcos Barbosa Dósea. – Recife : O Autor, 2008. xiii, 90 folhas : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia e apêndices. 1. Engenharia de software. Título.. 005.1. CDD (22.ed.). MEI2008-047.

(3) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. MARCOS BARBOSA DÓSEA. “UMA ABORDAGEM MODULAR PARA PROJETO DE SOFTWARE ORIENTADO A ASPECTOS". ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. ORIENTADOR: DR. PAULO HENRIQUE MONTEIRO BORBA CO-ORIENTADOR: DR SÉRGIO C. B. SOARES. RECIFE, 29 DE FEVEREIRO DE 2008.

(4)

(5) AGRADECIMENTOS Ao meu orientador, Prof. Paulo Borba, que mesmo no meio de tantas tarefas, sempre encontrava tempo para me ajudar com muita paciência e dedica¸cão na confeçcão deste projeto. Ao meu co-orientador, Prof. Sérgio Soares, pela disponibilidade e confian¸ca depositada nos vários trabalhos que me deu oportunidade de participar. Ao amigo e companheiro de trabalho Alberto Costa Neto, pela grande contribui¸cão neste trabalho e significativas discussões. Aos amigos do SPG e de apartamento, pelas contribui¸co˜es, discussões, companheirismo e amizade. A minha noiva Elielma, pelo amor, carinho e paciência nos momentos mais dif´ıceis. Aos meus pais, Messias e Maria, pela paciência, apoio e pelo exemplo que são em minha vida. A Deus, meu grande companheiro e amigo durante todo o tempo.. iii.

(6)

(7) RESUMO O projeto de software visa descrever os principais aspectos do sistema a ser constru´ıdo através de mecanismos que ajudam a raciocinar sobre a complexidade. Dentre as atividades do projeto de software, destaca-se a elabora¸cão e documenta¸caõ da arquitetura, um dos principais mecanismos para raciocinar e lidar com essa complexidade. Uma das principais metas do projeto da arquitetura é a modulariza¸caõ do sistema através do estabelecimento de design rules que deverão ser obedecidas pelos desenvolvedores. Exemplos de design rules estabelecidas no projeto da arquitetura são os servi¸cos disponibilizados pelos componentes e as regras de comunica¸caõ entre estes. A modulariza¸caõ dos sistemas de software também motivou o surgimento da Programa¸cão Orientada a Aspectos (POA). Entretanto estudos recentes mostraram que a utiliza¸cão da POA apesar de ser um meio efetivo para modulariza¸caõ de interesses transversais, pode prejudicar a modularidade dos demais interesses se design rules não forem estabelecidas pelo projetista. Muitas das design rules necessárias para melhorar a modularidade de sistemas orientados a aspectos são definidas na fase de projeto da arquitetura do software. Para cria¸caõ e documenta¸cão do projeto da arquitetura uma das principais abordagens é a utiliza¸caõ de Linguagens de Descri¸caõ de Arquitetura (LDA), que permitem descrever a arquitetura de forma clara e não amb´ıgua, possibilitando a verifica¸cão de uma série de propriedades que antes só poderiam ser analisadas depois do implementa¸caõ do software. O problema na utiliza¸caõ desta abordagem é que o modelo de arquitetura utilizado pela maioria das LDAs, formado por abstra¸co˜es como componentes e conectores, é diferente do modelo baseado em objetos utilizado por muitas linguagens de programa¸cão, tornado dif´ıcil o mapeamento e a consistência entre essas fases do desenvolvimento. Entretanto, para garantir a modularidade do sistema e as propriedades arquiteturais obtidas através de uma LDA, é necessário apenas garantir que as design rules estabelecidas por esta são obedecidas pelo código desenvolvido. Neste trabalho propomos um mapeamento das design rules implicitamente definidas por uma linguagem de descri¸cão arquitetural para uma linguagem de descri¸caõ de design rules, responsável por verificar se estas estão sendo obedecidas no código desenvolvido. A verifica¸cão das design rules permite garantir que a modularidade e as propriedades arquiteturais obtidas através do projeto da arquitetura sejam válidas no código desenvolvido. A LDA escolhida foi a linguagem AspectualAcme, que utiliza os conceitos da orienta¸cão a aspectos, permitindo que as design rules geradas melhorem também a modularidade de sistemas orientados a aspectos. Para diminuir os custos com a tradu¸cão, também foi constru´ıda uma ferramenta capaz de gerar automaticamente, a partir de uma especifica¸cão válida em AspectualAcme, as regras na linguagem de descri¸caõ de design rules. Além da economia de tempo dos v.

(8) vi. RESUMO. desenvolvedores, o suporte automático para tradu¸caõ evita que erros sejam cometidos ou que design rules sejam esquecidas, garantindo dessa forma as propriedades verificadas no modelo arquitetura e a modularidade do sistema. Palavras-chave: AspectualAcme, Mapeamento entre Modelos, Linguagem de Descri¸cão de Design Rules, Projeto Modular.

(9) ABSTRACT Software design aims at describing the main aspects of a system through mechanisms that help to reason about complexity. When considering the software design activities, elaborating and documenting the architecture are essential activities to deal with such complexity. Architectural design aims at modularizing the system by establishing design rules that must be obeyed by the developers. Available component services and the communication rules among them are examples of such design rules. Aspect-Oriented Programming (AOP) has been proposed to improve the modularity of software systems. However, recent work has showed that, despite the modularization of crosscutting concerns supported by AOP, it may also break the modularity of other concerns if no design rules are established by the designer. Many required design rules to improve aspect-oriented systems’ modularity are specified at the architectural design phase. An existing approach for creating and documenting the architectural design is to employ Architecture Description Languages (ADLs), which allow designers to describe the architecture clearly and without ambiguities. This way, it is possible to verify properties that would be only possible to analyze after the software is implementated. The problem with this approach is that the architecture model - which consists of abstractions such as components and connectors - used by the majority of ADLs is different from the models based on objects used by the majority of programming languages. Threrefore, it is hard to map these development phases consistently. Nevertheless, in order to guarantee the modularity of the system and the architectural properties obtained through the use of an ADL, it is necessary to guarantee that the design rules established by the ADL are obeyed in the implemented code. In this work, we propose a set of mappings to translate design rules defined by an ADL to a language of design rules, responsible for verifying if these rules are obeyed at the source code level. Such verification may guarantee that both modularity and architectural properties obtained by the architecture design are valid in the implemented source code. In this context, we choose the AspectualAcme ADL, which uses aspect-oriented concepts, allowing the generated design rules to improve the modularity of aspect-oriented systems. To reduce the translation costs, we have also implemented a tool to automatically generate rules in a description language of design rules from a valid specification in AspectualAcme. Besides reducing the developers’ effort and the time required to perform the translation, supporting automated translation may avoid errors. In addition, the design rules are never forgotten, guaranteeing the verified properties of the architectural model and the system’s modularity. Keywords: Models Translation, Design Rules Description Language, Modular Design vii.

(10)

(11) ´ SUMARIO. ˜ Cap´ıtulo 1—INTRODUC ¸ AO 1.1 1.2 1.3 1.4. O Problema . . . Solu¸caõ Proposta Contribui¸cões . . Organiza¸caõ desse. . . . . . . . . . . . . . . . . . . Trabalho. 1 . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Cap´ıtulo 2—Projeto de Arquitetura de Software Orientado a Aspectos 2.1 2.2 2.3. 2.4. Programa¸caõ Orientada a Aspectos . . . Projeto de Software . . . . . . . . . . . . Projeto de Arquitetura de Software . . . 2.3.1 Estilos Arquiteturais . . . . . . . 2.3.1.1 Pipes e Filtros . . . . . 2.3.1.2 Camadas . . . . . . . . 2.3.1.3 Objetos . . . . . . . . . 2.3.1.4 Invoca¸cão Impl´ıcita . . . 2.3.1.5 Quadro-Negro . . . . . . 2.3.1.6 Cliente-Servidor . . . . Linguagens de Descri¸cão de Arquitetura 2.4.1 ACME . . . . . . . . . . . . . . . 2.4.2 AspectualAcme . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 5 . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. Cap´ıtulo 3—A Linguagem de Especifica¸c˜ ao de Design Rules 3.1 3.2. 3.3. O Problema de Modularidade em Sistemas Orientado a Aspectos . A Linguagem para Especifica¸caõ de Design Rules . . . . . . . . . 3.2.1 Structural Rules . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Behavioral Rules . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Módulo de Configura¸cão . . . . . . . . . . . . . . . . . . . 3.2.4 Parametriza¸caõ . . . . . . . . . . . . . . . . . . . . . . . . O Exemplo Display Update . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. As Regras de Tradu¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix. 5 9 10 12 13 13 14 14 14 15 15 17 20 23. Cap´ıtulo 4—Regras de Tradu¸c˜ ao de AspectualAcme para Design Rules 4.1. 2 2 3 3. 23 25 26 27 29 30 31 37 37 38 38.

(12) ´ SUMARIO. x 4.1.3 4.1.4 4.1.5. 4.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectors, Roles e Attachments . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.5.1 A Propriedade Provided . . . . . . . . . . . . . . . . . . 4.1.5.2 A Propriedade Provides . . . . . . . . . . . . . . . . . . 4.1.5.3 A Propriedade Required . . . . . . . . . . . . . . . . . . 4.1.5.4 A Propriedade Requires . . . . . . . . . . . . . . . . . . 4.1.6 Aspectual Connectors, Base Roles, Crosscutting Roles e Attachments 4.1.7 Representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . O Tradutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Cap´ıtulo 5—Avalia¸c˜ ao 5.1 5.2 5.3. 57. Critérios de Avalia¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cenário 1: Arquitetura do Compilador . . . . . . . . . . . . . . . . . . . Cenário 2: A Arquitetura do Sistema Health Watcher . . . . . . . . . . .. Cap´ıtulo 6—Conclus˜ oes 6.1. 6.2. Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . 6.1.1 Mapeamento de AspectualAcme para aSideUML . 6.1.2 Mapeamento de AspectualAcme para UML 2.0 . 6.1.3 Op¸co˜es de Mapeamento de Acme para UML . . . 6.1.4 ArchJava . . . . . . . . . . . . . . . . . . . . . . Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . .. 39 40 42 43 43 44 48 49 52 54. 57 57 63 69. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 70 70 71 72 72 73. Apˆ endice A—Especifica¸c˜ ao em AspectualAcme do Sistema Health Watcher com Persistence Modelado como Interesse Transversal 75 Apˆ endice B—Especifica¸c˜ ao em AspectualAcme do Sistema Health Watcher com Persistence e Distribution Modelados como Crosscutting Concerns 79.

(13) LISTA DE FIGURAS. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12. Exemplos de Interesses num Sistema de Software [Lad03]. . . . . . Combina¸cão Aspectual no Sistema Orientado a Aspectos [GW06]. Principais Artefatos do Projeto de Software. . . . . . . . . . . . . Combina¸cão aspectual no sistema orientado a aspectos. . . . . . . Arquitetura do Compilador. . . . . . . . . . . . . . . . . . . . . . Arquitetura de de Internet TCP/IP. . . . . . . . . . . . . . . . . . Visão Componente e Conector [GMW97]. . . . . . . . . . . . . . . Visão Componente e Conector. . . . . . . . . . . . . . . . . . . . Ferramenta AcmeStudio. . . . . . . . . . . . . . . . . . . . . . . . Composisão Aspectual. . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Aspectual Connector. . . . . . . . . . . . . . . . . . . Exemplo de Composi¸caõ em AspectualAcme com Quantifica¸caõ. .. 3.1 3.2. Desenvolvedores de Classes e Aspectos usando Design Rules. . . . . . . . 24 Meta-Modelos do Linguagem de Design Rules e do Módulo de Configura¸caõ 26. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10. Exemplo de Tradu¸caõ de um System para sua Design Rule . . . . . . . . Regra de Tradu¸caõ de System para Design Rule . . . . . . . . . . . . . . Exemplo de Tradu¸caõ de Components para sua Design Rule . . . . . . . Regra de Tradu¸caõ de Component para sua Respectiva Design Rule . . . Exemplo de Tradu¸caõ de Ports para sua Design Rule . . . . . . . . . . . Regra de Tradu¸caõ de Port para sua Respectiva Design Rule . . . . . . . Exemplo de Tradu¸caõ de Connectors e Rules para sua Design Rule . . . Regra de Tradu¸caõ de Connectors e Rules para sua Respectiva Design Rule Exemplo de Tradu¸caõ da Propriedade provided para sua Design Rule . . Regra de Tradu¸caõ quando a Propriedade provided é Utilizada em Apenas uma das Portas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Tradu¸caõ da Propriedade Provides para sua Respectiva Design Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regra de Tradu¸caõ quando a Propriedade provides é Utilizada em Apenas uma das Portas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Tradu¸caõ das Propriedades required e provided para a Design Rule Correspondente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regra de Tradu¸caõ das Propriedades required e provided para a Design Rule Correspondente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Tradu¸caõ das Propriedades required e provides para a Design Rule Correspondente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.11 4.12 4.13 4.14 4.15. xi. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 6 7 9 11 13 14 16 19 20 21 21 22. 38 38 39 39 40 40 41 42 43 44 45 45 46 47 47.

(14) xii. LISTA DE FIGURAS 4.16 Regra de Tradu¸caõ das Propriedades required e provides para a Design Rule Correspondente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.17 Exemplo de Tradu¸cão da Propriedade requires para sua Design Rule . . . 4.18 Regra de Tradu¸cão da Propriedade requires para sua Design Rule . . . . 4.19 Exemplo de Tradu¸caõ de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Design Rule Correspondente . . . . . . . . . . . . . . . . 4.20 Regra de Tradu¸caõ de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Respectiva Design Rule com a Propriedade provided . . . 4.21 Regra de Tradu¸caõ de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Respectiva Design Rule com a Propriedade required . . . 4.22 Exemplo de Tradu¸cão de Component com Representation para sua Design Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.23 Regra de Tradu¸caõ de Component com Representation para sua Respectiva Design Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24 Funcionamento do Tradutor . . . . . . . . . . . . . . . . . . . . . . . . . 4.25 Componentes do Tradutor . . . . . . . . . . . . . . . . . . . . . . . . . . 4.26 Funcionamento do Tradutor . . . . . . . . . . . . . . . . . . . . . . . . .. 48 49 50 50 51 52 53 54 55 55 56. 5.1 5.2 5.3. Arquitetura do Compilador [Men02]. . . . . . . . . . . . . . . . . . . . . 58 + Arquitetura do Health Watcher com o Interesse Transversal Persistence [BCG 06]. 64 Arquitetura do Health Watcher com o interesse transversal Persistence e Distribution [BCG+ 06]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67. 6.1. Exemplo de Mapeamento de uma Especifica¸caõ AspectualAcme para aSideUML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitetura do Sistema Health Watcher usando a Extensão da UML 2.0.. 6.2. 70 71.

(15) LISTA DE TABELAS. 3.1. Behavioral Rules providas pela linguagem de especifica¸caõ de design rules.. xiii. 28.

(16)

(17) CAPÍTULO 1. ˜ INTRODUC ¸ AO A complexidade e o custo envolvidos no projeto e desenvolvimento de software aumentou muito nas u ´ltimas quatro décadas, fazendo com que um projeto bem elaborado tivesse cada vez mais importância. O projeto de software visa descrever os principais aspectos do sistema a ser constru´ıdo obtendo modelos que irão oferecer diferentes visões aos desenvolvedores. Dentre as atividades do projeto de software destacam-se a elabora¸cão e documenta¸caõ da arquitetura como uma dos principais mecanismos para raciocinar e lidar com a complexidade. A arquitetura do software corresponde às estruturas do sistema, que abrangem os componentes de software, as propriedades externas vis´ıveis a esses componentes e os relacionamentos entre estes [BCK03]. O projeto da arquitetura é importante por facilitar a comunica¸cão entre os desenvolvedores, documentar as decisões desde as fases iniciais do projeto, habilitar o efetivo particionamento e o desenvolvimento paralelo, além de constituir um modelo de como o sistema é estruturado que pode ser reutilizado por outros sistemas. O projeto da arquitetura visa, entre outras coisas, alcan¸car o que normalmente é considerado um dos principais atributos de qualidade de um sistema de software: a modularidade. Encontrar nota¸cões que pudessem documentar a arquitetura de forma não-amb´ıgua e onde fosse poss´ıvel raciocinar sobre as propriedades desta tornou-se um grande desafio. Trabalhos iniciais usavam nota¸cões visuais baseadas em objetos onde os componentes eram representados por classes e as intera¸co˜es entre esses componentes por associa¸cões. Apesar de vantajosa pela familiaridade da nota¸caõ, essa abordagem dificultava a caracteriza¸cão e análise de propriedades cr´ıticas dos sistemas, como por exemplo, performance e disponibilidade. Uma alternativa para a solu¸caõ desse problema foi a utiliza¸cão de Linguagens de Descri¸c˜ ao de Arquitetura (LDA) [MT00] que permitem aos engenheiros raciocinar sobre a arquitetura e suas propriedades num alto n´ıvel de abstra¸cão. Não existe um consenso na comunidade cient´ıfica sobre as caracter´ısticas que uma LDA deve possuir, entretanto é quase unanimidade entre as LDAs a utiliza¸caõ do modelo de componentes e conectores para descri¸cão da arquitetura. A melhoria da modularidade dos sistemas também motivou o surgimento da Programa¸cão Orientada a Aspectos (POA) [KLM+ 97]. A POA cria uma nova abstra¸cão denominada aspecto, cujo principal objetivo é modularizar certos interesses, denominados interesses transversais, que ficam espalhados e entrela¸cados pelo código. Entretanto, estudos recentes [SGCH01, SGS+ 05, GSS+ 06, RDB+ 07] mostraram que a utiliza¸caõ da POA apesar de ser um meio efetivo para modulariza¸caõ dos interesses transversais, pode prejudicar a modularidade dos demais interesses, exigindo aten¸caõ a forma como aspectos e código base interagem. Um mecanismo para lidar com esse problema é o estabelecimento de um conjunto de regras, denominadas design rules [BC00], pelo projetista do 1.

(18) ˜ INTRODUC ¸ AO. 2. sistema. Muitas dessas design rules necessárias para garantir a modularidade de sistemas orientados a aspectos são definidas na fase de projeto de software, mais especificamente no projeto da arquitetura do software. 1.1. O PROBLEMA. O uso de linguagens de descri¸cão de arquitetura permite descrever a arquitetura de forma clara e não-amb´ıgua, possibilitando a verifica¸cão de uma série de propriedades que antes só poderiam ser analisadas depois da implementa¸cão do software. Essas linguagens estabelecem um importante conjunto de design rules, necessárias para garantir as propriedades verificadas no modelo de arquitetura e a modularidade do sistema. Entretanto, o modelo de arquitetura utilizado pela maioria das linguagens de descri¸caõ de arquitetura, formado por abstra¸co˜es como componentes e conectores, é diferente do modelo baseado em objetos utilizado pelas maioria das linguagens de programa¸cão e de descri¸cão do projeto onde, por exemplo, não existe a abstra¸caõ de conector. Outro problema é que as abstra¸cões utilizadas pelas LDAs podem ser implementadas de diferentes formas na fase de implementa¸caõ, por exemplo, um componente no modelo de arquitetura pode gerar várias classes no modelo de implementa¸cão orientado a objetos, dificultando o mapeamento entre esses modelos. Entretanto, para garantir a validade das propriedades verificadas no modelo de arquitetura e a modularidade do sistema, as design rules estabelecidas pelo modelo de arquitetura precisam ser obedecidas tanto no modelo de projeto quanto no modelo de implementa¸caõ. Ambos refinam o modelo de arquitetura adicionando novas design rules. Para expressar de forma não-amb´ıgua as design rules estabelecidas pelo projetista, foi proposta em um trabalho anterior uma linguagem para descri¸cão de design rules [DNBS07]. Além das design rules arquiteturais, a linguagem permite descrever outras design rules definidas em outras fases do projeto do software. Através de uma ferramenta de verifica¸caõ é poss´ıvel determinar se as design rules descritas pela linguagem estão sendo obedecidas pelo código desenvolvido. A utiliza¸caõ da linguagem torna-se um meio efetivo para verificar se as design rules estabelecidas no modelo de arquitetura são obedecidas na fase de implementa¸cão. Entretanto, não existe um mapeamento expl´ıcito e não-amb´ıguo entre o modelo de arquitetura, utilizado pelas LDAs, e a linguagem de descri¸caõ design rules. Isso possibilita que design rules sejam esquecidas ou ainda mal interpretadas, comprometendo a validade das propriedades verificadas no modelo de arquitetura e a modularidade do sistema. Além disso, a inexistência de regras expl´ıcitas para o mapeamento impossibilita a cria¸caõ de mecanismos automáticos que permitam automatizar esse processo. 1.2. ˜ PROPOSTA SOLUC ¸ AO. Este trabalho define um mapeamento que traduz as design rules implicitamente definidas por uma linguagem de descri¸caõ arquitetural para a linguagem de descri¸cão de design rules. A linguagem arquitetural escolhida foi a linguagem AspectualAcme [BCG+ 06], por ser uma linguagem simples, genérica e que utiliza os conceitos da orienta¸cão a aspectos.

(19) ˜ 1.3 CONTRIBUIC ¸ OES. 3. para melhorar a modulariza¸cão dos interesses transversais. A utiliza¸caõ de uma LDA orientada a aspectos permite que as design rules geradas melhorem a modularidade dos sistemas orientados a aspectos. As regras impl´ıcitas para gera¸cão das design rules foram extra´ıdas da linguagem AspectualAcme observando-se basicamente a semântica das constru¸cões dessa linguagem. Para diminuir os custos com a tradu¸cão, construiu-se uma ferramenta capaz de gerar automaticamente, a partir de uma especifica¸cão válida em AspectualAcme, as regras na linguagem de descri¸caõ de design rules. Além da economia de tempo dos desenvolvedores, o suporte automático para tradu¸caõ evita que erros sejam cometidos ou que design rules sejam esquecidas, garantindo dessa forma as propriedades verificadas no modelo de arquitetura e melhorando a modularidade do sistema. 1.3. ˜ CONTRIBUIC ¸ OES. As principais contribui¸co˜es desse trabalho são: • Um mapeamento entre as design rules expressas na linguagem de descri¸caõ de arquitetura AspectualAcme para a linguagem de descri¸caõ de design rules. • A cria¸caõ de suporte automático para traduzir especifica¸co˜es entre a linguagem de descri¸caõ arquitetural AspectualAcme e a linguagem de descri¸cão de design rules. • A avalia¸caõ da proposta utilizando cenários de arquiteturas clássicas apresentadas na literatura. 1.4. ˜ DESSE TRABALHO ORGANIZAC ¸ AO. Neste Cap´ıtulo foi apresentada uma introdu¸cão ao problema abordado neste trabalho e um resumo das principais contribui¸co˜es. No Cap´ıtulo 2 é discutida a importância da arquitetura de software no contexto do projeto de software orientado a aspectos e são apresentados diversos conceitos sobre descri¸cão de arquiteturas e algumas linguagens de descri¸caõ arquitetural. A linguagem Acme e sua extensão AspectualAcme também são apresentadas em detalhes nesse cap´ıtulo. Para descrever de forma não amb´ıgua o conjunto de design rules necessárias para modularizar um sistema orientado a aspectos no Cap´ıtulo 3 é apresentada a linguagem para descri¸cão de design rules. Nesse cap´ıtulo são discutidos os problemas de modularidade existentes em sistemas orientado a aspectos, as principais constru¸co˜es da linguagem e um exemplo de como a linguagem poderia ser utilizada para melhorar a modularidade. As regras de transforma¸co˜es entre o modelo de arquitetura descritas através da linguagem AspectualAcme e a linguagem de design rules são apresentadas no Cap´ıtulo 4. Nesse cap´ıtulo são discutidas ainda a arquitetura e a implementa¸cão da ferramenta constru´ıda para provê o suporte automático para essas transforma¸co˜es. No Cap´ıtulo 5 a abordagem proposta é avaliada. São utilizados exemplos de estilos arquiteturais clássicos e também sistemas reais para mostrar como as design rules presentes na especifica¸caõ desses sistemas em AspectualAcme são geradas automaticamente para a linguagem de design rules..

(20) 4. ˜ INTRODUC ¸ AO. Finalmente, no Cap´ıtulo 6 são apresentadas as conclusões, os principais trabalhos relacionados e alguns trabalhos futuros. Com rela¸caõ ao padrão de escrita, foram adotadas as seguintes conven¸co˜es: • Fontes em itálico são utilizadas para representar termos em l´ınguas estrangeiras e palavras ou expressões com ênfase; • A fonte Courier New é utilizada na representa¸caõ do código fonte e termos que representam tipos e constru¸cões de linguagens de programa¸caõ..

(21) CAPÍTULO 2. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. O Desenvolvimento de Software Orientado a Aspectos (DSOA) [FF05] é uma nova abordagem que vem se destacando para resolver problemas de outras abordagens, entre elas a programa¸cão orientada a objetos, provendo suporte sistemático para identifica¸caõ, modulariza¸cão, e composi¸cão de interesses transversais através de todo ciclo de vida do software. No n´ıvel do projeto da arquitetura, um interesse transversal pode ser qualquer interesse que não pode ser efetivamente modularizado com as abstra¸co˜es providas para esta tarefa. Dentre as várias formas de cria¸cão do projeto arquitetural, destaca-se a utiliza¸caõ de Linguagens de Descri¸cão de Arquitetura (LDA) [MT00] como mecanismo para a descri¸cão não-amb´ıgua da arquitetura. Através do emprego dessas linguagens, propriedades inerentes à arquitetura, como desempenho e disponibilidade, podem ser analisadas antes da implementa¸caõ concreta do software. Recentemente algumas LDAs vem propondo mecanismos para modelagem de interesses transversais. Neste cap´ıtulo são descritos os principais conceitos referentes à programa¸caõ orientada à aspectos e em seguida é discutido como esta vem influenciando as técnicas para o projeto de arquitetura de software. Ainda nesse cap´ıtulo são apresentadas em detalhes as linguagens de descri¸caõ de arquitetura Acme e sua extensão orientada a aspectos AspectualAcme. 2.1. ˜ ORIENTADA A ASPECTOS PROGRAMAC ¸ AO. A programa¸cão orientada a aspectos (POA)[KLM+ 97] foi criada com o objetivo de separar os interesses centrais dos interesses transversais, de uma forma bem definida e centralizada, possibilitando um n´ıvel maior de abstra¸caõ e uma separa¸cão bem definida de cada um dos componentes. Um interesse é um requisito espec´ıfico ou uma considera¸caõ que deve ser tratada para satisfazer os objetivos do sistema. Um sistema de software é composto por um conjunto de interesses. Na Figura 2.1 temos exemplos de três interesses: Business logic é um exemplo de interesse não-transversal por capturar a funcionalidade principal do módulo e Persistence e Logging são exemplos de interesses transversais por capturar requisitos que podem se espalhar em m´ ultiplos módulos. A identifica¸cão de cada um desses interesses permite focar em cada um separadamente, reduzindo a complexidade e aumentando as possibilidades de reuso. Segundo Goetten [GW06] a orienta¸caõ a aspectos possui quatro conceitos fundamentais: 5.

(22) 6. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. Figura 2.1 Exemplos de Interesses num Sistema de Software [Lad03].. • pontos de jun¸c˜ ao: são locais bem definidos na execu¸caõ de um programa, como por exemplo, a chamada a um método ou a ocorrência de uma exce¸cão. Todos os pontos de jun¸caõ possuem um contexto associado, por exemplo, durante a chamada de um método o objeto chamador, o objeto alvo e os argumentos estão dispon´ıveis no contexto. • conjuntos de pontos de jun¸c˜ ao: são elementos do programa usados para definir um ponto de jun¸caõ, através da cria¸caõ de regras genéricas que definem quais os eventos serão considerados pontos de jun¸caõ, sem precisar defini-los individualmente. • adendos: são partes da implementa¸caõ de um aspecto executados em pontos bem definidos do programa principal. São compostos por duas partes: a primeira define o conjunto de pontos de jun¸cão que define as regras de captura dos pontos de jun¸caõ; a segunda é o código que será executado quando ocorrer um ponto de jun¸caõ definido pela primeira parte. • aspecto: é um mecanismo disponibilizado para agrupar fragmentos de código referentes aos interesses transversais em uma unidade do sistema, evitando código espalhado e entrela¸cado. Dessa forma, os aspectos não podem existir sozinhos. Eles precisam das classes onde são implementados os interesses centrais. A combina¸cão aspectual é o processo responsável por combinar os elementos escritos em linguagem de componentes, na qual as classes do sistema são escritas, com os elementos escritos em linguagem de aspectos. As classes referentes aos interesses nãotransversais não sofrem qualquer altera¸caõ para dar suportar à programa¸caõ orientada a aspectos. A Figura 2.2 demonstra o processo de combina¸caõ aspectual onde os interesses centrais escritos numa linguagem de componentes são combinados com os interesses transversais.

(23) ˜ ORIENTADA A ASPECTOS 2.1 PROGRAMAC ¸ AO. 7. Figura 2.2 Combina¸cão Aspectual no Sistema Orientado a Aspectos [GW06].. escritos numa linguagem de aspectos. Como sa´ıda obtém-se o código combinado entre programas escritos em linguagem de componentes e programas escritos em linguagem de aspectos. Atualmente uma das linguagens de aspectos mais popular é o AspectJ [Tea07], uma extensão da linguagem Java que implementa os conceitos da orienta¸caõ a aspectos citados anteriormente. Para exemplificar os conceitos apresentados, utilizaremos um pequeno exemplo que modulariza o interesses transversal de gerenciamento de transa¸co˜es de um sistema. Listing 2.1 Facade OO 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23. public c l a s s Facade { public void i n s e r t ( Employee employee ) { try { getPm ( ) . b e g i n T r a n s a c t i o n ( ) ; employeeRecord . i n s e r t ( employee ) ; getPm ( ) . co mm itT ra n sa ctio n ( ) ; } catch ( E x c e p t i o n e ) { getPm ( ) . r o l l b a c k T r a n s a c t i o n ( ) ; } } public void update ( Employee employee ) { try { getPm ( ) . b e g i n T r a n s a c t i o n ( ) ; employeeRecord . update ( employee ) ; getPm ( ) . co mm it Tra nsa ct io n ( ) ; } catch ( E x c e p t i o n e ) { getPm ( ) . r o l l b a c k T r a n s a c t i o n ( ) ; } } ... }. Na Listagem 2.1 temos um fragmento de código de uma fachada onde alguns dos seus métodos precisam realizar gerenciamento transacional. Nos dois métodos percebe-se que.

(24) 8. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. o código relativo ao in´ıcio do gerenciamento transacional (Linhas 5 e 15), a grava¸caõ das mudan¸cas realizadas (Linhas 7 e 17) e o retorno ao estado anterior em caso de falhas (Linhas 9 e 19) é igual e está entrele¸cado com o interesse central dos métodos que é realizar as opera¸co˜es de inser¸caõ e atualiza¸cão. O código também esta espalhado, caracter´ısticas que definem um interesse transversal. Para modularizar esse interesses utilizaremos a orienta¸cão a aspectos através dos mecanismos providos pela linguagem AspectJ. Listing 2.2 Facade OO Modularizada 1 2 3 4 5 6 7 8 9 10 11. public c l a s s Facade { public void i n s e r t ( Employee employee ) { employeeRecord . i n s e r t ( employee ) ; } public void update ( Employee employee ) { employeeRecord . update ( employee ) ; } ... }. Para modularizar o interesse transversal de gerenciamento transacional, inicialmente implementamos na fachada apenas o código referente ao interesse central, no exemplo as rotinas de inser¸cão e atualiza¸caõ. Na Listagem 2.2 apresentamos como ficaria a fachada apenas com as rotinas de inser¸caõ, sem a presen¸ca do interesse transversal de gerenciamento de transa¸co˜es. Essa implementa¸cão deixa a fachada mais flex´ıvel e com maior possibilidade de reutiliza¸caõ, por exemplo por um sistema onde o gerenciamento transacional não fosse requerido. Listing 2.3 Aspecto Responsável pelo Gerenciamento de Transa¸c˜ oes de Facade 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16. public aspect TransactionManagement { pointcut t r a n s a c t i o n a l M e t h o d s ( ) : execution ( ∗ Facade . ∗ ( . . ) ) ; ; before ( ) : t r a n s a c t i o n a l M e t h o d s ( ) { getPm ( ) . b e g i n T r a n s a c t i o n ( ) ; } a f t e r ( ) returning : t r a n s a c t i o n a l M e t h o d s ( ) getPm ( ) . c om mit Tran sa ctio n ( ) ; } a f t e r ( ) throwing : t r a n s a c t i o n a l M e t h o d s ( ) getPm ( ) . r o l l b a c k T r a n s a c t i o n ( ) ; }. {. {. }. O gerenciamento transacional seria então implementado pelo aspecto exibido na Listagem 2.3. Na Linha 1 temos a declara¸cão do aspecto responsável pelo gerenciamento transacional na linguagem AspectJ, no qual todo tratamento relativo a esse interesse transversal deve ser inclu´ıdo. O aspecto pode se utilizar de conjuntos de pontos de jun¸cão, adendos, atributos e métodos para fazer esse tratamento. A Linha 3 declara o conjunto de pontos de jun¸cão transactionalMethods responsável por selecionar os pontos de jun¸caõ onde o gerenciamento transacional será adicionado. No exemplo, os pontos de jun¸caõ selecionados são as execu¸cões de todos os métodos existentes na fachada. Para.

(25) 2.2 PROJETO DE SOFTWARE. 9. denotar que são todos os métodos, independentemente do tipo de retorno, o wildcard ’*’ é utilizado e para denotar que esses métodos pode possuir qualquer n´ umero de parâmetros e com quaisquer tipos, é utilizado o wildcard ’..’. A utiliza¸cão de wildcards é importante para facilitar a sele¸caõ de um conjunto de pontos de jun¸caõ sem a necessidade de escrevê-los individualmente. Caso apenas alguns métodos precisassem de gerenciamento de transa¸cões, seriam selecionados pelos conjuntos de pontos de jun¸caõ apenas as assinaturas dos métodos correspondentes. O código seguinte à declara¸caõ do conjunto de pontos de jun¸cão especifica três adendos: o primeiro adendo (Linhas 5-7) insere o código relativo ao in´ıcio do gerenciamento transacional antes da execu¸cão dos pontos de jun¸caõ selecionados pelo conjunto de pontos de jun¸cão transactionalMethods; o segundo adendo (Linhas 9-11) insere o código depois da execu¸caõ desse mesmo conjunto de pontos de jun¸cão quando a opera¸cão for realizada com sucesso, sem o lan¸camento de exce¸co˜es; e finalmente o u ´ltimo adendo (Linhas 13 a 15) insere o código também depois da execu¸caõ do conjunto de pontos de jun¸cão mas somente se houver algum problema e uma exce¸cão for lan¸cada. Nas se¸co˜es seguintes, é explicado como esses conceitos da orienta¸caõ a aspectos, inicialmente relativos à fase de implementa¸caõ, influenciam a fase de projeto, mais especificamente o projeto da arquitetura. 2.2. PROJETO DE SOFTWARE. O projeto de software é um processo iterativo através do qual requisitos de software são traduzidos em artefatos que demonstram que existe uma solu¸caõ fact´ıvel para a constru¸cão do software. O resultado desse processo é a especifica¸caõ de como a aplica¸cão deverá ser constru´ıda e as restri¸cões técnicas de implementa¸caõ que deverão ser obedecidas [Pre02]. Cada um dos elementos do modelo de análise fornece informa¸caõ necessária para criar os modelos de projeto. O projeto é a etapa na qual a qualidade é incorporada à engenharia de software e serve de base para todas as fases que se seguem à engenharia do software.. Figura 2.3 Principais Artefatos do Projeto de Software.. Na Figura 2.3 exibimos os quatro principais artefatos que, segundo Preesman [Pre02],.

(26) 10. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. são produzidos pelos principais métodos de projeto de software. Cada uma dessas atividades oferece informa¸co˜es para realiza¸cão das etapas superiores. Vale ressaltar que, a depender do tipo de software a ser constru´ıdo e da metodologia adotada, algumas dessas etapas podem ser suprimidas ou simplificadas. Mas geralmente temos as seguintes etapas: • Projeto Arquitetural : define as rela¸co˜es entre os principais elementos estruturais do software, os padrões de projeto e as restri¸cões que afetam o modo pelo qual os padrões de projeto arquitetural podem ser aplicados. • Projeto de Interface: descreve como o software se comunica com ele mesmo, com os sistemas que interoperam com ele e com as pessoas que o utilizam. Uma interface implica um fluxo de informa¸caõ e um tipo de comportamento espec´ıfico. • Projeto dos Componentes: transforma elementos estruturais da arquitetura de software numa descri¸cão procedimental dos componentes de software. • Projeto de Dados: transforma o modelo do dom´ınio da informa¸cão nas estruturas de dados que vão ser necessárias para implementar o software. Parte do projeto de dados pode ocorrer em conjuga¸cão com o projeto de arquitetura. Projeto mais detalhado ocorre à medida que cada componente de software é projetado. O resultado dessas atividades é um conjunto de modelos que caracterizam e especificam o comportamento e a estrutura do software requerido. Estes modelos podem ter diferentes n´ıveis de abstra¸caõ, a depender do n´ıvel de detalhes necessário. O Projeto de Software Orientado a Aspectos (PSOA) tem os mesmos objetivos que qualquer atividade de projeto: caracterizar e especificar a estrutura e o comportamento do software. A diferen¸ca é que nas abordagens de PSOA há o tratamento diferenciado para os interesses transversais. Neste trabalho o foco será nas atividades de projeto arquitetural e projeto das interfaces, destacadas na Figura 2.3, principais responsáveis pelo estabelecimento das regras relativas à modulariza¸caõ do sistema. Assim, nas se¸cões seguintes descrevemos a atividade de projeto da arquitetura do software e ressaltamos sua importância para alcan¸car essa meta. 2.3. PROJETO DE ARQUITETURA DE SOFTWARE. A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externas vis´ıveis a esses componentes e os relacionamentos entre eles [BCK03]. No contexto do projeto arquitetural, um componente de software pode ser algo tão simples quanto um módulo de programa mas também pode ser ampliado para incluir, por exemplo, uma base de dados. As propriedades dos componentes são aquelas caracter´ısticas necessárias para o entendimento de como os componentes interagem com os outros componentes. As rela¸cões entre componentes podem ser tão simples quanto uma chamada a procedimento de um módulo para outro ou tão complexas quanto um protocolo de acesso a base de.

(27) 2.3 PROJETO DE ARQUITETURA DE SOFTWARE. 11. dados. Assim, o projeto arquitetural foca na representa¸cão da estrutura de componentes de software, suas propriedades e intera¸co˜es. Um sistema normalmente é composto por vários tipos de componentes. Porém, na descri¸cão da arquitetura, normalmente são escolhidos aqueles que são mais representativos ou ainda são constru´ıdas várias visões da organiza¸caõ desses componentes [CN02a]. Para tomar as decisões no projeto arquitetural o projetista leva em conta os requisitos para motivar e justificar suas decisões. Além disso devem ser consideradas também as metas de qualidade, cenários de uso, padrões de projeto [GHJV95] e estilos arquiteturais existentes. A Figura 2.4 exibe essas entradas, necessárias para o projeto da arquitetura e que geram como resultado a sua documenta¸caõ.. Figura 2.4 Combina¸cão aspectual no sistema orientado a aspectos.. Os atributos de qualidade, também chamados de requisitos não-funcionais, são usados como critérios de sele¸cão na escolha de alternativas de projeto, estilo arquitetural e forma de implementa¸caõ. Segundo Mendes [Men02] os principais atributos de qualidade a serem considerados no projeto arquitetural são: • usabilidade: especifica tanto o n´ıvel de desempenho quanto a satisfa¸caõ do usuário no uso de sistema. Para determinar se a arquitetura satisfaz os aspectos de usabilidade é necessário o desenvolvimento de cenários de uso do sistema. Os cenários devem assegurar que informa¸co˜es corretas estejam dispon´ıveis ao usuário no momento adequado, bem como encaminhar corretamente a¸co˜es ou comandos dos usuários aos componentes apropriados do sistema. • manutenibilidade: é um dos requisitos mais relacionados com a arquitetura pois a facilidade de fazer modifica¸co˜es vai depender muito desta. Dessa forma, a arquitetura deve acomodar as modifica¸co˜es que precisem ser feitas tanto durante o desenvolvimento quanto após o sistema entrar em opera¸cão. • confiabilidade: é a probabilidade do sistema de software não apresentar desvios com rela¸caõ à sua especifica¸cão durante um determinado per´ıodo de tempo sob condi¸co˜es espec´ıficas. A arquitetura influenciará na confiabilidade do sistema e uma das formas que pode ser utilizada para melhorá-la é a replica¸caõ dos componentes mais suscet´ıveis a falhas. • desempenho: o desempenho do sistema depende muito da intera¸caõ existente entre os componentes de um sistema de software e, portanto, está muito associado à.

(28) 12. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. arquitetura. Normalmente é influenciado por outros requisitos de qualidade. Por exemplo, a confiabilidade alcan¸cada com a replica¸caõ de componentes pode comprometer o desempenho do sistema. • portabilidade: é a facilidade com a qual o software pode ser transferido de um sistema computacional ou ambiente para outro. Quanto maior a necessidade de portabilidade do sistema, mais elaborada vai ter que ser a arquitetura para dar suporte a diferentes plataformas. • reusabilidade: tem como objetivo reutilizar componentes já desenvolvidos e testados, diminuindo conseq¨ uentemente os custos. O que determinará o grau de reusabilidade dos componentes de uma arquitetura será a interdependência ou acoplamento entre esses componente. • seguran¸ca: objetiva assegurar a integridade do sistema quanto a ataques intencionais ou acidentais. No desenvolvimento da arquitetura, diversos aspectos, como por exemplo, autentica¸caõ, tempo de acesso, disponibilidade, criptografia e auditoria, devem ser levados em considera¸caõ a fim de atender os requisitos de seguran¸ca. Os cenários de uso são exemplos de intera¸caõ entre usuários e o sistema e também influenciam as decisões para projeto da arquitetura. Os tipos de cenários a ser desenvolvidos estão intimamente relacionados ao software que se deseja construir. Por exemplo, pode se desenvolver cenário de tempo de resposta para o desempenho, cenários de invasão para um sistema onde seguran¸ca seja um item cr´ıtico e cenários de degrada¸cão para avaliar a disponibilidade do sistema. Os padrões de projeto descrevem solu¸co˜es simples e elegantes para problemas que aconteceram várias vezes no desenvolvimento de software. Refletem a experiência dos desenvolvedores e ajudam o projetista a criar um software mais flex´ıvel e reutilizável [GHJV95]. No projeto da arquitetura esses padrões devem ser conhecidos pelo projetista para que este possa chegar mais rápido à solu¸cão correta para o problema. Finalmente, os estilos arquiteturais também podem ser utilizados como pontos de partida na elabora¸caõ da arquitetura. São semelhantes aos padrões de projeto pois descrevem solu¸cões elegantes para problemas que aconteceram diversas vezes. Entretanto, funcionam em um n´ıvel mais alto de abstra¸caõ, ignorando questões como paradigma de programa¸cão adotado. Na se¸cão seguinte são detalhados os principais estilos arquiteturais existentes e como estes devem ser utilizados para projetar arquiteturas mais flex´ıveis e reusáveis. 2.3.1. Estilos Arquiteturais. Ao caracterizar as arquiteturas de software que são utilizadas nos sistemas, identificando seus componentes, mecanismos de intera¸caõ e propriedades, podemos classificá-las. Um estilo arquitetural é um conjunto de classes ou uma fam´ılia de arquiteturas com semelhan¸cas nas caracter´ısticas dos componentes e conectores, topologia da arquitetura, restri¸cões semânticas e mecanismos de intera¸caõ entre os componentes [BCK03]..

(29) 2.3 PROJETO DE ARQUITETURA DE SOFTWARE. 13. Estilos arquiteturais bem definidos e com caracter´ısticas bem especificadas, semelhantes à utiliza¸caõ de padrões de projetos, diminuem o esfor¸co dos projetistas para encontrar a melhor solu¸cão e facilitam a comunica¸caõ entre os desenvolvedores da solu¸caõ adotada. Estilos arquiteturais também são conhecidos na literatura como padrões arquiteturais. Nas subse¸cões seguintes são apresentados os principais estilos arquiteturais encontrados na literatura, procurando identificar seus componentes, mecanismos de itera¸caõ e propriedades. 2.3.1.1 Pipes e Filtros Nesse estilo arquitetural os dados fluem de uma extremidade a outra através dos pipes e sofrem transforma¸cões quando processados nos filtros. Um pipe provê um canal unidirecional, atuando como condutor do fluxo de dados entre a fonte de origem dos dados e o destino. O estilo é adequado para o projeto de sistemas que requerem vários estágios de processamento. Cada estágio é implementado como um filtro que recebe os dados e, depois de realizar alguma transforma¸caõ, produz dados na sa´ıda, que são associados por meio de pipe ao próximo estágio.. Figura 2.5 Arquitetura do Compilador.. Um exemplo da utiliza¸caõ do estilo arquitetural pipes e filtros é o modelo clássico dos compiladores apresentado na Figura 2.5. Nessa arquitetura cada etapa do processamento é realizada separadamente e os resultados parciais de cada fase são encaminhados à etapa seguinte. Na figura, o compilador é decomposto em seis componentes associados às seis fases da compila¸caõ. Cada componente da figura é um filtro que efetua uma transforma¸cão sobre os dados que são canalizados através dos pipes para o próximo componente. 2.3.1.2 Camadas Este estilo arquitetural estrutura o sistema num conjunto de camadas, onde cada uma delas agrupa um conjunto de tarefas num determinado n´ıvel de abstra¸cão. Geralmente as camadas num n´ıvel inferior oferecem servi¸cos à camada de n´ıvel superior. A arquitetura em camadas não especifica qual deveria ser a granularidade dos componentes. Entretanto, componentes complexos normalmente exigirão decomposi¸caõ adicional. A Figura 2.6 exibe a arquitetura da internet TCP/IP formada por quatro camadas distintas. No estilo em camadas, diferentemente do estilo pipes e filtros, pode haver comunica¸cão entre os componentes em ambos os sentidos..

(30) 14. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. Figura 2.6 Arquitetura de de Internet TCP/IP.. 2.3.1.3 Objetos O estilo arquitetural de objetos tem como base o uso de um tipo de dados abstrato: o objeto. Dessa forma o sistema de software é visto como um conjunto de objetos comunicantes com estado associado a eles e opera¸co˜es associados àqueles estados. Os objetos podem requisitar e oferecer servi¸cos. Neste caso, quando um objeto precisa se comunicar com outro, é necessário que ele conhe¸ca a identidade do objeto ao qual a mensagem será enviada. A desvantagem da utiliza¸caõ desse estilo é justamente a dependência entre os objetos que se comunicam, visto que esses precisam fazer uma chamada expl´ıcita através da referência do objeto alvo, diminuindo a possibilidade de reuso do componente. 2.3.1.4 Invoca¸c˜ ao Impl´ıcita Também conhecido na área de sistemas distribu´ıdos como estilo publisher/subscriber. Diferentemente do estilo arquitetural com base em objetos, no qual um componente (objeto) invoca o outro diretamente por meio de passagem de mensagens, o estilo arquitetural de invoca¸caõ impl´ıcita requer que os componentes interessados em um evento registrem-se a fim de recebê-lo. Assim, componentes podem tanto registrar interesse em receber eventos quanto em divulgar eventos. Tais eventos podem e, provavelmente, contêm dados. Nesse caso, o sistema dispõe de um mecanismos para tratamento de eventos, o qual encarrega-se de encaminhar os eventos aos componentes destinatários. 2.3.1.5 Quadro-Negro O estilo quadro-negro ou blackboard originou-se no campo da inteligência artificial, no qual ele era utilizado como um mecanismo para compartilhamento de conhecimento ou dados por vários componentes inteligentes. Esse etilo considera a existência de um repositório central de dados circundado por um conjunto de componentes (células do conhecimento). O estilo arquitetural quadro-negro consiste basicamente em três componentes: as células do conhecimento que possuem o conhecimento necessário para solucionar um.

(31) ˜ DE ARQUITETURA 2.4 LINGUAGENS DE DESCRIC ¸ AO. 15. problema ou parte dele; a estrutura de dados quadro-negro, um banco de dados compartilhado que possui dados de solu¸cão de problemas que são acessados pelas células de conhecimento, e o controle, que faz com que as células de conhecimento respondam de forma oportunista às mudan¸cas no quadro-negro. As células de conhecimento podem ser ativadas através do estado do quadro-negro. Dessa forma, as células de conhecimento respondem às altera¸cões que acontecem no ´ importante observar que o fluxo de controle do sistema não é expliquadro-negro. E citamente definido. Em vez disso, o fluxo de controle é determinado pelo conjunto de componentes ativos em um determinado instante. 2.3.1.6 Cliente-Servidor Este estilo permite que várias tarefas sejam divididas entre produtores e consumidores de dados. Um servidor é um processo que fica num estado de espera, aguardando solicita¸caõ de servi¸co de um ou mais clientes. O servidor pode trabalhar de forma s´ıncrona ou ass´ıncrona. Quando operando de modo s´ıncrono, o servidor retorna o controle ao cliente no mesmo instante em que ele envia os dados resultantes. Se o servidor trabalhar de forma ass´ıncrona, o servidor não necessariamente retorna os dados resultantes ao cliente no mesmo instante da solicita¸caõ. Os clientes no estilo arquitetural cliente-servidor podem ser vistos como processos que atuam de forma independente, isto é, a execu¸caõ de um processo não interfere em outro. Esta independência entre processos facilita a remo¸caõ/inser¸caõ de clientes e facilita a modifica¸caõ da funcionalidade de um cliente visto que os outros não serão afetados. 2.4. ˜ DE ARQUITETURA LINGUAGENS DE DESCRIC ¸ AO. Nas se¸co˜es anteriores foram apresentados princ´ıpios gerais que devem ser utilizadas para a cria¸caõ do projeto da arquitetura do software. Seguindo esses princ´ıpios, deve-se usar mecanismos que possam documentar decisões e validá-las caso seja necessário. Segundo Clements [Cle96] existem três visões que podem ser utilizadas para documenta¸cão da arquitetura. A vis˜ ao baseada nas estruturas código (visão lógica) utiliza módulos, pacotes e classes com relacionamentos de dependência, uso, heran¸ca, etc. Nesse tipo de documenta¸cão normalmente são utilizados figuras e diagramas que dificultam a análise de propriedades da arquitetura. A visão baseada nas estruturas de execu¸c˜ ao, também chamada vis˜ ao de componentes e conectores (C&C), utiliza componentes, conectores e sistemas para indicar as regras de comunica¸caõ. A visão baseada nas estruturas de aloca¸c˜ ao (visão f´ısica ou visão de implanta¸c˜ ao) mapeia elementos das duas primeiras visões em entidades não-software, tais como configura¸co˜es f´ısicas (rede, CPU, etc) ou desenvolvimento de equipes. Neste trabalho o foco será na modelagem da arquitetura baseada na vis˜ ao das estruturas de execu¸c˜ ao, ou vis˜ ao de componentes e conectores (C&C). Essa abordagem facilita a análise de propriedades cr´ıticas do sistema como disponibilidade, seguran¸ca e desempenho. A Figura 2.7 ilustra os principais conceitos da visão de componentes e conectores: o component que modela o elemento computacional principal e que possui um conjunto de ports que modelam as interfaces de comunica¸caõ do componente; o connector que.

(32) 16. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. Figura 2.7 Visão Componente e Conector [GMW97].. modela os caminhos de comunica¸cão entre os componentes e que possuem um conjunto de roles que modelam as especifica¸co˜es requeridas para o componente que usar o conector; e os systems que agrupam um conjunto de componentes, conectores e configura¸co˜es entre estes. Esta visão da arquitetura é utilizada pelas maioria das linguagens de descri¸caõ arquitetural. As Linguagens de Descri¸caõ de Arquitetura (LDAs) são linguagens formais que podem ser utilizadas para representar a arquitetura de um sistema de software [Cle96]. Elas tentam suprir as falhas de abordagens informais de representa¸caõ, como figuras e diagramas, incluindo caracter´ısticas sofisticadas de análise e teste que permitem guiar as decisões de projeto. O uso de abordagens formais na ind´ ustria ainda não é largamente difundido, entretanto, com o incremento da complexidade dos novos softwares, a utiliza¸caõ de abordagens formais torna-se um mecanismo efetivo para antecipa¸caõ de problemas que só poderiam ser identificados na fase de desenvolvimento, caso mecanismos formais não fossem utilizados. Um grande n´ umero de linguagens de descri¸cão de arquitetura têm sido definidas para descrever, modelar, checar e implementar arquiteturas de software [MT00]. Alguns exemplos de LDAs são: • Wright [AG97] permite que arquitetos especifiquem protocolos de comunica¸caõ temporal e checar propriedades como livre de deadlock. A semântica de intera¸cão entre os componentes é especificada em CSP. Ela tem um extens´ıvel sistema de tipos e suporta a defini¸caõ de estilos arquiteturais, mas não suporta evolu¸caõ de seus componentes. • SADL [Pon87] formaliza arquiteturas em termos de teorias, mostra como opera¸cões de refinamentos genéricas podem ser provadas corretas, e descreve um n´ umero de padrões de refinamentos flex´ıveis. • Rapide [ML97] é uma linguagem para especifica¸cão de sistemas distribu´ıdos de grande escala. Suporta especifica¸cão comportamental baseada em eventos e a simula¸caõ de arquiteturas reativas. Os componentes em Rapide são representados como interfaces cujos pontos de comunica¸caõ consistem de ”provides”, ”requires”, ”actions” e ”services”. Rapide tem um extens´ıvel sistema de tipos, suporta parametriza¸caõ de tipos e heran¸ca estrutural através de subtipos..

(33) ˜ DE ARQUITETURA 2.4 LINGUAGENS DE DESCRIC ¸ AO. 17. • Aesop [MG96] é um sistema para desenvolvimento de projetos orientados a estilos arquiteturais. Aesop caracteriza estilos arquiteturais como especializa¸co˜es de um modelo de objetos genérico através de sub-tipos. Isto ajuda na gera¸caõ de projetos de estilos espec´ıficos e na constru¸cão de fam´ılias de sistemas dentro do escopo desse estilo. • C2 [MORT96] tem um sistema de tipos extens´ıvel para componentes e conectores. A comunica¸caõ entre os componentes é realizada através de mensagens e os relacionamentos casuais entre mensagens de entrada e sa´ıda dá a semântica. Ela suporta a evolu¸cão de componentes permitindo sub-tipos de nome, interface e comportamento. Dinamismo é poss´ıvel em termos de adi¸cão, exclusão e reconfigura¸co˜es. • ArchJava [ACN02] é uma ADL projetada para dar suporte a mudan¸cas dinâmicas em arquiteturas distribu´ıdas de forma dinâmica. Diferente de outra abordagens que desacoplam o projeto da arquitetura da implementa¸caõ, ArchJava unifica projeto e implementa¸caõ garantindo que a implementa¸caõ obedece as restri¸cões arquiteturais. A abordagem evita inconsistências e confusões entre o modelo e o código que possam violar as propriedades da arquitetura e inibir a evolu¸caõ do software. O grande n´ umero de LDAs existentes na literatura traz como vantagem a explora¸caõ de diversos problemas no projeto da arquitetura. Mesmo possuindo muitas caracter´ısticas em comum cada LDA trabalha de forma diferente, tornando dif´ıcil combinar as facilidades que cada LDA apresenta. Outro problema é a falta ferramentas para prover suporte integrado a utiliza¸caõ de várias LDAs. O esfor¸co pode se tornar grande, caso vários LDAs sejam necessárias para análise da arquitetura. Para resolver esses problemas surgiu a linguagem ACME [GMW97], detalhada a seguir. 2.4.1. ACME. ACME [GMW97] é uma linguagem de intercâmbio de arquiteturas usada para mapear especifica¸co˜es através de diferentes LDAs. Ela suporta um sistema de tipos extens´ıvel para componentes e conectores e a evolu¸caõ é possibilitada através da utiliza¸caõ do mecanismo de representa¸cões. ACME possui limita¸co˜es quanto a verifica¸caõ de propriedades da arquitetura, como concorrência e disponibilidade, verificáveis em outras linguagens. Dessa forma, caso fosse necessário verificar essas propriedades, seria necessário utilizar outra LDA e em seguida mapear essa especifica¸caõ para ACME. A linguagem ACME foca na descri¸cão da estrutura do sistema e como esta estrutura pode evoluir ao longo do tempo. Para a descri¸cão da arquitetura, sete constru¸co˜es principais são utilizadas pela linguagem: components, connectors, ports, roles, systems, representations, e properties. Os components representam o elemento de computa¸caõ primário. Exemplos t´ıpicos incluem clientes, servidores, filtros, objetos, entre outros. As interfaces de comunica¸cão dos components são definidas por um conjunto de ports. Cada port identifica um ponto de intera¸cão entre o componente e o ambiente. Um componente pode prover m´ ultiplas interfaces através da utiliza¸caõ de várias ports..

(34) 18. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. Os connectors representam as intera¸co˜es entre os components, mediando a comunica¸cão e coordenando as atividades entre estes. Exemplos incluem simples formas de intera¸cão como pipes, chamada a procedimento e o protocolo cliente-servidor. As interfaces de comunica¸cão dos connectors são definidas por roles. Cada role de um connector define um participante da intera¸cão representada pelo connector. Systems representam configura¸cões de components e connectors. Um system inclui um conjunto de components, um conjunto de connectors e um conjunto de attachments que descrevem a topologia do sistema. Um attachment descreve o relacionamento entre um connector e um component pela associa¸caõ da interface port do component com a interface role do connector. A Listagem 2.4 exibe um exemplo de uma arquitetura com dois components: um client e um server conectados pelo connector rpc (Linhas 2, 3, e 4 respectivamente). O component client declara uma u ńica port, send-request (Linha 2), e o component server também declara uma u ńica port, receive-request (Linha 3). O connector possui dois roles denominados caller e callee (Linha 4). A topologia do sistema é declarado pelo conjunto de attachments (Linhas 5-8). Listing 2.4 Especifica¸cão Acme Simples de um Arquitetura Cliente-Servidor. 1 2 3 4 5 6 7 8 9. System s i m p l e c s = { Component c l i e n t = { Port send−r e q u e s t } Component s e r v e r = { Port r e c e i v e −r e q u e s t } Connector r p c = { R o l e s { c a l l e r , c a l l e e } } Attachments { c l i e n t . send−r e q u e s t t o r p c . c a l l e r ; s e r v e r . r e c e i v e −r e q u e s t t o r p c . c a l l e e } }. Representations são um mecanismo provido por ACME para dar suporte a decomposi¸caõ hierárquica. Esse mecanismo permite representar qualquer component ou connector de uma forma mais detalhada através de uma descri¸cão de mais baixo n´ıvel. Cada descri¸cão é denominado representation e cada entidade pode possuir mais de uma, permitindo m´ ultiplas visões da mesma entidade. A Property é o mecanismo provido por ACME para anotar decisões de projeto, geralmente informa¸cão não-estrutural. Todas as entidades arquiteturais descritas anteriormente podem ser anotadas com properties. A declara¸caõ de uma property é uma tripla formada pelo nome, tipo e valor. A linguagem provê um série de tipos pré-definidos, como por exemplo, string, float, enum, sequence, set e record. A linguagem também permite que novos tipos sejam criados. Listing 2.5 Especifica¸cão Acme de um Arquitetura Cliente-Servidor com Properties. 1 2 3 4 5 6 7 8 9 10. System s i m p l e c s = { Component c l i e n t = { Port send−r e q u e s t ; Properties { r e q u e s t −r a t e : f l o a t = 1 7 . 0 ; s o u r c e −code : e x t e r n a l − f i l e = ”CODE−LIB/ c l i e n t . c ” } } Component s e r v e r = { Port r e c e i v e −r e q u e s t ;.

(35) ˜ DE ARQUITETURA 2.4 LINGUAGENS DE DESCRIC ¸ AO 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30. 19. Properties { i d e m p o t e n t : boolean = true ; max−c o n c u r r e n t −c l i e n t s : i n t e g e r = 1 ; s o u r c e −code : e x t e r n a l − f i l e = ”CODE−LIB/ s e r v e r . c ” } } Connector r p c = { Role c a l l e r ; Role c a l l e e ; Properties { s y n c h r o n o u s : boolean = true ; max−r o l e s : i n t e g e r = 2 ; p r o t o c o l : Wright = ” . . . ” } } Attachments { c l i e n t . send−r e q u e s t t o r p c . c a l l e r ; s e r v e r . r e c e i v e −r e q u e s t t o r p c . c a l l e e } }. A Listagem 2.5 descreve uma extensão da Listagem 2.4 anotada com properties que descrevem caracter´ısticas dos elementos estruturais do sistema. Essas constru¸cões também podem ser utilizadas para dar suporte ao intercâmbio entre diferentes LDAs. A Figura 2.8 ilustra uma dessas possibilidades. Quando, por exemplo, os desenvolvedores de Wright precisassem utilizar as caracter´ısticas de Rapide para simular e animar as descri¸co˜es arquiteturais. Assim, descri¸cões em Wright seriam num primeiro passo traduzidas para ACME, num segundo passo a descri¸caõ em ACME seria alterada para incluir propriedades espec´ıficas de Rapide e, finalmente, a descri¸cão Rapide seria produzida [GMW97].. Figura 2.8 Vis˜ ao Componente e Conector.. Outra caracter´ıstica importante da linguagem ACME é a especifica¸caõ de estilos arquiteturais que podem ser reutilizados em vários sistemas. Uma especifica¸caõ de um estilo arquitetural consiste num conjunto de defini¸cões de tipos, um conjunto de design rules, um conjunto de regras de análise e um conjunto de estruturas m´ınimas requeridas. A linguagem ACME também possui uma ferramenta de modelagem bastante poderosa, o AcmeStudio [SG04], que permite a arquitetos modelar facilmente novas arquiteturas e estilos arquiteturais e utilizar estilos arquiteturais pré-definidos. A ferramenta.

(36) 20. PROJETO DE ARQUITETURA DE SOFTWARE ORIENTADO A ASPECTOS. foi escrita como um plugin do framework Eclipse IDE possibilitando que novas caracter´ısticas sejam facilmente adicionadas. A Figura 2.9 mostra um exemplo da arquitetura cliente-servidor sendo criada pela ferramenta.. Figura 2.9 Ferramenta AcmeStudio.. 2.4.2. AspectualAcme. No n´ıvel do projeto da arquitetura os interesses transversais come¸cam a surgir de forma significativa e precisam ser tratados adequadamente para evitar problemas nas fases subseq¨ uentes. A linguagem AspectualAcme [BCG+ 06], estende a linguagem ACME e provê uma solu¸caõ simples para tratamento desses interesses transversais através da utiliza¸cão do aspectual connector. O Aspectual Connector (AC) é um connector regular com uma nova interface. O principal objetivo dessa nova interface é realizar a distin¸cão entre os componentes participantes da intera¸cão transversal. Assim a constru¸caõ base role é a interface para o componente base e o crosscutting role é a interface para o componente aspectual. Há ainda uma cláusula glue que informa como se dará a intera¸caõ entre esses dois componentes. A Figura 2.10 descreve a composi¸cão entre um componente aspectual e dois compo-.