Uma exposição formal para a composição de frameworks

Texto

(1)

(2) 2.

(3) 3.

(4) 4.

(5) Sum´ ario 1 Introdu¸c˜ ao. 12. 2 Introdu¸c˜ ao a frameworks 2.1 Componentes de um framework . . . . . . . . . . . . . . . . . . 2.2 Tipos de frameworks . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Exemplos de frameworks . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Java Collections Framework . . . . . . . . . . . . . . . . 2.3.2 Simple API for XML (SAX) . . . . . . . . . . . . . . . . 2.3.3 SalesPoint Framework . . . . . . . . . . . . . . . . . . . 2.4 Problemas da composi¸cão de frameworks . . . . . . . . . . . . . 2.4.1 Composi¸cão do fluxo de controle . . . . . . . . . . . . . . 2.4.2 Integra¸cão com sistemas legado e ferramentas existentes . 2.4.3 Framework gap . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Sobreposi¸cão de entidades dos frameworks . . . . . . . . 2.4.5 Integra¸cão de funcionalidades de diferentes frameworks . 2.5 Considera¸cões finais . . . . . . . . . . . . . . . . . . . . . . . . . 3 Vis˜ ao geral: CSP, Z e CSP-Z 3.1 CSP . . . . . . . . . . . . . . 3.1.1 Processos primitivos . 3.1.2 Prefixo . . . . . . . . . 3.1.3 Recursão . . . . . . . . 3.1.4 Composi¸cão seq¨ uencial 3.1.5 Escolha . . . . . . . . 3.1.6 Paralelismo . . . . . . 3.1.7 Comunica¸cão . . . . . 3.1.8 Traces . . . . . . . . . 3.1.9 Falhas . . . . . . . . . 3.1.10 Divergências . . . . . . 3.2 Z . . . . . . . . . . . . . . . . 3.2.1 Free types . . . . . . . 3.2.2 Esquemas . . . . . . . 3.3 CSP-Z . . . . . . . . . . . . . 3.3.1 Exemplo ilustrativo . . 3.4 Considera¸cões finais . . . . . .. . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. 16 16 16 17 17 17 18 18 19 20 21 22 23 23. . . . . . . . . . . . . . . . . .. 25 25 25 26 26 26 27 28 28 29 30 31 31 31 32 34 34 36.

(6) ´ SUMARIO. 6. 4 A estrat´ egia de composi¸c˜ ao 4.1 Exemplo de composi¸cão unidirecional . . . . . . . . . . . . . . . . . 4.1.1 Sobre os tipos de hot spots . . . . . . . . . . . . . . . . . . . 4.1.2 Valida¸cão das caracter´ısticas dos frameworks originais . . . . 4.1.3 Identifica¸cão dos pontos de composi¸cão . . . . . . . . . . . . 4.1.4 Identifica¸cão das seq¨ uências de eventos . . . . . . . . . . . . 4.1.5 Passagens de parâmetros e mapeamentos de tipos . . . . . . 4.1.6 Composi¸cão dos hot spots . . . . . . . . . . . . . . . . . . . 4.1.7 Especifica¸cão do componente de sincroniza¸cão e comunica¸cão 4.1.8 A composi¸cão dos frameworks . . . . . . . . . . . . . . . . . 4.1.9 Sobre a composi¸cão das caracter´ısticas . . . . . . . . . . . . 4.2 Exemplo de composi¸cão bidirecional . . . . . . . . . . . . . . . . . . 4.2.1 O framework CLIENTE . . . . . . . . . . . . . . . . . . . . 4.2.2 O framework GARCOM . . . . . . . . . . . . . . . . . . . . 4.2.3 Valida¸cão das caracter´ısticas dos frameworks originais . . . . 4.2.4 Identifica¸cão dos pontos de composi¸cão . . . . . . . . . . . . 4.2.5 Casamento de eventos . . . . . . . . . . . . . . . . . . . . . 4.2.6 Passagens de parâmetros e mapeamentos de tipos . . . . . . 4.2.7 Especifica¸cão do componente de sincroniza¸cão e comunica¸cão 4.2.8 A composi¸cão dos frameworks . . . . . . . . . . . . . . . . . 4.3 Considera¸cões finais . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38 40 43 44 44 45 47 48 49 56 57 57 59 62 65 65 67 68 69 71 72. 5 Estudo de caso 5.1 Introdu¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Descri¸cão do exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 O framework de persistência de dados . . . . . . . . . . . . . 5.2.2 O framework de envio de mensagens . . . . . . . . . . . . . 5.2.3 Sobre as threads de execu¸cão . . . . . . . . . . . . . . . . . 5.3 O passo-a-passo da composi¸cão . . . . . . . . . . . . . . . . . . . . 5.3.1 Valida¸cão das caracter´ısticas clássicas dos frameworks originais 5.3.2 Identifica¸cão dos pontos de composi¸cão . . . . . . . . . . . . 5.3.3 Identifica¸cão das seq¨ uências de eventos . . . . . . . . . . . . 5.3.4 Passagens de parâmetros e mapeamentos de tipos . . . . . . 5.3.5 Composi¸cão de hot spots . . . . . . . . . . . . . . . . . . . . 5.3.6 Especifica¸cão do componente de sincroniza¸cão e comunica¸cão 5.3.7 A composi¸cão dos frameworks . . . . . . . . . . . . . . . . . 5.3.8 O refinamento dos frameworks envolvidos . . . . . . . . . . . 5.3.9 A composi¸cão dos refinamentos . . . . . . . . . . . . . . . . 5.4 Considera¸cões finais . . . . . . . . . . . . . . . . . . . . . . . . . . .. 73 73 73 74 79 81 81 81 82 84 84 85 86 88 88 91 91. 6 Conclus˜ ao 92 6.1 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.1.1 A Pi-Calculus based Framework for the Composition and Replacement of Components . . . . . . . . . . . . . . . . . . 94.

(7) ´ SUMARIO 6.1.2. 6.2. A channel-based coordination model for component composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 OOD Frameworks in Component-based Software Development in Computational Logic . . . . . . . . . . . . . . . . 6.1.4 Composi¸cão de Fluxo de Controle de Frameworks Java . . Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. . 94 . 95 . 95 . 95. A Os frameworks do exemplo completo 97 A.1 O framework de persistência de dados . . . . . . . . . . . . . . . . . 97 A.2 O framework de envio de mensagens . . . . . . . . . . . . . . . . . 112.

(8) Lista de Tabelas 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11. Caracter´ısticas originais de CLIENTE e SERVIDOR . . . . . . . Casamento de eventos do processamento CLIENTE - SERVIDOR Casamento de eventos da valida¸cão CLIENTE - SERVIDOR . . . Eventos envolvidos em escolhas internas CLIENTE - SERVIDOR Caracter´ısticas originais do CLIENTE e do SERVIDOR . . . . . Tipos de dados do exemplo bidirecional . . . . . . . . . . . . . . . Caracter´ısticas originais do CLIENTE e do GARCOM . . . . . . Versão inicial do casamento CLIENTE - GARCOM . . . . . . . . Casamento GARCOM - CLIENTE . . . . . . . . . . . . . . . . . Casamento CLIENTE - GARCOM . . . . . . . . . . . . . . . . . Caracter´ısticas da composi¸cão CLIENTE e do GARCOM . . . .. . . . . . . . . . . .. 44 47 47 49 57 59 65 67 68 68 72. 5.1 5.2 5.3 5.4 5.5 5.6. Casamentos do endere¸camento das mensagens . . . . . . . . Casamentos do armazenamento dos registros de envio . . . . Descri¸cão dos mapeamentos do estudo de caso . . . . . . . . Eventos envolvidos em escolhas internas - estudo de caso . . Caracter´ısticas da composi¸cão do estudo de caso . . . . . . . Caracter´ısticas da composi¸cão dos refinamentos do estudo de. . . . . . .. 84 84 84 86 88 91. 8. . . . . . . . . . . . . . . . caso.

(9) Lista de Figuras 1.1. Visão geral da estratégia . . . . . . . . . . . . . . . . . . . . . . . . 13. 2.1. Adaptando a interface da classe Adaptee . . . . . . . . . . . . . . . 21. 4.1 4.2 4.3 4.4 4.5. Visão geral da estratégia . . . . . . . . . . . . . . . . . . . . . . . Visão geral da composi¸cão . . . . . . . . . . . . . . . . . . . . . . Diagrama de seq¨ uência - CLIENTE processando informa¸cões. . . Diagrama de seq¨ uência - SERVIDOR validando informa¸cões e realizando processamento. . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de seq¨ uência - Intera¸cão entre CLIENTE e GARCOM.. 5.1 5.2. A arquitetura de framework de persistência de dados . . . . . . . . 74 A arquitetura do framework de envio de mensagens . . . . . . . . . 79. 9. . 38 . 39 . 41 . 42 . 58.

(10) Resumo O desenvolvimento de aplica¸cões baseado em frameworks tem sido apontado como o próximo passo em dire¸cão a um maior reuso de software. O reuso através da composi¸cão de dois frameworks, e não apenas através de extensões de classes de um u ńico framework, tornou-se uma necessidade gerada pelo aumento da complexidade de desenvolvimento de sistemas computacionais. Neste sentido, tornam-se necessárias novas técnicas de documenta¸cão ou especifica¸cão de frameworks que eliminem imprecisões e ambig¨ uidades nas descri¸cões dos seus comportamentos. Este trabalho apresenta uma estratégia de composi¸cão de frameworks que utiliza linguagens de especifica¸cão formal para descrever seus comportamentos e estruturas de dados. As linguagens utilizadas são CSP, Z e CSP-Z. Por tratar da composi¸cão no n´ıvel das especifica¸cões formais, a estratégia consegue abstrair detalhes de implementa¸cão e eliminar restri¸cões ligadas a estes detalhes. Além disso, a abordagem formal permite a verifica¸cão, através do verificador de modelos de CSP, FDR, da manuten¸cão das propriedades dos frameworks originais. O objetivo principal da estratégia é a composi¸cão de fluxos de controle, que é um dos problemas mais comuns da composi¸cão de frameworks. Nós apresentamos as causas e poss´ıveis solu¸cões deste e dos demais problemas da composi¸cão de frameworks. Por fim, mostramos que a estratégia aborda todos os problemas listados em menor ou maior grau. A estratégia pretende realizar a comunica¸cão entre os frameworks através de um casamento entre os eventos e tipos de dados correspondentes dos dois frameworks. A composi¸cão é realizada através de um terceiro componente, o componente de sincroniza¸cão e comunica¸cão (CSC ). A ado¸cão deste componente possibilita maior flexibilidade à composi¸cão e, entre outros benef´ıcios, permite que os frameworks se comuniquem de forma anônima e elimina efeitos colaterais nos seus comportamentos. A estratégia tem todos os seus pontos especificados num n´ıvel de detalhe que facilitará uma futura mecaniza¸cão. Neste sentido, são apresentados modelos para a especifica¸cão do CSC e uma abordagem construtiva para a sua gera¸cão. Palavras chave: Composi¸cão de frameworks, estratégia, métodos formais, reuso de componentes.. 10.

(11) Summary Framework based development has been presented as the next step towards better software reuse. The increasing complexity of computer systems requires the level of reuse that framework composition can achieve. In this scenario, new framework documentation and specification techniques that can eliminate behavior ambiguities and imprecision are overdue. The strategy presented in this work uses formal languages to characterize the framework composition problem, abstracting from implementation details or technology. The languages involved are CSP, Z and CSP-Z. Furthermore, the approach allows the use of the CSP model checking tool (FDR) to verify the preservation of properties after the composition. The main goal of the strategy is to address control flow composition, which is one of the most common framework composition problems. Other composition problems are also discussed, as well as their common causes and possible solutions. Finally, we will demonstrate that the strategy addresses every kind of problem at some level. The strategy intends to communicate the frameworks by matching corresponding events and data types. The composition is performed through a third component, the communication and synchronization component (CSC ). This component provides the composition with great flexibility and abstraction, allowing the frameworks to communicate anonymously and eliminating collateral effects on their behavior. The strategy has been thoroughly detailed in order to allow future automation. For that, CSC specification templates and a constructive approach to its generation are presented. Key words: Framework composition, strategy, formal methods, component reuse.. 11.

(12) Cap´ıtulo 1 Introdu¸c˜ ao Reuso é um dos objetivos centrais da engenharia de software. O paradigma de orienta¸cão-a-objetos representa um grande avan¸co neste sentido, permitindo a constru¸cão de classes que encapsulam informa¸cões e comportamentos, e que podem ser estendidas e usadas em diversas aplica¸cões. Neste cenário, destacam-se dois tipos principais de reuso: reuso de projeto (design) e de implementa¸cão. Inicialmente, buscava-se o reuso através da contru¸cão de bibliotecas de rotinas de procedimentos. Posteriormente, o paradigma de orienta¸cão-a-objetos tornou poss´ıvel a constru¸cão de classes que podem ser reusadas em diversas aplica¸cões. No entanto, estes esfor¸cos permitem basicamente o reuso de componentes individuais que seriam usados como pequenos blocos de novas aplica¸cões. O problema real de reuso de componentes em larga escala, e que representam uma por¸cão maior de um sistema, não é tratado pelo paradigma de orienta¸cão a objetos por si só. Neste contexto, surgiram os Frameworks orientados-a-objetos, que são blocos de constru¸cão muito maiores que objetos e classes [7]. Um framework pode ser definido como um conjunto de classes que incorporam um projeto abstrato para solucionar problemas de um determinado dom´ınio [17, 20, 21]. Eles fornecem a infra-estrutura básica para aplica¸cões de um dom´ınio e permitem que os desenvolvedores se concentrem nas caracter´ısticas espec´ıficas da aplica¸cão. Um framework é composto por um n´ ucleo, que define a sua estrutura e o seu comportamento (os tipos dos objetos, suas regras de intera¸cão ...) e por pontos de extensão (ou hot spots) que permitem que o framework se torne uma aplica¸cão completa. Além da maior possibilidade de reuso em termos da por¸cão das aplica¸cões representadas por eles, os frameworks possibilitam reuso tanto de design quanto de implementa¸cão. Esta é uma outra vantagen dos frameworks sobre outras formas de reuso como bibliotecas de classes, design patterns e componentes. A sinergia entre frameworks e as outras formas de reuso pode ser vista como outro fator importante e motivador do uso de frameworks. Com o aumento da complexidade de desenvolvimento de sistemas de computa¸cão, solu¸cões de um determinado dom´ınio de aplica¸cão requerem o uso de mais de um framework [8]. Este trabalho foca no reuso de frameworks através da sua composi¸cão. Um dos requisitos necessários para o reuso de frameworks 12.

(13) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 13. é o total conhecimento de seus comportamentos. Os métodos de documenta¸cão usualmente adotados (por exemplo, UML) envolvem grande quantidade de texto, imagens e diagramas mas são normalmente imprecisos e amb´ıguos. A ado¸cão de linguagens de especifica¸cão formal para descrever o comportamento dos frameworks elimina estas imprecisões e ambig¨ uidades, além de possibilitar uma análise semântica, abstraindo detalhes de implementa¸cão. Em geral, a descri¸cão de um framework envolve aspectos de controle (comportamentais) que capturam funcionalidades. Complementarmente, são utilizadas estruturas de dados para representar as entidades manipuladas pelo framework. Portanto, é importante que a linguagem de especifica¸cão utilizada para formalizar a composi¸cão de frameworks ofere¸ca facilidades de controle e de dados. Uma tendência na literatura recente, na área de métodos formais, é precisa´ mente a integra¸cão de formalismos. Algebras de processos (que oferecem um repertório rico para exepressar comportamento), como CSP [16], têm sido combinadas com linguagens que focam mais em tipos abstratos de dados, como Z [33, 31]. Um exemplo de integra¸cão é a linguagem CSP-Z [22] que integra o comportamento especificado por processos CSP com estruturas de dados especificadas através de esquemas Z, usada neste trabalho. Outros exemplos são LOTOS [32], Temporal Logic e CSP [34] e CSP-OZ [13, 15]. Nós usaremos a parte CSP das especifica¸cões CSP-Z para especificar o fluxo de controle dos frameworks e a parte Z para representar as estruturas de dados. A grosso modo, a idéia de composi¸cão de frameworks é apresentada na Figura 1.1. Partindo das especifica¸cões em CSP-Z [12] de cada um dos frameworks (SPEC F1 e SPEC F2 ), verificamos, inicialmente, as suas caracter´ısticas clássicas usando a ferramenta FDR [9]. O objetivo central é, então, compor (representado na figura por •) as suas especifica¸cões preservando as caracter´ısticas e sem gerar qualquer efeito colateral nos seus comportamentos. Adicionalmente, se verificarmos que as instâncias dos frameworks (INST F1 e INST F2 ) são realmente válidas, através da verifica¸cão do refinamento entre as instâncias e os frameworks originais, podemos efetuar também a composi¸cão das instâncias assegurando que esta preserva todas as propriedades da composi¸cão dos frameworks. A no¸cão de refinamento adotada é a de Failures Divergences de CSP [16], que captura tanto traces, como as falhas (deadlock ) e divergências (livelock ).. Figura 1.1: Visão geral da estratégia Uma das maiores dificuldades enfrentadas na composi¸cão de frameworks é o fato de os frameworks serem desenvolvidos para a instancia¸cão por extensão e não por composi¸cão. A instancia¸cão por extensão se baseia na extensão das classes do framework que representam os seus hot spots. A instancia¸cão por composi¸cão se.

(14) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 14. baseia na integra¸cão ao framework de componentes (ou frameworks) que respeitem as suas regras. O comportamento coeso de frameworks desenvolvidos para instancia¸cão por extensão torna dif´ıcil a integra¸cão destes novos componentes. Como observado em [8, 7], a composi¸cão de frameworks pode gerar efeitos colaterais indesejáveis, como os problemas de composi¸cão do fluxo de controle, integra¸cão com sistemas legado, framework GAP, sobreposi¸cão de entidades e integra¸cão de funcionalidades de diferentes frameworks. O foco deste trabalho é a composi¸cão de fluxos de controle. A estratégia realiza a composi¸cão através de um terceiro componente responsável pela comunica¸cão entre os dois frameworks compostos e entre cada um deles e o ambiente. A ado¸cão deste componente possibilita maior flexibilidade à composi¸cão, permite que os frameworks se comuniquem de forma anônima e evita efeitos colaterais nos comportamentos dos frameworks após a composi¸cão. A forma de comunica¸cão adota é a sincroniza¸cão de eventos de CSP. Apesar do foco em composi¸cão de frameworks, a estratégia pode ser utilizada em desenvolvimento baseado em componentes, conforme será descrito em mais detalhes posteriormente. Existem duas caracter´ısticas dos frameworks que precisam ser levadas em considera¸cão quando desejamos realizar a composi¸cão: os fluxos de controle e os tipos de dados utilizados. Os dados manipulados por um dos frameworks devem ser entendidos pelo outro e as seq¨ uências de eventos (ou chamadas de métodos) dos dois frameworks não devem ser conflitantes. A nossa estratégia propõe solu¸cões para ambos os problemas, possibilitando um mapeamento de eventos e dados dos frameworks a serem compostos. Outros trabalhos tratam de reuso através de composi¸cão de frameworks. Os trabalhos reportados em [7, 21, 20], por exemplo, analisam os problemas de composi¸cão de frameworks, suas causas e poss´ıveis solu¸cões. Uma lista destes problemas, causas e solu¸cões são apresentadas no Cap´ıtulo 2. O trabalho reportado em [8, 24] analisa o problema da composi¸cão de fluxos de controle de frameworks constru´ıdos em Java e que se comunicam através de troca de mensagens. Além disso, o trabalho apresenta uma ferramenta que verifica, a partir do código dos frameworks e da forma de composi¸cão desejada, os tipos de problemas que podem ocorrer, onde eles podem ocorrer e sugere uma poss´ıvel solu¸cão para cada problema. O trabalho reportado em [19] salienta a importância dos seguintes requisitos do processo de integra¸cão de componentes: a independência do processo em rela¸cão aos componentes sendo compostos e a flexibilidade da reconfigura¸cão da composi¸cão. Por flexibilidade de reconfigura¸cao, entenda-se a inser¸cão de novos componentes sem afetar os componentes já existentes. A nossa estratégia pretende atender a estes requisitos através da ado¸cão do componente responsável pela composi¸cão. Foram analisados também trabalhos que propõem a aplica¸cão de métodos formais para solucionar problemas de composi¸cão de componentes. O trabalho reportado em [25] formalisa a composi¸cão de componentes através da defini¸cão de um protocolo para compatibiliza¸cão de conectores, estabelecimento de conexões,.

(15) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 15. invoca¸cão de servi¸cos, respostas e a posterior substitui¸cão de componentes. Este trabalho utiliza os conceitos de pi -Calculus. Outro trabalho, reportado em [18], faz uma tentativa preliminar de obten¸cão de uma semântica formal para frameworks orientados a objetos. Esse trabalho aponta o uso de frameworks como o próximo passo (após o foco em classes e objetos) em dire¸cão a um maior reuso de software. A abordagem assumida se baseia num formalismo em três camadas: frameworks de especifica¸cões (os tipos tratados pelo framework), especifica¸cões definidas no contexto do framework de especifica¸cões (o framework propriamente dito) e programas corretos (que refinam a especifica¸cão). O trabalho chega à conclusão que existem dois n´ıveis de reuso: reuso de frameworks, baseado em métodos clássicos de heran¸ca envolvendo as restri¸cões das especifica¸cões; e reuso de especifica¸cões e programas, baseado nos meios, a partir de programas corretos, de como compô-los para se chegar a novos programas corretos. O trabalho reportado em [4] apresenta um paradigma chamado Pω (“rheoh”) para composi¸cão de componentes de software baseado na no¸cão de canais móveis. Os operadores de Pω são utilizados para compor componentes a partir de componentes menores. No entanto, o modelo apresentado não se preocupa com detalhes das entidades compostas. Uma compara¸cão mais detalhada da nossa proposta com os trabalhos mencionados é apresentada no Cap´ıtulo 6. O restante deste trabalho está estruturado da seguinte forma. O Cap´ıtulo 2 apresenta uma visão geral de frameworks e dos problemas de composi¸cão de frameworks. O Cap´ıtulo 3 apresenta as linguagens formais utilizadas, seus operadores mais relevantes para o nosso trabalho e descreve brevemente como alguns deles são usados na especifica¸cão de frameworks. O Cap´ıtulo 4 apresenta a estratégia através de dois exemplos simples e descreve em mais detalhes as abordagens adotadas para especificar os hot spots dos frameworks. No Cap´ıtulo 5, nós apresentamos um estudo de caso e, por fim, apresentamos as conclusões, compara¸cões com outros trabalhos e trabalhos futuros no Capitulo 6..

(16) Cap´ıtulo 2 Introdu¸c˜ ao a frameworks Um framework pode ser definido como um conjunto de classes que incorporam um design abstrato para solucionar problemas de um determinado dom´ınio. Além de possibilitar o reuso de design e implementa¸cão, os frameworks fornecem a infra-estrutura básica para aplica¸cões em um determinado dom´ınio e permitem que os desenvolvedores se concentrem nas caracter´ısticas espec´ıficas da aplica¸cão. Aplica¸cões desenvolvidas a partir de um framework são chamadas de instâncias do framework.. 2.1. Componentes de um framework. Um framework é composto de um n´ ucleo e de pontos de extensão (hot spots). O n´ ucleo do framework é composto de classes concretas e abstratas. As classes concretas são projetadas para serem invis´ıveis para o usuário do framework. As classes abstratas podem tanto ser invis´ıveis quanto vis´ıveis para que elas possam ser estendidas pelo usuário do framework. O u ´ltimo caso de classes abstratas representam os hot spots do framework [7]. O n´ ucleo define a estrutura e o comportamento (ou fluxo de controle) do framework, os tipos dos objetos e as regras de como eles interagem [17]. Aplica¸cões desenvolvidas baseadas em um ou mais frameworks devem respeitar a estrutura e as regras definidas pelo(s) framework(s). Os hot spots são os pontos de extensão de um framework. Eles permitem que, quando instanciado, o framework se torne uma aplica¸cão completa. Os hot spots constituem o código espec´ıfico da aplica¸cão.. 2.2. Tipos de frameworks. Os frameworks podem ser divididos em duas categorias, de acordo com o tipo de reutiliza¸cão (ou instancia¸cão) permitido: frameworks caixa-branca e frameworks caixa-preta [7]. Frameworks caixa-branca são os que permitem instancia¸cão através da extensão de suas classes. O termo caixa-branca é usado para denotar visibilidade. Por causa 16.

(17) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 17. da heran¸ca, alguns membros das classes do framework ficam vis´ıveis para as classes espec´ıficas da aplica¸cão. Não existe uma linha bem definida que separe frameworks caixa-branca e uma simples hierarquia de classes. Potencialmente, toda hierarquia de classes pode se tornar um framework caixa-branca. Frameworks caixa-preta ou parametrizados são os que se baseiam em instancia¸cão por composi¸cão. A extensão de frameworks por composi¸cão é obtida através da defini¸cão de classes que seguem as regras do framework (i.e. implementam as interfaces definidas pelo framework) e pela integra¸cão dessas classes ao framework. O comportamento do framework caixa-preta pode ser “customizado” através do uso de diferentes combina¸cões de classes. A instancia¸cão de frameworks por composi¸cão tende a ser mais flex´ıvel que a instancia¸cão por extensão, pois a composi¸cão pode ser alterada em tempo de execu¸cão enquanto que estruturas hierárquicas são fixadas em tempo de compila¸cão, além de permitir o reuso de componentes já existentes. Este trabalho trata de instancia¸cão por composi¸cão. Outra vantagem da instancia¸cão por composi¸cão é a manuten¸cão do encapsulamento das funcionalidades das classes do framework. Como os detalhes internos do framework não são expostos, a aplica¸cão fica menos sens´ıvel a altera¸cões internas do framework ([29]). Apesar da classifica¸cão de frameworks em caixa-branca e caixa-preta, normalmente os frameworks são parametrizados em alguns pontos e “customizados” através de heran¸ca em outros.. 2.3. Exemplos de frameworks. O objetivo dessa se¸cão é demonstrar a usabilidade prática de frameworks através de alguns exemplos reais.. 2.3.1. Java Collections Framework. O Java Collections Framework é um framework que provê um conjunto bem definido de classes e interfaces que permitem o armazenamento e a manipula¸cão cole¸cões ([1]). O framework possui representa¸cões para vários dos tipos de estruturas de dados como mapas, conjuntos, listas, árvores, tabelas e outras cole¸cões. Além disso, o desenvolvedor pode implementar as interfaces do framework para criar as suas próprias representa¸cões.. 2.3.2. Simple API for XML (SAX). Normalmente, SAX ([3, 5, 27, 30]) não é apresentado como um framework mas como uma API (Simple API for XML). Nós argumentamos que SAX tem um fluxo de controle bem definido (n´ ucleo) e que este fluxo faz chamadas a classes.

(18) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 18. desenvolvidas pelo usuário que representam as implementa¸cões dos hot spots de SAX. SAX representa um mecanismo, orientado a eventos, de tratamento (parsing) de arquivos XML. Durante o processamento, à medida que o parser SAX identifica um elemento (por exemplo, o in´ıcio ou o fim de uma tag ou de um dos seus atributos), ele invoca o tratador do evento de elemento. O tratador de eventos, que deve implementar uma das interfaces definidas pelo framework, representa o código espec´ıfico da aplica¸cão e deve ser criado pelo desenvolvedor.. 2.3.3. SalesPoint Framework. O SalesPoint é um framework usado para criar simula¸cões de aplica¸cões de pontode-venda ([2]). Um ponto-de-venta pode ser um simples máquina de refrigerantes ou um complexo supermercado com vários departamentos. Tipicamente, uma aplica¸cão SalesPoint é composta de uma loja (representada pela classe Shop), onde clientes (classe Customer ) são atendidos em um determinado n´ umero de caixas ou pontos-de-venda (classe Counter ). Os clientes possuem cestas (classe DataBasket) que contêm os itens selecionados por eles. Estes itens são pagos ou cancelados no caixa. Os hot spots do framework permitem: • A adapta¸cão das classes de dados (por exemplo, a classe DataBasket); • A implementa¸cão da funcionalidade da aplica¸cão através do SalesPoint Process Model ; • A cria¸cão de um visual conveniente para os dados e processos adaptados (através dos vários componentes prontos do framework).. 2.4. Problemas da composi¸ c˜ ao de frameworks. Tradicionalmente, o desenvolvimento baseado em frameworks baseia-se no reuso de um u ńico framework através da extensão de suas classes. Recentemente, como já mencionado do Cap´ıtulo 1, o aumento da complexidade das aplica¸cões tornou necessário o uso de mais de um framework na implementa¸cão das solu¸cões de um determinado dom´ınio. O processo de composi¸cão de frameworks pode causar diversos problemas. Estes problemas são, normalmente, causados por que os framework são contru´ıdos de acordo com a perspectiva tradicional, assumindo que o framework estará no controle do fluxo principal da aplica¸cão, que ele será instanciado por extensão (e não por composi¸cão) e que outros componentes não serão inseridos [21]. A seguir descrevemos brevemente alguns dos problemas mais comuns da composi¸cão de frameworks..

(19) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 2.4.1. 19. Composi¸ c˜ ao do fluxo de controle. Trabalhos reportados em [24, 20] e [21] apresentam descri¸cões de algumas formas de composi¸cão de frameworks, assim como uma lista de tipos de problemas que podem surgir da composi¸cão. Antes de descrever o problema da composi¸cão de frameworks, vamos introduzir as formas de composi¸cão. • Sem comunica¸cão ´ a forma mais simples de composi¸cão. Ocorre quando os dois frameworks E funcionam de forma concorrente e sem compartilhamento de recursos. • Seq¨ uencial Nesta forma de composi¸cão, temos a execu¸cão completa de um dos frameworks seguida da execu¸cão completa do outro. A inicializa¸cão do segundo framework é feita pelo primeiro ao término da sua execu¸cão. • Unidirecional Nesta forma de composi¸cão, apenas um framework chama o outro, sendo que essas chamadas podem ou não ter retorno e/ou parâmetros. • Bidirecional ´ a forma mais complexa de composi¸cão, nela ambos os frameworks fazem E chamadas ao outro. Vale a pena voltar a afirmar que as chamadas podem ser com ou sem parâmetros e/ou retorno. Descri¸ c˜ ao do problema Uma das principais caracter´ısticas dos frameworks é o uso extensivo de vincula¸cão dinâmica de tipos (dynamic-binding). Isso não deveria ser nenhuma surpresa neste ponto, já que sabemos que um framework é composto de classes abstratas e concretas e que ele define a intera¸cão entre instâncias de suas classes concretas e/ou de especializa¸cões das suas classes. A defini¸cão do tipo do objeto pode ser feita em tempo de execu¸cão. Normalmente, o framework possui uma thread de controle u ńica que faz chamadas ao código espec´ıfico da aplica¸cão sempre que for necessário. Este comportamento é freq¨ uentemente chamado de “O Princ´ıpio de Hollywood” (“don´t call us, we´ll call you”). Quando mais de um framework chama o código da aplica¸cão simultaneamente, cada um esperando estar no controle do fluxo principal da aplica¸cão (no nosso caso, da composi¸cão), ocorre um problema chamado de “inversão do fluxo de controle”. Poss´ıveis solu¸c˜ oes A solu¸caõ do problema da composi¸cão do fluxo de controle (ou inversão do fluxo de controle) irá, indubitavelmente, requerer a adapta¸cão dos fluxos dos frameworks envolvidos. Existem três técnicas para a adapta¸cão dos frameworks envolvidos:.

(20) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 20. • Concorrência Cada um dos frameworks envolvidos pode ter um fluxo de controle independente, concorrente com os outros. Essa abordagem só pode ser usada nos casos onde não há a necessidade de comunica¸cão (notifica¸cão) entre os frameworks. Uma desvantagem da abordagem é que todas os objetos espec´ıficos da aplica¸cão que podem ser acessados por ambos os frameworks devem ser extendidos com código de sincroniza¸cão. A vantagem da abordagem é a não necessidade de acesso ao código fonte dos frameworks. • Encapsulamento Essa técnica consiste em criar wrappers dos componentes (classes que encaplusam os componentes) dos frameworks envolvidos. Os wrappers interceptariam todas as mensagens enviadas de e para os frameworks e delegariam as a¸cões para os frameworks ([29]). A vantagem da técnica é que ela permite que os componentes originais dos frameworks permane¸cam inalterados. A desvantagem é a impossibilidade do tratamento dos eventos internos dos frameworks, apenas eventos externos aos frameworks podem ser tratados ou interceptados. • Reescrita de código Se a integra¸cão de todos os eventos (internos e externos) dos frameworks for necessária, a solu¸cão será remover as partes relevantes dos fluxos de controle dos frameworks e substitu´ı-las com código espec´ıfico da aplica¸cão. A distribui¸cão do fluxo de controle entre os componentes do framework (comportamento coesivo) e a falta de acesso ao código fonte são fatores que podem dificultar ou inviabilizar a solu¸cão.. 2.4.2. Integra¸ c˜ ao com sistemas legado e ferramentas existentes. Descri¸ c˜ ao do problema Idealmente, frameworks contém apenas funcionalidades genéricas para o seu dom´ınio ´ comum surgir a necessidade de reuso de componentes prontos esde aplica¸cão. E pec´ıficos da aplica¸cão a ser desenvolvida. A integra¸cão desses componentes ao framework nem sempre é uma tarefa trivial, pois o comportamento coesivo do framework pode dificultar a substitui¸cão de suas classes. Outro fator complicante é o fato dos frameworks se basearem em mecanismos de instancia¸cão por heran¸ca e não por composi¸cão..

(21) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 21. Poss´ıveis solu¸c˜ oes • Adapter design pattern O Adapter Design Pattern é um dos quatro patterns estruturais listados em [10]. Ele é muito usado em casos onde desejamos reusar uma classe mas a interface da aplica¸cão não é compat´ıvel com a classe. O adapter ou wrapper é usado para converter a interface da aplica¸cão para a interface esperada pela classe. O problema de integra¸cão com sistemas legado é um exemplo t´ıpico de uso desse design pattern. A figura abaixo ilustra o funcionamento do pattern. No cenário, o Client deseja invocar o método request() da interface Target. Como a classe Adaptee não possui o método request(), é fun¸cão do Adapter converter a chamada para uma chamada a um método equivalente do Adaptee ([6]).. Figura 2.1: Adaptando a interface da classe Adaptee A desvantagem da solu¸cão é o overhead de implementa¸cão, pois cada método do componente legado irá requerer código de adapta¸cão. • Altera¸cão do framework Essa solu¸cão consiste da substitui¸cão do código referente à classe do framework por código que use o componente legado. Obviamente, a solu¸cão é impossibilitada quando há falta de acesso ao código fonte.. 2.4.3. Framework gap. Descri¸ c˜ ao do problema Esse problema ocorre quando a composi¸cão de dois ou mais frameworks não satisfaz todos os requisitos da aplica¸cão..

(22) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 22. Poss´ıveis solu¸c˜ oes • Encapsulamento Caso o framework composto (resultado da composi¸cão) não assuma o controle do fluxo principal da aplica¸cão, o problema pode ser resolvido através do seu encapsulamento e da complementa¸cão das funcionalidades necessárias da aplica¸cão. A vantagem da solu¸cão é a não necessidade de altera¸cão do código do framework composto. • Software mediador Caso o framework composto assuma o controle do fluxo principal da aplica¸cão, o problema só pode ser solucionado através da implementa¸cão de código para notificar um framework dos eventos ocorridos no outro. Uma desvantagem clara da solu¸cão é a dificuldade de implementa¸cão, pois o código terá que gerenciar a intera¸cão entre os framework além de prover a funcionalidade necessária para “fechar o gap”. Outra desvantagem é a vulnerabilidade do código mediador (e da aplica¸cão) a evolu¸cões dos frameworks. • Altera¸cão do framework Quando existe a inten¸cão de reusar o framework em outras aplica¸cões, a solu¸cão mais interessante é a altera¸cão do código fonte para que o framework obtenha uma maior cobertura do dom´ınio da aplica¸cão.. 2.4.4. Sobreposi¸ c˜ ao de entidades dos frameworks. Descri¸ c˜ ao do problema Esse problema ocorre quando dois ou mais frameworks possuem representa¸cões para entidades do mundo real sob diferentes perspectivas. Isso pode ocorrer quando ambos os frameworks englobam as mesmas partes do dom´ınio de aplica¸cão. Poss´ıveis solu¸c˜ oes • Heran¸ca m´ ultipla Essa solu¸cão só pode ser aplicada quando as representa¸cões são mutuamente exclusivas. O ponto chave da solu¸cão é suportar atualiza¸cões e conversões necessárias entre os diferentes frameworks. • Agrega¸cão A solu¸cão consiste da cria¸cão de uma classe que contenha ambas as representa¸cões como suas partes. Essa nova classe seria a representa¸cão agregada da entidade na aplica¸cão..

(23) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 23. Além do acesso ao código fonte de ambos os frameworks, a solu¸cão requer a substitui¸cão de todas as referências à representa¸cão original pela representa¸cão agregada. As maiores desvantagens dessa solu¸cão são a necessidade de acesso e altera¸cão do código fonte de ambos os frameworks. Vale notar que a terminologia utilizada nesta se¸cão faz referência a classes, e não a frameworks especificamente, pois as classes dos frameworks são utilizadas para representar as entidades do mundo real.. 2.4.5. Integra¸ c˜ ao de funcionalidades de diferentes frameworks. Descri¸ c˜ ao do problema Esse problema ocorre quando um componente tem que ser modelado a partir de funcionalidades de diferentes frameworks. Um exemplo t´ıpico é a integra¸cão entre os frameworks das camadas de interface gráfica (GUI), regra de negócio e persistência de um software estruturado em camadas. A integra¸cão das respectivas classes dos diferentes frameworks através de heran¸ca m´ ultipla ou agrega¸cão não é suficiente para a resolu¸cão do problema pois, por exemplo, mudan¸cas feitas em uma entidade na camada de regra de negócio podem refletir atualiza¸cões na representa¸cão da entidade na interface gráfica e na camada de persistência. Poss´ıveis solu¸c˜ oes • Agrega¸cão ou heran¸ca m´ ultipla ´ a solu¸cão mais simples para o problema. Seu u E ńico problema é que as altera¸cões do estado de uma entidade em um dos frameworks não irão influenciar as partes de sua representa¸cão nos outros frameworks. Torna-se necessário então a extensão da funcionalidade dos frameworks para que altera¸cões feitas neles causem notifica¸cões nos outros. • Observer design pattern A complementa¸cão da solu¸cão acima pode ser obtida através da extensão do comportamento dos frameworks com comportamento de notifica¸cão, através do design pattern Observer.. 2.5. Considera¸c˜ oes finais. A composi¸cão de frameworks, no projeto e implementa¸cão de aplica¸cões, oferece grande potencial para reuso e extensibilidade em larga escala. Entretanto, estudos na literatura mostram que compor frameworks pode resultar em efeitos colaterais.

(24) ˜ A FRAMEWORKS CAPÍTULO 2. INTRODUC ¸ AO. 24. inesperados. A seguir apresentamos uma compara¸cão entre frameworks e outras formas de reuso. • Frameworks X Bibliotecas de classe O escopo de reutiliza¸cão e o gerenciamento do fluxo de controle são os principais pontos de distin¸cão entre frameworks e bibliotecas de classes. Enquanto frameworks definem aplica¸cões incompletas para um determinado dom´ınio, bibliotecas de classes apresentam solu¸cões de uso mais geral, menos espec´ıficas de dom´ınio e de maior escopo de reutiliza¸cão. Frameworks podem gerenciar o fluxo de controle dentro da aplica¸cão enquanto que bibliotecas de classes são tipicamente passivas, ou seja, não influenciam diretamente no fluxo de controle da aplica¸cão. • Frameworks X Design Patterns Enquanto frameworks focam a reutiliza¸cão de designs concretos, algoritmos e implementa¸cões em uma linguagem de programa¸cão particular, os design patterns focam a reutiliza¸cão de designs abstratos e micro-arquiteturas de software. A combina¸cão de frameworks e design patterns tende a ser muito sinérgica, mais de um design pattern pode ser utilizado em um framework. • Frameworks X Componentes Componentes são entidades caixa-preta que definem opera¸cões coesivas e que, para serem reutilizados, basta que se tenha conhecimento da sintaxe e da semântica de sua interface. O fato de os componentes serem bastante coesos constitui um fator de distin¸cão entre eles e frameworks, uma vez que a coesão entre as classes de um framework deve ser mantida em n´ıveis gerenciáveis se o framework for implementado para permitir reuso por composi¸cão. Assim como acontece com os design patterns, a combina¸cão de frameworks e componentes tende a ser altamente sinérgica e vários componentes podem ser utilizados em um framework. Neste cap´ıtulo, nós apresentamos brevemente o que são frameworks e quais os problemas que podem ocorrer durante a sua composi¸cão. Nos próximos cap´ıtulos nós abordaremos o problema da composi¸cão de fluxos de controle de especifica¸cões CSP-Z de frameworks..

(25) Cap´ıtulo 3 Vis˜ ao geral: CSP, Z e CSP-Z Uma das formas de melhorar a qualidade dos sistemas é melhorar a forma na qual eles são documentados desde os requisitos até a implanta¸cão. Componentes interagem de formas não esperadas e ocorrem interferências nos seus comportamentos, possivelmente gerando propriedades indesejáveis. Os métodos de documenta¸cão usualmente adotados envolvem grande quantidade de texto, imagens e diagramas, mas são normalmente imprecisos e ambiguos. Detalhes importantes podem ser ocultados por informa¸cões irrelevantes, fazendo com que falhas de projeto sejam descobertas tarde demais. Linguagens de especifica¸cão formal baseadas em matemática elementar, por outro lado, podem ser usadas para produzir uma documenta¸cão precisa na qual a informa¸cão é apresentada de forma estruturada e em um n´ıvel apropriado de abstra¸cão. O objetivo deste cap´ıtulo é introduzir as linguagens usadas no nosso trabalho e apresentar os seus operadores e caracter´ısticas mais relevantes.. 3.1. CSP. CSP [16] usa eventos para definir os padrões de comportamento de objetos do mundo real (processos). Primeiramente, devemos definir quais eventos são relevantes no comportamento do processo, e cada evento deve ser identificado com um nome u ńico. Cada evento escolhido e nomeado representa um tipo de evento e pode haver várias ocorrências do mesmo tipo de evento no comportamento de um determinado processo. O conjunto dos tipos de eventos relevantes de um processo é chamado de alfabeto. A ocorrência de um evento no comportamento de um processo é considerada instantânea ou atômica. A¸cões extensas ou que consomem tempo devem ser representadas por um par de eventos, o primeiro representando o seu in´ıcio e o segundo, o seu fim.. 3.1.1. Processos primitivos. CSP possui três processos primitivos que descrevemos a seguir. 25.

(26) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 26. • Stop - representa um processo em estado de deadlock (paraliza¸cão), que não aceita evento algum; • Skip - representa um processo que finalizou sua execu¸cão com sucesso; • DIV - representa um processo em estado de livelock.. 3.1.2. Prefixo. Seja x um evento e P um processo, então (x → P ) descreve o processo que inicialmente aceita o evento x e depois passa a se comportar como o processo P.. 3.1.3. Recurs˜ ao. O operador prefixo pode ser usado para descrever o comportamento de qualquer processo finito, embora isto possa se tornar praticamente inviável para processos que apresentam ciclos repetitivos. Surge, então, a necessidade de descrevermos processos repetitivos com uma nota¸cão mais prática ou compacta. Consideremos o processo infinito que representa um relógio cujo u ńico evento de interesse seja o tick. (tick → CLOCK ) O comportamente de CLOCK é a repeti¸cão indefinida de tick, o que pode ser represemtado pela equa¸cão: CLOCK = (tick → CLOCK ) Uma alternativa para definir recursão é através do operador µ. O processo CLOCK pode ser equivalentemente definido como CLOCK = µ X • tick → X. 3.1.4. Composi¸ c˜ ao seq¨ uencial. O operador de composi¸cão seq¨ uencial permite que um processo seja inicializado após o término da execu¸cão de um outro processo. Diferente do operador de prefixo, que permite a passagem de parâmetros entre eventos consecutivos, o operador de composi¸cão seq¨ uencial não permite a extensão o escopo das variáveis do primeiro processo até o segundo. Um processo P que inicialmente se comporta como um processo A e depois passa a se comportar como um processo B pode ser especificado da seguinte forma: P = A; B.

(27) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 27. O operador de composi¸cão seq¨ uencial também pode ser usado para especificar processos recursivos. A seguir apresentamos o processo recursivo R que executa uma série de eventos e depois volta ao seu estado inicial. R = (e1 → e2 → Skip); R Este processo equivale a R = (e1 → e2 → R). 3.1.5. Escolha. Através do uso de prefixos e recursões é poss´ıvel descrever o comportamento de processos com uma sequência u ńica de eventos. Porém, usualmente é necessário representar processos que têm seus comportamentos (ou suas seq¨ uências de eventos) influenciados por fatores externos. O processo abaixo, por exemplo, aceita inicialmente um dos eventos a ou b e depois passa a se comportar como A, quando o evento ocorrido for a, ou B , quando o evento ocorrido for b. (a → A) | (b → B ) O operador | é o operador de escolha. A escolha entre os poss´ıveis comportamentos do processo acima depende do ambiente; dizemos que tal escolha é determin´ıstica. Existem processos com mais de uma possibilidade de comportamento e cuja sele¸cão entre os comportamentos (ou seq¨ uências de eventos) não sofre qualquer influência do ambiente e talvez até nem seja observável pelo ambiente. Estes processos são chamados de não-determin´ısticos. Sejam P e Q dois processos, então P uQ denota o processo que pode se comportar como P ou Q, arbitrariamente. O operador u (escolha interna) nos permite manter um alto n´ıvel de abstra¸cão na descri¸cão do comportamento dos processos. Apesar de não ser muito u ´til na implementa¸cão, este operador é muito usado na especifica¸cão de processos. Especifica¸cões não determin´ısticas podem ser usadas para representar hot spots dos frameworks. Um hot spot especificado como o processo acima pode ser instanciado tanto através do processo P quanto através do processo Q. Existe um terceiro operador que permite que o ambiente controle a escolha entre as op¸cões de comportamento, o operador de escolha externa 2. A escolha é feita na ocorrência do primeiro evento de cada uma das op¸cões de comportamento. No processo (P 2 Q) caso o primeiro evento não seja um poss´ıvel evento inicial de P , o processo irá se comportar como Q e vice-versa. Porém, se o primeiro evento for um evento inicial.

(28) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 28. de ambos os processos, a escolha entre eles será não-determin´ıstica. Quando os conjuntos de eventos iniciais de P e Q forem disjuntos, o operador é equivalente ao primeiro operador apresentado |. Por exemplo, (a → P ) 2 (b → Q) = (a → P ) | (b → Q). 3.1.6. Paralelismo. Quando dois processos são postos em execu¸cão concorrentemente, normalmente se deseja que eles interajam. As intera¸cões podem ser vistas como eventos que ´ imrequerem a participa¸cão (ou aceita¸cão) simultânea de ambos os processos. E portante destacar que o ambiente também pode ser tratado como um processo, o que nos permite simular o comportamento de um processo em conjunto com o seu ambiente. Sejam P e Q processos com alfabetos iguais, então P || Q é o processo que representa os processos P e Q com todos os seus eventos sincronizados. Se um dos eventos for aceito por apenas um dos processos, ele não poderá ocorrer. Quando os alfabetos de P e Q não são iguais, cada um deles pode aceitar os eventos fora da interse¸cão dos dois alfabetos independentemente. Uma outra versão do operador de paralelismo explicita os eventos nos quais os processos irão sincronizar. O processo P [| X |]Q sincroniza P e Q nos eventos X . Tanto P quanto Q podem interagir independentemente com o ambiente através de eventos que não perten¸cam a X . Uma outra varia¸cão do operador de paralelismo, chamada de interleaving, permite unir processos concorrentes sem intera¸cão ou sincroniza¸cão entre eles. O comportamento do interleaving de dois processos é idêntico ao paralelismo alfabetisado de dois processos, onde o conjunto de sincroniza¸cão X é vazio. Cada evento oferecido ao interleaving de dois processos, ocorre apenas em um deles. Caso ambos estejam dispostos a aceitar o evento, a escolha entre os processos é não-determin´ıstica. Esse tipo de combina¸cão é especificado da seguinte forma: P ||| Q Nós usaremos o operador ||| para especificar as poss´ıveis threads de um determinado processo, como por exemplo todas as threads de execu¸cão de um servidor multi-thread, onde cada thread terá um identificador u ńico.. 3.1.7. Comunica¸ c˜ ao. Até agora nós falamos de eventos apenas como um meio de caracterizar o comportamento e a sincroniza¸cão dos processos. Entretanto, a sincroniza¸cão não é o.

(29) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 29. u ńico tipo de intera¸cão poss´ıvel. Pode surgir a necessidade de um processo passar para ou receber informa¸cões de outros processos ou do ambiente. Em CSP, uma comunica¸cão é descrita como um par c.v , onde c é o nome do canal e v é o valor da mensagem (ou o parâmetro) enviada pelo canal. Uma comunica¸cão é um tipo de evento e pode ser tratrada como tal em todos os operadores e conceitos de CSP. Uma comunica¸cão pode envolver um ou mais parâmetros. Existem parâmetros de entrada e de sa´ıda, comunicados ou recebidos pelo processo, respectivamente. Um processo que inicialmente comunica v pelo canal c e depois passa a se comportar como P é definido como c!v → P = c.v → P Um processo que inicialmente recebe o valor v pelo canal c é definido como c?v → P ´ uma conven¸cão usar canais apenas para um tipo ou dire¸cão de comunica¸cão. E Nos exemplos vistos posteriormente, as comunica¸cões que envolvam parâmetros de ida e de volta serão especificados com mais de um canal. Usaremos um processo apresentado em um dos exemplos do Cap´ıtulo 4 como exemplo mais completo de um processo CSP. O processo recursivo CLIENTE apresenta canais que recebem parâmetros do ambiente (precedidos por “?”) e canais que recebem parâmetros de eventos anteriores (precedidos por “.”). Ele também apresenta o operador de escolha interna, o que o torna não determin´ıstico. A seguir descrevemos o seu comportamento. O processamento do CLIENTE é iniciado pelo evento recebeDadosDoUsuario (DadosCliente). Depois disto, ele passa a aceitar o evento validaDados(DadosCliente) que pode ser seguido por qualquer um dos eventos dadosValidos() ou dadosInvalidos(ErroCliente). Dependendo de qual destes u ´ltimos eventos venha a ocorrer, o CLIENTE passa a aceitar o evento processarDados(DadosCliente), que será seguido pelos eventos obterResposta (RespostaCliente) e mostraResposta(RespostaCliente), ou o evento mostraMsgErro(ErroCliente). Após a execu¸cão de qualquer um desses fluxos, o CLIENTE volta ao seu estado inicial. CLIENTE = (recebeDadosDoUsuario?dados → validaDados.dados → ( dadosInvalidos?descErro → mostraMsgErro.descErro → Skip u dadosValidos → processarDados.dados → obterResposta?resp → mostraResposta.resp → Skip )); CLIENTE. 3.1.8. Traces. Um processo pode ser estudado pelo seu comportamento observável. Um trace de um processo é um registro de uma sequência finita de eventos que o processo já aceitou até o momento. Por exemplo:.

(30) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 30. • < x , y > - é um trace de um processo que aceita o evento x seguido do evento y; • < tick > - é o trace do processo CLOCK após a ocorrência do primeiro tick ; • <> - é o trace de um processo que ainda não aceitou evento algum. Uma análise dos traces dos processos será usada na nossa estratégia para identificar alguns eventos que podem ocorrer tanto na comunica¸cão dos frameworks compostos quanto em cada um deles independentemente da composi¸cão. Antes do in´ıcio do processo não podemos saber quais dos poss´ıveis traces serão de fato registrados. No entanto, o conjunto de todos os poss´ıveis traces finitos de um processo P pode ser determinado e é representado pela fun¸cão traces(P ). Embora os membros do conjunto resultado da fun¸cão traces(P ) sejam finitos, o conjunto representado por traces(P ) pode ser infinito. A defini¸cão de traces() é indutiva na estrutura de P e pode ser encontrada, por exemplo, em [26].. 3.1.9. Falhas. O modelo de traces nos informa o que um processo pode fazer, mas não o que ele deve fazer. A distin¸cão entre os processos (P u Q) e (P 2 Q) não pode ser feita pela compara¸cão de seus traces, pois todos os traces de um deles são possiveis traces do outro. No entanto, os seus comportamentos podem ser completamente diferentes. O primeiro processo pode se comportar tanto como P quanto como Q. Supondo que a escolha (interna) seja pelo comportamento de P, o processo pode entrar em deadlock se o ambiente só disponibilizar o evento inicial de Q. E isto não aconteceria com o segundo processo. Para podermos distinguir o comportamento dos processos acima, precisamos observar o que eles podem se recusar a fazer, além do que eles podem fazer. Quando uma escolha interna entre dois processos é feita por um deles, dizemos que o outro foi recusado. As recusas de eventos iniciais de processos ou de partes de uma especifica¸cão serão usadas na nossa estratégia para identificar e eliminar possiveis deadlocks nos pontos de comunica¸cão entre os frameworks. O conjunto de eventos que um processo não pode aceitar indefinidamente é chamado de recusa. O conjunto de recusas iniciais de um processo P é representado pela fun¸cão refusals(P ). Uma falha é caracterizada por uma sequência s de eventos, que representa os eventos já ocorridos até o momento, e pelo conjunto de eventos R que não serão aceitos após a ocorrência dos eventos da seq¨ uência. As falhas de um processo P são calculadas pela fun¸cão failures(P ). failures(P ) = {(s, R) | s ∈ traces(P ) ∧ R ∈ refusals(P /s)} Na defini¸cão acima, P /s representa o processo P após o trace s. Um processo é dito determin´ıstico se ele nunca recusa um evento que ele esteja disposto a aceitar..

(31) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 3.1.10. 31. Divergˆ encias. Uma divergência de um processo é definida como um trace depois do qual o processo se comporta de forma imprevis´ıvel ou caótica. Um exemplo deste tipo comportamento é o de um processo que executa uma seq¨ uência infinita de eventos ocultos (ou não observáveis), como o processo D abaixo. D = (a → b → D)\{a, b} Os eventos a e b ocorrerão infinitamente e sem influência nem observa¸cão do ambiente, não permitindo que o processo D se comunique com o ambiente. O operador de hiding (\{X }) torna todos os eventos do conjunto X ocultos para o ambiente.. 3.2. Z. A linguagem Z [33, 31] é uma linguagem formal de fácil aprendizado e aplica¸cão, baseada na teoria de conjuntos e em lógica de primeira ordem. Enquanto CSP oferece operadores que permitem capturar aspectos de controle de um sistema, Z é mais adequada à modelagem de dados e tipos abstratos. Objetos do mundo real são representados por esquemas Z. Os esquemas podem ser usados tanto para representar o estado de um sistema e as formas nas quais ele pode ser alterado quanto para descrever as suas opera¸cões e possibilitar a análise dos seus poss´ıveis refinamentos. Esquemas são um poderoso mecanismo de estrutura¸cão que, em combina¸cão com linguagem natural, podem ser usados para especifica¸cões formais [33]. Veremos mais detalhes sobre os esquemas Z na próxima se¸cão. Uma das caracter´ısticas importantes de Z é o uso de tipos. Todos os objetos matemáticos possuem um tipo u ńico, que é representado por um conjunto de valores poss´ıveis.. 3.2.1. Free types. Antes de falarmos sobre esquemas, vamos introduzir uma forma mais simples de defini¸cão de tipos em Z , os Free types. O caso mais simples de utiliza¸cão de Free types é quando queremos definir um conjunto restrito de valores. Vamos tomar por exemplo o conjunto dos meses do ano. Numa linguagem de programa¸cão qualquer, este conjunto poderia ser definido da seguinte forma: MesesDoAno = {Jan, Fev , Mar , Abr , Mai, Jun, Jul , Ago, Set, Out, Nov , Dez } Em Z , este mesmo conjunto poderia ser definido como a seguir, MesesDoAno == {Jan, Fev , Mar , Abr , Mai, Jun, Jul , Ago, Set, Out, Nov , Dez }.

(32) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 32. Porém, as formas acima não fazem nenhuma inferência sobre os elementos do conjunto. Nada garante que, por exemplo, Janeiro e Fevereiro são valores distintos. A seguinte defini¸cão do Free type MesesDoAno introduz um conjunto de doze constantes distintas. MesesDoAno == Jan | Fev | Mar | Abr | Mai | Jun | Jul | Ago | Set | Out | Nov | Dez Apesar do exemplo apresentado acima ser bastante simples, os Free types são um poderoso mecanismo de Z e podem ser usados na defini¸cão de cole¸cões, objetos compostos e estruturas recursivas.. 3.2.2. Esquemas. A nota¸cão de Z envolve duas linguagens: a linguagem matemática e a linguagem de esquemas. A linguagem matemática é usada para descrever vários aspectos de um objeto ou sistema. A linguagem de esquemas é usada para estruturar e compor essas descri¸cões: agrupando, encapsulando e nomeando informa¸cões para permitir o seu reuso. Esquemas podem ser usados na defini¸cão de tipos e de suas opera¸cões. Um esquema consiste de duas partes: a declara¸cão de suas variáveis e os seus predicados (ou propriedades) que impõem condi¸cões sobre os valores das variáveis. Os predicados representam as pré e pós-condi¸cões de um esquema. Existem duas formas de escrevermos o conte´ udo de um esquema: • Horizontal b [declaracao | predicado] NomeDoEsquema =. • Vertical NomeDoEsquema declaracao predicado Esquemas podem ser usados na defini¸cão de tipos compostos (registros). Por exemplo, o esquema abaixo pode representar os dados do processo CLIENTE (apresentado na se¸cão anterior). O atributo c representa a lista de poss´ıveis pedidos (o menu) e o atributo vontade representa as preferências do cliente. O predicado restringe as preferências do cliente às op¸cões de menu. CLIENTE c : Pedidos vontade : OpcaoMenu vontade ∈ c ´ poss´ıvel referenciar os elementos de um esquema através de um operador de E sele¸cão. Por exemplo, se cli é do tipo CLIENTE , então cli .vontade representa a sua preferência..

(33) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 33. Alterando o estado de um esquema Quando desejamos usar um esquema para descrever opera¸cões sobre o estado, usamos duas cópias do esquema: uma para representar o seu estado antes e outra depois da opera¸cão. A distin¸cão entre as cópias é feita através da decora¸cão do esquema que representa o estado após a opera¸cão: CLIENTE 0 c 0 : Pedidos vontade 0 : OpcaoMenu vontade 0 ∈ c 0 A seguir descrevemos uma opera¸cão que atribui um valor ao componente c do cliente. O predicado do esquema caracteriza o comportamento (pré e póscondi¸cões) da opera¸cão. com recebeCardapio CLIENTE CLIENTE 0 c? : Pedidos c 0 = c? vontade 0 = vontade A inclusão das duas cópias de CLIENTE indica que c, vontade, c 0 e vontade 0 constituem um estado válido do sistema. As opera¸cões podem envolver trocas de informa¸cões com o ambiente (parâmetros de entrada e/ou de sa´ıda). Os parâmetros são representados pelas variáveis declaradas no esquema da opera¸cão. Convenciona-se que parâmetros de entrada (recebidos do ambiente) devem ter seus nomes terminados por “?” e parâmetros de sa´ıda (enviados para o ambiente) devem ter seus nomes terminados por “!”. Convenciona-se também que, se CLIENTE é um esquema, então ∆CLIENTE é um esquema que inclui CLIENTE e CLIENTE 0 . Logo, a opera¸cão acima pode ser escrita da seguinte forma: com recebeCardapio ∆CLIENTE c? : Pedidos c 0 = c? vontade 0 = vontade Podem haver opera¸cões nas quais o estado não é alterado, os valores antes e depois da sua execu¸cão são idênticos. Convenciona-se que ΞCLIENTE denota que o esquema inclui CLIENTE e CLIENTE 0 , onde os valores de CLIENTE são idênticos aos valores de CLIENTE 0 ..

(34) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 34. com chamaGarcom ΞState m? : Mesa O esquema acima descreve uma opera¸cão que recebe um parâmetro do ambiente mas que não altera o estado do CLIENTE .. 3.3. CSP-Z. A linguagem CSP-Z é uma integra¸cão entre CSP e Z, onde CSP trata os aspectos de concorrência de um sistema enquanto que Z trata as estruturas de dados [22]. A combina¸cão é tal que o refinamento de qualquer das partes (CSP ou Z) resulta no refinamento da especifica¸cão completa, desde que obedecidas certas condi¸cões [12]. Nos exemplos, ora nós refinamos a parte Z, ora refinamos a parte CSP das especifica¸cões para representar as instâncias dos frameworks. De acordo com [12], uma especifica¸cão CSP-Z SPEC 2 é um refinamento de uma outra especifica¸cão CSP-Z SCPEC 1 se: • A parte Z de SPEC 2 for um refinamento da parte Z de SPEC 1. Isto ocorre quando as opera¸cões de SPEC 2 tiverem pré-condi¸cões mais fracas e póscondi¸cões mais fortes que as de SPEC 1 e quando todos os poss´ıveis estados iniciais de SPEC 2 corresponderem a algum estado inicial de SPEC 1; • As partes CSP das especifica¸cões não tiverem “acesso interno” às variáveis dos esquemas Z. Ou seja, o processo CSP não deve referenciar qualquer variável do esquema Z; • A parte CSP de SPEC 2 for um refinamento válido da parte CSP de SPEC 1. Semanticamente, as partes de uma especifica¸cão CSP-Z são combinadas em paralelo, com a parte Z interpretada como um processo CSP. A forma de tal processo é a escolha externa entre as transi¸cões de estado (as combina¸cões entre a parte CSP e Z de cada opera¸cão e o seu efeito no estado do processo). O paralelismo é feito através dos nomes dos canais, onde a ocorrência de cada evento ev da parte CSP corresponde à ativa¸cão do esquema com ev da parte Z. Um evento da parte CSP só pode ocorrer quando o predicado (as pré-condi¸cões) do esquema Z correspondente é satisfeito; o mesmo acontece quando as variáveis de sa´ıda do esquema Z não podem ser comunicadas pelo evento CSP [23].. 3.3.1. Exemplo ilustrativo. Uma especifica¸cão CSP-Z consiste de uma interface e das partes CSP e Z, entre as palavras-chave spec e end spec. A interface é representada pela lista de declara¸cões de canais. A parte CSP é representada pelo um processo CSP main.

(35) ˜ GERAL: CSP, Z E CSP-Z CAPÍTULO 3. VISAO. 35. cujo alfabeto contenha apenas canais declarados na interface. A parte Z é composta de diversos esquemas, um deles representando o estado do processo, outro representando a inicializa¸cão do processo e tantos outros quantos forem os canais declarados na interface. Estes u ´ltimos são os responsáveis pela comunica¸cão direta entre entre as partes CSP e Z da especifica¸cão. Apresentamos, como exemplo ilustrativo, um processo CSP-Z que representa uma urna de vota¸cão que permite que o usuário, após a inicializa¸cão, escolha entre dois candidatos ou vote nulo ou em branco. A parte CSP é responsável pela seq¨ uência de eventos enquanto que parte Z da especifica¸cão é responsável pela totaliza¸cão dos votos. A seguir apresentamos a especifica¸cão CSP-Z completa. spec URNA channel inicializa channel candidato1 channel candidato2 channel brancoNulo A interface da urna consiste dos canais iniciaVotacao, candidato1, candidato2 e brancoNulo representando as opera¸cões de inicio da vota¸cão, voto no candiadato 1, voto no candidato2 e voto branco ou nulo, respectivamente. main = iniciaVotacao → (candidato1 → main) 2 (candidato2 → main) 2 (brancoNulo → main) O processo main acima representa as poss´ıveis seq¨ uências de opera¸cões da urna. As altera¸cões do estado da urna, causadas por cada uma das opera¸cões são realizadas pelas opera¸cões apresentadas abaixo. URNA votosCand 1 : N votosCand 2 : N brancosNulos : N O estado da urna armazena as quantidades de votos nos candidatos e a quantidade de votos nulos e brancos. Init URNA0 votosCand 10 = 0 votosCand 20 = 0 brancosNulos 0 = 0.