Mapeando CSP em UML-RT

Texto

(1)Pós-Graduação em Ciência da Computação. “Mapeando CSP em UML-RT” Por. Manoel Messias da Silva Menezes Junior Dissertação de Mestrado. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, FEVEREIRO/2008.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Manoel Messias da Silva Menezes Junior. “Mapeando CSP em UML-RT”. 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: Prof.. Dr. Augusto Sampaio. RECIFE, FEVEREIRO/2008.

(3) Menezes Junior, Manoel Messias da Silva Mapeando CSP em UML-RT / Manoel Messias da Silva Menezes Junior. – Recife: O Autor, 2008. xi, 182 folhas : il., fig., tab. Dissertação (mestrado) – Federal de Pernambuco. CIn. Computação, 2008.. Universidade Ciência da. Inclui bibliografia e anexo. 1. Engenharia de software. formais. I. Título. 005.1 076. CDD (22.ed.). 2.. Métodos MEI2008-.

(4) A meus pais que me ensiram a arte de ser um otimista..

(5) Agradecimentos. Agradeço especialmente ao Prof. Dr. Augusto Sampaio pela orientação fornecida durante o mestrado, sempre disponível para esclarecer dúvidas sobre o projeto. Agradeço-o também pelas disciplinas que ministrou, e, principalmente, pelo incentivo à conclusão deste projeto. Agradeço também aos professores que ministraram disciplinas importantes para este projeto. Em especial, agradeço ao Prof. Dr. Alexandre Mota pelas disciplinas ministradas e pelas sugestões fornecidas durante reuniões do grupo ForMULA. Agradeço aos integrantes do grupo ForMULA pelas sugestões que muito contribuíram para a melhoria deste trabalho. Agradeço a Patrícia Muniz Ferreira pela participação efetiva neste projeto. Agradeço também a Joabe Jesus pelas suas sugestões de melhoria. Agradeço a meus amigos Alberto Costa Neto, André Meneses, José Carlos, Márcio Ribeiro de Carvalho, Rohit Gheyi, Alan Kelon e Guilherme Esmeraldo pelo apoio que sempre me forneceram e pelos momentos de entretenimento. Agradeço a meus pais por sempre me incentivaram e estarem sempre presentes nos momentos mais difíceis. Agradeço a Deus por estar presente em cada um de nós.. ii.

(6) Há dois modos de construir um projeto de software: um é fazê-lo tão simples que obviamente não haja deficiências; o outro é fazê-lo tão complicado que não haja deficiências óbvias. O primeiro modo é muito mais difícil. —C.A.R. HOARE.

(7) Forte é aquele que tem força suficiente para reconhecer suas fraquezas. —MANOEL MESSIAS DA SILVA MENEZES (Meu pai).

(8) Resumo. A integração de métodos formais com notações semi-formais visuais é uma tendência em engenharia de software. Métodos formais apresentam uma semântica precisa e permitem verificação de propriedades. No entanto, não são considerados intuitivos. Por outro lado, notações semi-formais visuais, como UML, são facilmente integradas no processo de desenvolvimento de software. Assim, métodos formais e semi-formais visuais são complementares. CSP e UML-RT são, respectivamente, exemplos de notação formal e diagramática usados para especificar e projetar sistemas concorrentes e distribuídos. CSP é um método formal no qual processos representam unidades comportamentais que se comunicam através de canais de comunicação, utilizando passagem de mensagem. UML-RT é uma extensão conservativa de UML na qual cápsulas são unidades comportamentais que se comunicam através de portas de comunicação. Portas realizam protocolos os quais especificam os sinais que podem ser enviados e recebidos através de uma porta, e a ordem na qual os sinais podem ser comunicados. Em um trabalho anterior, Ferreira apresentou um conjunto de regras que sistematizam o mapeamento de CSP para UML-RT, mas uma prova formal deste mapeamento não foi apresentada. Assim, para garantir consistência no desenvolvimento de sistemas concorrentes e distribuídos utilizando este mapeamento, a prova formal do mesmo é indispensável, uma vez que não faz sentido o esforço dedicado à especificação do sistema em CSP e a verificação de propriedades e refinamentos, se uma ou mais regras de mapeamento estiverem incorretas. No entanto, UMLRT não possui uma semântica formal padrão. Entre outras propostas de semântica formal, Ramos propõe uma semântica para UML-RT utilizando OhCircus (uma combinação de CSP e Z com características adicionais de orientação a objetos) como modelo semântico. Neste trabalho, é proposta uma variação da semântica de Ramos para UML-RT usando CSP como modelo semântico. Com base nesta semântica, é apresentada a prova do mapeamento de CSP para UML-RT, considerando o modelo de falhas e divergências de CSP. Assim, este trabalho consolida a integração de CSP e UML-RT proposta por Ferreira, no desenvolvimento de sistemas críticos, concorrentes e distribuídos. Um resultado interessante foi observar que, estritamente, as regras propostas por Ferreira não preservam a semântica de CSP, essencialmente com relação a aspectos de terminação dos processos. Palavras-chave: Métodos Formais, Métodos Semi-formais, CSP, UML-RT, Regras de Tradução, Prova formal do mapeamento. v.

(9) Abstract. The integration of formal methods with semi-formal visual notations is a tendency in software engineering. Formal methods have a precise semantics and allow properties verification. However, they are not considered intuitive. On the other hand, semi-formal visual notations, like UML, are easily integrated in the software development process. Thus, formal methods and semi-formal ones are complementary. CSP and UML-RT are, respectively, examples of formal and semi-formal visual notation used to specify and design concurrent and distribute systems. CSP is a formal method where processes represent behavioral units that communicate through communication channels using message passing. UML-RT is conservative profile of UML where capsules are the behavioral units that communicate through ports. Ports realize protocols that specify the signals that can be sent or received through a port, and the order in which the signals can be communicated. In a previous work, Ferreira presented a set of rules that systematize the mapping from CSP to UML-RT, but a formal proof of this mapping was not presented. Thus, to guarantee consistence in the development of concurrent and distributed systems using this mapping, a formal proof of it is indispensable, since the effort dedicated to specifying systems in CSP, verifying properties and carrying out refinements does not make sense if some mapping rules from CSP to UML-RT are incorrect. However, there is not a formal standard semantics for UML-RT. Among other approaches to formal semantics, Ramos proposes a semantics for UML-RT using OhCircus (a combination of CSP and Z with additional features of object orientation) as semantic model. In this work, a variation of Ramos semantics for UML-RT, using CSP as semantic model, is proposed. Based on this semantics, a proof of the mapping from CSP to UML-RT is presented, considering the CSP semantic model of failures-divergences. Thus, this work consolidates the integration of CSP and UML-RT presented by Ferreira, in the development of concurrent and distributed critical systems. One interesting result was to note that, strictly, the rules proposed by Ferreira do not preserve the CSP semantics, mainly with respect to aspects of termination of processes. Keywords: Formal Methods, Semi-formal Methods, CSP, UML-RT, Translation Rules, Formal proof of the mapping. vi.

(10) Sumário. 1. Introdução. 1. 2. CSP 2.1 Definindo Processos 2.1.1 Processos Primitivos 2.1.2 Prefixo 2.1.3 Recursão 2.1.4 Escolhas Externa e Interna 2.1.5 Escolha Condicional 2.1.6 Internalização de Eventos 2.1.7 Renomeação de Eventos 2.1.8 Composição Seqüencial 2.1.9 Interrupção 2.1.10 Paralelismo 2.1.11 Operadores Indexados 2.2 Modelos Semânticos 2.3 Leis Algébricas. 5 7 8 8 9 9 10 10 11 11 11 11 12 12 14. 3. UML-RT 3.1 Cápsulas 3.2 Portas 3.3 Protocolos 3.4 Modelando a Estrutura 3.5 Modelando o Comportamento 3.6 Comunicação. 17 18 18 19 20 23 25. 4. Uma Semântica para UML-RT em CSP 4.1 Formalização 4.1.1 Mapeamento Estrutural 4.1.2 Mapeamento Comportamental 4.2 Considerações Adicionais. 28 28 29 32 34. 5. Prova do Mapeamento de CSP para UML-RT 5.1 Estratégia de Prova 5.2 Regras de Mapeamento 5.3 Aplicação da Estratégia de Prova sobre a Regra 5.1. 36 36 37 44. vii.

(11) SUMÁRIO. 5.4. 5.5 6. 5.3.1 Tradução do Lado Direito da Regra 5.1 5.3.2 Prova da Regra 5.1 5.3.3 Validação da Prova da Regra 5.1 Aplicação da Estratégia de Prova sobre a Regra 5.2 5.4.1 Tradução do Lado Direito da Regra 5.2 5.4.2 Prova da Regra 5.2 5.4.3 Validação da Prova da Regra 5.2 Considerações Adicionais. Conclusão 6.1 Trabalhos Relacionados 6.2 Trabalhos Futuros. A Provas das Regras de CSP para UML-RT. viii 44 47 54 55 56 60 88 89 91 92 94 96.

(12) Lista de Figuras. 2.1. Equações de Processos. 8. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10. Representação de cápsulas em diagramas de classes Representação de protocolos em diagramas de classes Máquina de estados do papel base de ProtocoloComunicacao Diagrama de estrutura de cápsula Cápsula P contendo instância ativa de Q Máquina de estados de cápsula Estados concorrentes Estados concorrentes Comunicação assíncrona entre cápsulas Comunicação síncrona entre cápsulas. 19 20 20 21 22 24 25 25 26 26. 4.1 4.2 4.3 4.4 4.5 4.6 4.7. Mapeamento de Protocolo Mapeamento de Cápsula Mapeamento de Diagrama de Estrutura Mapeamento de Estado Inicial Mapeamento de Estado de Escolha Mapeamento de Estado de Simples Mapeamento de Estado sem Transição de Saída. 29 30 32 33 34 34 35. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9. Estratégia de Prova das Regras Protocolo CSPMessageProtocol Máquina de estados do protocolo CSPMessageProtocol Protocolo CSPBehaviorProtocol Máquina de estados do protocolo CSPBehaviorProtocol Cápsula P representado o processo P = a -> Q(s’) Processos P e STRUCT SYSTEM CONTROLLER da Regra 5.1 no FDR Validação da Regra 5.1 no FDR Processos da Regra 5.2 no FDR. 37 38 38 39 40 41 55 56 88. A.1 A.2 A.3 A.4 A.5. Processos da Regra A.1 no FDR Processos da Regra A.2 no FDR Processos da Regra A.3 no FDR Processos da Regra A.4 no FDR Processos da Regra A.5 no FDR. 109 115 122 129 137 ix.

(13) LISTA DE FIGURAS. A.6 A.7 A.8 A.9 A.10. Processos da Regra A.6 no FDR Processos da Regra A.7 no FDR Processos da Regra A.8 no FDR Processos da Regra A.9 no FDR Processos da Regra A.10 no FDR. x 146 154 161 169 177.

(14) Lista de Tabelas. 5.1. Mapeamento de CSP para UML-RT. 39. xi.

(15) C APÍTULO 1. Introdução. O desenvolvimento de software dirigido a modelos (MDE - Model Driven Engineering) [Sel03, Ken02] é uma tendência em Engenharia de Software. Nesta abordagem, os principais artefatos produzidos durante o desenvolvimento são modelos, e não código fonte em uma determinada linguagem de programação. A principal característica do desenvolvimento dirigido a modelos é que o processo de desenvolvimento focaliza as atividades de modelagem de software, em contraste com as metodologias tradicionais nas quais modelos são utilizados apenas para fins de documentação. Além disso, transformações podem ser aplicadas com o objetivo de reestruturar ou refinar o modelo. Assim, tanto as transformações quanto os modelos são artefatos importantes nesta abordagem de desenvolvimento. A OMG (Object Management Group) [OMG07] tem padronizado notações e trabalhado na interoperabilidade de ferramentas. A especificação de MDA (Model-Driven Architecture) [MM06] e UML [RJB99] evidencia este fato. Atualmente, UML é uma notação padrão para a modelagem de sistemas, enquanto que MDA tem contribuído com padrões de interoperabilidade e portabilidade, dando suporte ao desenvolvimento dirigido a modelos. MDA define uma arquitetura que separa a especificação das funcionalidades do sistema da especificaçãao de como elas são implementadas. A especificação inicial é estruturada como um modelo independente de plataforma (PIM), que pode ser refinado em um ou mais modelos específicos de plataforma (PSM). O desenvolvimento de software de qualidade depende de os artefatos (modelos e transformações) não serem produzidos baseados na intuição [Hoa84]. É importante que os modelos tenham uma semântica formal a fim de que não gerem ambigüidades e expressem corretamente as propriedades do sistema. Além disso, a corretude das transformações deve ser provada para que a preservação das propriedades seja garantida [EHKG02]. A importância da formalização dos modelos e transformações se torna ainda mais evidente no desenvolvimento de sistemas complexos, por exemplo, sistemas concorrentes, nos quais as provas de propriedades são também complexas. Há vários trabalhos disponíveis na literatura no sentido de integrar notações informais (ou semi-formais), utilizadas para descrever modelos, com linguagens formais [EFLR99, BFLP97, NB03]. O principal objetivo destes trabalhos é que as propriedades do sistema inicialmente difinidas e verificadas sejam preservadas durante o ciclo de vida do sistema. Alguns destes trabalhos formalizam a notação informal através da atribuição de uma semântica definida pela linguagem formal. Assim, modelos podem ser mapeados para a linguagem formal e propriedades do modelo podem ser verificadas. A integração entre métodos formais e notações semi-formais visuais tem o objetivo de agregar as vantagens de cada um. Métodos formais são útéis para provar propriedades do 1.

(16) CAPÍTULO 1 INTRODUÇÃO. 2. sistema a partir de sua especificação. No entanto, uma deficiência de algumas notações formais é a falta de representação gráfica que permita aos aos desenvolvedores com background mais prático lerem e entenderem o que está sendo modelado [RL97]. Por outro lado, notações semiformais visuais, como UML, são facilmente integradas ao processo de desenvolvimento de software. Assim, métodos formais e semi-formais visuais são complementares. CSP [RH98, Hoa85] é uma linguagem formal para modelar sistemas concorrentes, onde as partes componentes do sistema são representadas como processos. CSP permite modelar diversas formas de interação entre os processos componentes do sistema, de maneira concisa e elegante. Cada primitiva, ou operador, de CSP é uma abstração para um padrão de interação específico, e o seu comportamento está implícito ao seu uso. CSP também encapsula o conceito de comunicação entre processos, que envolve passagem de mensagens síncronas. Por ser uma álgebra de processos, CSP define leis algébricas para cada operador, assim é possível manipular expressões de processos usando raciocínio equacional. Desta forma, CSP permite provar propriedades comportamentais clássicas de sistemas, como comportamentos determinísticos e ausências de deadlock e livelock, assim como propriedades específicas da especificação através de verificadores de modelos (model checkers) como o FDR [Gol01]. Além disso, a equivalência entre processos também pode ser provada através destas leis, bem como, através da verificação de refinamentos utilizando um model checker como o FDR. UML-RT [SR98, Lyo98] é um profile conservativo de UML idealizado para modelar sistemas concorrentes e reativos. Este profile tem todos os elementos e diagramas de UML, somados a alguns elementos de modelagem e formalismos de ROOM (Real-Time Object-Oriented Modeling) [Lyo98], que é uma notação visual orientada a objetos específica para modelagem de sistemas de tempo real, distribuídos e reativos. Em UML-RT, assim como em ROOM, cada componente do sistema é representado por uma entidade independente, com estrutura e comportamento próprios, e a interação entre estes componentes se dá através de elementos específicos de modelagem (protocolos). Em [Fer07, FSM06], um mapeamento de CSP [RH98, Hoa85] para UML-RT [SR98, Lyo98] é apresentado. Conceitos de processos, operadores e comunicação da notação formal são traduzidos em elementos e diagramas de UML-RT. O mapeamento de especificações CSP em modelos UML-RT permite que o projeto de uma aplicação seja enriquecido com modelos diagramáticos que preservam as propriedades da especificação formal. A partir de uma especificação CSP, três visões complementares em UML-RT são geradas, representadas por diagramas de classe, de estrutura e máquinas de estado [FSM06]. A escolha por representar elementos de CSP usando UML-RT é justificada pelo fato de que esta notação possui facilidades para modelar sistemas reativos e concorrentes. O conceito de processos independentes e comunicantes da álgebra de processos CSP pode ser naturalmente representado por objetos ativos e cooperantes (cápsulas), presentes em UML-RT. Além disso, a semântica herdada de ROOM possibilita a geração de código, tornando possível animar e testar especificações CSP através da tradução. Por fim, os conceitos de UML-RT foram incorporados ao padrão UML 2.0, o que torna a abordagem passível de evolução e aplicável em diversos cenários [Fer07]. Alguns trabalhos relacionados abordam o mapeamento inverso, de UML e UML-RT para algumas notações formais relacionadas a CSP, como CSP-OZ [Fis00] e OhCircus [Ram05]..

(17) CAPÍTULO 1 INTRODUÇÃO. 3. Abordagens alternativas [JCS07, CTJ07, FC06, Fre02, GS03] apresentam o mapeamento de CSP não para uma notação gráfica, mas para bibliotecas Java que implementam alguns operadores de CSP. Embora a estratégia apresentada em [Fer07] tenha sido desenvolvida com o intuito de preservar a semântica da especficiação formal em CSP, uma prova formal não foi apresentada. A prova deste mapeamento é de fundamental importância, uma vez que não faz sentido o esforço dedicado à especificação de sistemas em CSP e a verificação de propriedades e refinamentos, se uma ou mais regras de mapeamento estiverem incorretas. Assim, para garantir confiabilidade no desenvolvimento de sistema concorrentes e distribuídos utilizando este mapeamento, a prova formal do mesmo é indispensável. No entanto, UML-RT não possui uma semântica formal padrão. Entre outras propostas de semântica formal, Ramos [Ram05] propõe uma semântica para UML-RT utilizando OhCircus [CSW03b] (uma combinação de CSP e Z com características adicionais de orientação a objetos) como modelo semântico. O objetivo principal desta dissertação é provar as regras de mapeamento de CSP para UMLRT apresentadas em [Fer07] no modelo de falhas e divergências (failures-divergences model). Uma contribuição adicional, é a formalização de UML-RT em CSP, com base em [Ram05], necessária para as provas das regras. Assim, este trabalho consolida a integração entre CSP e UML-RT apresentada em [Fer07] no desenvolvimento de sistemas concorrentes e distribuídos. Cada regra de mapeamento de CSP para UML-RT é composta por um lado esquerdo, o qual corresponde a uma equação de processo especificado em CSP, e um lado direito com o modelo em UML-RT correspondente à equação. A estratégia utilizada para provar cada regra de mapeamento é a seguinte: • Inicialmente, o lado direito de cada regra (especificado em UML-RT) é traduzido para CSP. Esta tradução é feita de acordo com a semântica formal que atribuímos a UMLRT. Assim, obtém-se um processo em CSP que pode ser comparado ao lado esquerdo da regra. • Em seguida, a equivalência, no modelo de falhas e divergências, entre o processo obtido no passo anterior e o processo que representa o lado esquerdo da regra é provada através da aplicação de leis algébricas de CSP. • Além disso, a equivalência, no modelo de falhas e divergências, entre estes dois processos também é validada automaticamente utilizando o model checker FDR, para uma instância da regra. Um resultado interessante deste esforço foi observar que, estritamente, as regras propostas em [Fer07] não preservam a semântica de CSP, essencialmente com relação a aspectos de terminação dos processos. As cápsulas presentes nas regras foram modeladas recursivamente para permitir a sincronização entre cápsulas quando ocorrer a comunicação através de sinais comuns entre as mesmas. No entanto, uma tentativa de sincronização mal sucedida, ou seja, em sinais que não são compartilhados pelas cápsulas, faz com que estas retornem recursivamente para seus estados iniciais. Esta modelagem gera livelock quando apenas tentativas de sincronização mal sucedidas são executadas. Esta conclusão foi obtida através da prova da Regra do Prefixo, a qual realiza o mapeamento de processos em CSP, que utilizam este operador, para cápsulas.

(18) CAPÍTULO 1 INTRODUÇÃO. 4. em UML-RT. Além de capturar o comportamento do operador de prefixo, esta regra também implementa a sincronização de eventos em CSP. Durante a prova, a recursividade das cápsulas foi quebreda ao finalizarmos os processos que as representam em SKIP, pois para provar as regras basta provarmos um ciclo de comunicação. No entanto, se considerarmos a representação em CSP do modelo UML-RT gerado pela regra, o processo CSP correspondente a este modelo não representa o processo especificado pelo lado esquerdo, uma vez que este não permite a ocorrência de livelock. Em CSP, a sincronização entre dois processos ocorre através da comunicação de eventos em comum, caso este evento não seja comunicado, os processos ficam bloqueados. Assim, além das provas das regras de mapeamento, este resultado também é considerado uma contribuição importante deste trabalho. Esta dissertação está dividida em seis capítulos, além deste, e um apêndice. O conteúdo de cada um é descrito a seguir: • No Capítulo 2, introduzimos a linguagem formal CSP. Apresentamos seus operadores, modelos semânticos e algumas leis algébricas utilizadas nas provas das regras de mapeamento de CSP para UML-RT. • No Capítulo 3, introduzimos os conceitos presentes na linguagem UML-RT, e as características desta notação para representar sistemas concorrentes e reativos. • No Capítulo 4, apresentamos a formalização de UML-RT em CSP. Esta formalização é utilizada para traduzir o lado direito de cada regra para CSP. • No Capítulo 5, apresentamos as provas das regras de mapeamento de CSP para UML-RT utilizando leis algébricas de CSP, bem como a validação das provas utilizando o modelchecker FDR para verficação da equivalência entre os processos que representam os lados esquerdo e direito de cada regra. • No Capítulo 6, discutimos alguns trabalhos relacionados e futuros, e apresentamos nossas considerações finais. • No Apêndice A, apresentamos as demais regas de mapeamento de CSP para UML-RT, a tradução para CSP do lado direito de cada uma destas regras, e suas provas correspondentes através da aplicação de leis algébricas..

(19) C APÍTULO 2. CSP. CSP [Hoa85, RH98] (Communicating Sequential Processes) é uma linguagem formal projetada para modelar o comportamento de sistemas concorrentes e distribuídos. Uma forma de entender CSP é imaginar um sistema como uma composição de unidades comportamentais independentes (subsistemas, componentes ou simplesmente rotinas de processamento) que comunicam-se entre si e com o ambiente que os cerca [Hoa85]. Cada uma destas unidades independentes pode ser formada por unidades menores, combinadas por algum padrão de interação específico. Consideramos o ambiente como todo agente externo que pode interagir com o sistema, como os seus usuários ou outros sistemas. Processos são abstrações para unidades comportamentais, e são construídos através de eventos, operadores e outros processos. Isto é, processos podem ser combinados para formar processos maiores, até que o comportamento de todo o sistema esteja especificado. A composicionalidade de processos (facilidade para compor processos complexos a partir de processos menores, sem alterar a estrutura interna das partes componentes) permite que CSP seja satisfatoriamente usado para modelar sistemas sob diversas abordagens para desenvolvimento de aplicações, como a orientada a objetos. Eventos são abstrações de ações do mundo real. Por exemplo, o evento exibir.BoasVindas pode ser usado para representar a ação de exibir uma mensagem de boas vindas ao usuário do sistema. Além de eventos, que representam uma única ação, CSP permite definir canais, que representam coleções de eventos com características em comum. Canais também são vistos conceitualmente como meios para transmitir dados. Por exemplo, a declaração channel e:. Int. introduz o canal e que pode transmitir qualquer valor do tipo inteiro; o evento e.1 é um dos possíveis eventos que podem ocorrer a partir desta declaração. Além de tipos pré-definidos, como o Int usado previamente, CSP também permite definir tipos novos. Uma facilidade é a criação de tipos enumerados, através do construtor datatype. Por exemplo, datatype Mensagem : BoasVindas | Erro channel exibir: Mensagem determina que o canal exibir pode transmitir qualquer valor do tipo Mensagem, ou seja, qualquer dos eventos exibir.BoasVindas e exibir.Erro. Note que a declaração de um canal sem tipo, como em channel e 5.

(20) CAPÍTULO 2 CSP. 6. define um único evento. Como dito anteriormente, canais com tipos podem ser usados para transmitir dados desse tipo. Assim sendo, CSP também permite modelar a entrada e saída de dados em canais. Por exemplo, a expressão e?x determina que o canal e está pronto para receber um valor a ser atribuído à variável x. Dessa forma, a expressão e?x cria um binding entre x e o valor recebido através de e. É possível, inclusive, restringir o conjunto de valores aceitáveis. Considere a expressão e?x:{x 6 10} na qual o canal e pode comunicar valores do tipo inteiro. Devido à expressão de restrição, {x 6 10}, este canal só aceitará inteiros menores ou iguais a 10. Os exemplos anteriores consideram a possibilidade de receber algum dado através de um canal. Mas, obviamente, para que haja uma recepção de dado, deve haver um correspondente envio. Isso se dá através de expressões de saída, especificadas da seguinte forma: e!exp Nesta expressão, o canal e envia o valor da expressão exp. Assim, canais podem também ser abstrações para pontos de comunicação, ou a interface, de um sistema com seu ambiente. Estas ações podem ainda ser modeladas de forma integrada, como em soma?x?y!(x + y) que indica que o canal soma está pronto para receber dois valores de entrada que serão vinculados a x e y, e enviar a soma desses volores como saída. A ocorrência de um evento em um processo caracteriza uma comunicação deste processo com pelo menos um participante. Geralmente o participante é um outro processo, caso contrário será o próprio ambiente em que o processo está envolvido. Para entender a ocorrência de um evento em um processo deve-se considerar que [RH98, Fre02]: • Eventos são instantâneos: não há diferença de tempo entre o início e fim de um evento em um processo. Conceitualmente eventos podem ocorrer a qualquer momento, desde que isso seja permitido. Esta propriedade, embora permita que a especificação abstraia possíveis atrasos na comunicação, limita a linguagem a não considerar aspectos temporais. Extensões de CSP com tempo (Timed CSP) [LW97] já existem, mas não são consideradas neste trabalho. • A comunicação entre processos é atômica e se dá através de passagem de mensagens simultâneas. Estas interações não são diferenciadas seja para sincronismo simples (ou rendezvous, entre 2 processos) ou complexo (ou multi-way rendezvous, entre mais de 2 processos). No modelo de comunicação síncrono todos os processos participantes devem estar simultaneamente prontos para executar a comunicação..

(21) 2.1 DEFININDO PROCESSOS. 7. Durante o rendezvous, ambos os processos emissores e receptores permanecem bloqueados no ponto de sincronização até que todos os envolvidos alcancem este ponto em seus fluxos particulares. Só então a comunicação ocorre, liberando os envolvidos. Ou seja, os atos de enviar e receber mensagens são dependentes entre si, já que nenhum é efetuado sem o outro. A troca de mensagens em CSP é efetuada sem que necessariamente sejam definidos eventos de entrada e de saída. Isto se deve ao fato de que, na prática, toda ocorrência de e?x ou e!x é reduzida para um evento simples, como e.v, onde v é um dos valores válidos para o canal e. Assim sendo, a noção de entrada ou saída em canais é puramente conceitual, e na prática, é irrelevante do ponto de vista comportamental. O conjunto de todos os eventos possíveis em uma especificação é dito alfabeto, e é representado por ∑ [RH98]. Neste trabalho, convencionamos chamar o conjunto de eventos que podem ocorrer em um processo de alfabeto do processo, e para tal usamos a notação α P, onde P é um processo [Hoa85]. A composição de eventos para formar um processo, e o relacionamento entre diferentes processos são descritos através dos operadores algébricos de CSP. Através dos operadores é possível, por exemplo, executar dois processos em paralelo, podendo haver ou não comunicação entre eles. Outro exemplo é permitir que eventos de um processo não sejam percebidos por outros processos ou pelo ambiente externo. Isto faz CSP extremamente flexível em relação a outras notações formais, já que permite descrever tanto sistemas próximos da arquitetura, onde a estrutura de processos se assemelha à estrutura de componentes do sistema, como especificações mais abstratas, que tenham pouca relação com a estrutura, mas detalhem o comportamento desejado [RH98, Fre02, Fis00]. A sintaxe de CSP define a forma como eventos e processos podem ser combinados através dos operadores para formar um processo. A seguir apresentamos a sintaxe considerada nesta dissertação [RH98] e uma breve descrição de cada um dos elementos sintáticos mencionados.. 2.1 Definindo Processos Cada processo é na verdade uma equação composta por eventos, operadores algébricos e outros processos. As equações de processos são definidas de forma semelhante a funções. Ou seja, o lado esquerdo introduz o nome e os parâmetros, e o lado direito o corpo do processo. Assumimos que o lado esquerdo da equação de um processo parametrizado P será representado como P(s), onde s é o parâmetro de P. Na prática, obviamente, um processo pode ter mais de um parâmetro, porém evitamos este caso por simplicidade na representação das equações. Os parâmetros de processo, junto com os parâmetros de entrada de eventos, representam o estado interno do processo. O escopo dos parâmetros de processo se estende por toda a definição do processo, e seus valores podem ser utilizados em qualquer evento deste processo. Nesta seção detalhamos os operadores algébricos e os processos primitivos de CSP usados para compor a equação de processos complexos (Figure 2.1). Considere g uma expressão condicional, a um evento (a ∈ ∑), C um conjunto de eventos e R uma relação (∑ × ∑)..

(22) 2.1 DEFININDO PROCESSOS. P(s) ::= | | | | | | | | | | |. 8. STOP SKIP a → P(s) (prefixo) P(s) (recursão) g & P(s) (escolha condicional) P(s) 2 P(s) (escolha externa) P(s) u P(s) (escolha interna) P(s) \ C (internalização) P(s)[[R]] (renomeação) P(s);P(s) (composição sequencial) P(s) 4 P(s) (interrupção) P(s) |[ C ]| P(s) (paralelismo). Figura 2.1 Equações de Processos. 2.1.1 Processos Primitivos CSP possui dois processos especiais, considerados primitivos: STOP e SKIP. O processo STOP representa um estado problemático de um sistema (o sistema quebrou), e também pode ser usado para representar um deadlock. Por outro lado, o processo SKIP representa o término de uma execução com sucesso. Embora a literatura classifique outros processos como especiais, como DIV e RUN, estes não são considerados primitivos, desde que são construídos através de outros processos. O processo DIV representa um estado de livelock, e pode ser simulado através de um processo que executa ações internas indefinidamente. Estas ações não são percebidas por outros processos ou pelo ambiente. Sua definição é basicamente DIV = DIV. O processo RUN representa um processo que aceita sincronizar com qualquer evento em qualquer instante de tempo, e volta a comporta-se como RUN novamente. 2.1.2 Prefixo Para construir um processo através de seus eventos usamos o operador → (chamado operador de prefixo). O operador de prefixo sempre possui um evento do lado esquerdo e um processo do lado direito. O comportamento do processo e → P é oferecer o evento e ao ambiente e aguardar indefinidamente até que o ambiente esteja pronto para sincronizar neste evento. Quando isso se dá, o processo passa a comporta-se como P. Devido à composicionalidade de processos em CSP é possível criar um processo com vários prefixos em seqüência, como no exemplo a seguir. Nestes casos o escopo dos parâmetros de entrada se estende pelos eventos subseqüentes. A seguinte definição de processo ilustra esta situação. DUPLICAR = recebeValor?x → duplica!(x + x) → SKIP.

(23) 2.1 DEFININDO PROCESSOS. 9. 2.1.3 Recursão O operador de prefixo é usado para descrever a seqüência de eventos de qualquer processo finito, mas é inviável para processos que apresentam ciclos repetitivos. Daí a necessidade de um mecanismo para representar comportamentos infinitos. Tal mecanismo é a recursão. O processo Clock = tick → tack → Clock executa os eventos tick e tack, nesta ordem, e volta a comportar-se como Clock, indefinidamente. A recursão é útil para definir um processo através de uma única equação, mas também é útil para definir processos que possuem recursão mútua entre si. O exemplo a seguir ilustra recursão mútua entre dois processos, Calculadora e Visor. Calculadora = in?x → in?y → Visor(x + y) Visor(valor) = exibir!valor → Calculadora Se uma equação recursiva é prefixada por um evento, então é chamada recursão guardada. Esta classe de recursão é de grande importância em CSP, haja vista que previne a ocorrência de livelock, como descrito em mais detalhes na Seção 2.1.6. Uma alternativa para definir a recursão é através do operador µ . Por exemplo, o processo Clock apresentado anteriormente poderia ser representado como Clock = µ X • tick → tack → X 2.1.4 Escolhas Externa e Interna Enquanto o operador de prefixo oferece uma única alternativa de execução (processar um evento e em seguida comportar-se como um processo), os operadores de escolha são usados para especificar processos que oferecem mais de uma alternativa de execução em determinado momento. Por exemplo, o processo (a -> P) 2 (b -> Q) aceita inicialmente comunicar qualquer um dos eventos a ou b. O evento escolhido será o primeiro que solicitado pelo ambiente, por isso este operador é chamado escolha externa ou determinística. Após a escolha feita pelo ambiente, o processo anterior comporta-se-á como o processo P ou como o processo Q, dependendo de qual evento inicial tenha sido escolhido. O operador 2 é chamado de escolha externa ou determinística. Por outro lado, o processo (a -> P) u (b -> Q) decide internamente qual dos eventos a ou b será disponibilizado para sincronização, independente do ambiente externo. Isto significa que o ambiente não tem influência na escolha, e qualquer um, a ou b, pode ser oferecido ou recusado para sincronização, de forma imprevisível. O operador u é chamado escolha interna ou não-determinística..

(24) 2.1 DEFININDO PROCESSOS. 10. Uma situação curiosa ocorre quando os eventos iniciais de uma escolha externa são os mesmos. Apesar de se tratar de um operador determinístico, tal característica introduz um comportamento não-determinístico. Por exemplo, o processo (a → P) 2 (a → Q) tem o mesmo comportamento do processo (a → P) u (a → Q) haja vista que na ocorrência do evento a, não se sabe qual foi a escolha do ambiente. Comportamentos não-determinísticos em geral são situações indesejáveis em sistemas complexos e concorrentes, porque representam imprevisibilidade ou falhas de modelagem. Entretanto, o operador u (escolha interna) pode ser usado para abstrair detalhes internos do comportamento de processos, como condições de controle não modeladas. 2.1.5 Escolha Condicional Além das escolhas apresentadas na seção anterior, CSP possui ainda escolhas condicionais baseadas em variáveis introduzidas através de parâmetros de processos ou comunicações de entrada. Assim, estas variáveis podem ser utilizadas para determinar o comportamento dos processos, através de expressões lógicas. O construtor condicional básico é o seguinte: if (g) then P else Q que comporta-se como P se a expressão lógica g for verdadeira, ou como Q, se g for falsa. Em CSP, a construção if (g) then P else STOP pode ser abreviada para g & P. Também é possível representar a expressão if (g) then P else Q como P <g> Q. 2.1.6 Internalização de Eventos Em algumas circunstâncias é importante que ações internas de sistemas não devam ser visualizadas ou sofrer interferência do ambiente externo. CSP dispõe do operador de internalização (hiding) para esconder eventos de processos, e torná-los invisíveis e incontroláveis ao ambiente. Estes eventos continuam ocorrendo no processo, apenas o ambiente externo não pode vê-los. O operador recebe como parâmetros um processo e o conjunto de eventos que devem ser escondidos. Assim, o processo P\{a} comporta-se exatamente como o processo P, exceto que as ocorrências do evento a não são visualizadas externamente. Através do operador de hiding é possível construir o processo DIV mencionado anteriormente. Para isto basta que um processo recursivo tenha todo o seu alfabeto escondido. No exemplo a seguir o processo Q comporta-se como a recursão infinita P = P, que será interpretada pelo ambiente externo como um livelock..

(25) 2.1 DEFININDO PROCESSOS. 11. P = a → P Q = P\{a} 2.1.7 Renomeação de Eventos O operador de renomeação é usado para mudar a representação dos eventos de um processo para o ambiente, sem mudar sua representação interna no processo. O operador recebe como parâmetros um processo e uma relação do tipo ∑ × ∑. Por exemplo, o processo P[[a ← b,b ← a]] comporta-se exatamente como P, mas a relação de mapeamento garante que os eventos a e b de P serão percebidos externamente como b e a, respectivamente. A renomeação é especialmente interessante para promover reuso, porque permite criar cópias de processos com alfabetos diferentes. 2.1.8 Composição Seqüencial O operador de composição seqüencial permite que dois processos sejam executados segundo uma ordem de precedência. O segundo processo deve ser executado apenas após o término com sucesso do primeiro processo. Por exemplo, o processo Q;R comporta-se inicialmente como o processo Q. Após o término com sucesso de Q (identificado quando este passa a comportar-se como SKIP) o processo Q;R passa a comportar-se como R. Diferente do operador de prefixo, que permite eventos consecutivos compartilharem o escopo de uma mesma variável, o operador de composição seqüencial não permite a extensão do escopo das variáveis do primeiro processo para o segundo. Assim, na composição seqüencial (a?x → SKIP);P a variável x não será percebida pelo processo P. 2.1.9 Interrupção Similar ao operador de composição seqüencial, o operador de interrupção é útil para impor uma ordem de prioridade entre dois processos. O processo Q 4 R comporta-se como Q até que o processo R o interrompa. A partir deste momento o processo comporta-se como R. A interrupção ocorre quando o ambiente sincroniza com qualquer evento que R ofereça. Se Q e R oferecem os mesmos eventos ao ambiente, então ocorre uma escolha não-determinística entre eles. 2.1.10. Paralelismo. Até aqui os processos descritos têm representado ações sequenciais. Mesmo os processos que oferecem alternativas de execução (externa ou interna) determinam que apenas um fluxo de.

(26) 2.2 MODELOS SEMÂNTICOS. 12. execução seja escolhido. Através do paralelismo é possível executar mais de um processo simultaneamente, possivelmente havendo comunicação entre eles. Sejam X e Y os alfabetos de P e Q, respectivamente, então o processo P |[ X | Y ]| Q executa os processos P e Q sincronamente em todos os eventos do conjunto X ∩ Y. Se um dos eventos de X ∩ Y for aceito por apenas um dos processos, então este evento não poderá ocorrer (será refutado). Este operador é chamado paralelismo alfabetizado, e permite que eventos fora da interseção dos alfabetos possam ser executados independentemente. Uma outra variação do operador de paralelismo, chamada interleaving, permite compor processos em paralelo, sem que haja interações entre eles. Cada evento oferecido ao interleaving de dois processos ocorre apenas em um deles. Caso ambos estejam dispostos a aceitar um mesmo evento, a escolha entre os processos é não-determinística. Esse tipo de combinação é especificado da seguinte forma: P ||| Q O comportamento do interleaving de dois processos é idêntico ao paralelismo alfabetizado de dois processos, quando a interseção dos alfabetos é um conjunto vazio. Os dois operadores de paralelismo apresentados acima podem ser representados por um único operador, chamado paralelismo generalizado. Através deste operador basta informar o conjunto de sincronização, que contém os eventos que devem ocorrer simultaneamente nos processos participantes. Os eventos fora deste conjunto são executados como no interleaving. Segue abaixo a representação dos operadores de paralelismo alfabetizado e interleaving através do paralelismo generalizado. P |[ X | Y ]| Q ≡ P |[ X ∩ Y ]| Q P ||| Q ≡ P |[ {} ]| Q 2.1.11. Operadores Indexados. A sintaxe de CSP permite construir processos complexos a partir de um conjunto de outros processos e de um operador indexado por este conjunto. O processo do exemplo a seguir representa o interleaving dos P1 a Pn .. |||i:1..n. • Pi. 2.2 Modelos Semânticos CSP adota modelos semânticos para especificar relações de refinamento entre processos. Os principais modelos semânticos são: traces, failures e failures-divergences. O modelo de traces é útil para encontrar seqüências finitas de eventos que um processo pode executar, e verificar que padrões de comportamento são identificados em um processo. Um trace de um processo é uma seqüência finita de eventos que este processo já aceitou. Por exemplo:.

(27) 2.2 MODELOS SEMÂNTICOS. 13. • hx,yi: é um trace de um processo que aceita o evento x seguido pelo evento y; • hXi: é um dos traces do processo SKIP; • hi: é o trace vazio de um processo que ainda não aceitou nenhum evento. A semântica denotacional de CSP impõe que este trace está contido no conjunto de traces de qualquer processo. No modelo de traces, quando um processo Q refina outro processo P, escrito P vT Q, significa que: P vT Q ≡ traces(Q) ⊆ traces(P) onde para cada processo R, traces(R) é o conjunto de todos os seus traces finitos. O modelo de traces é incapaz de identificar os eventos que um processo não pode executar. Assim, neste modelo, os processos P 2 Q and P u Q são equivalentes, já que os conjuntos de traces destes processos são iguais e dados por traces(P) ∪ traces(Q). O modelo de falhas (failures) é mais poderoso que o de traces, já que ele permite a identificação de seqüências de eventos que um processo pode executar, assim como o conjunto de eventos que este processo pode recusar a executar neste momento. Assim, este modelo permite a demonstração de que os processos P 2 Q e P u Q não são semanticamente equivalentes, quando os eventos recusados são considerados. Este modelo também permite verificar se um processo é determinístico, ou seja, se ele sempre se comporta da mesma maneira ao receber sempre a mesma entrada inicial. Finalmente, o modelo de falhas permite análise de deadlock. Refusal é o conjunto de eventos que um processo falha ao aceitar sempre que eles são oferecidos; refusals(P) é o conjunto de eventos recusados no início da execuçao de P. No entanto, apenas o que um processo pode recusar a executar depois do trace vazio não é suficiente, é necessário saber o que o processo pode recusar depois da execução de qualquer trace. Uma falha é um par (s, X), onde s ∈ traces(P) e X ∈ refusals(P/s) (P/s representa o processo P depois da execução da trace s); failures(P) é o conjunto de todas as falhas de P. No modelo de falhas, um processo refina outro, P vF Q, se e somente se traces(Q) ⊆ traces(P) ∧ failures(Q) ⊆ failures(P) ou seja, se qualquer trace s de Q é também um possível trace de P e qualquer refusal depois deste trace também é um possível refusal de P. Q não pode aceitar ou recusar um evento a menos que P o faça. O modelo de falhas e divergências (failures-divergences) é o mais poderoso entre os três modelos descritos. Este modelo também permite a identificação de todos os traces que podem fazer um processo se comportar como divergência (DIV), ou livelock. Um processo divergente não executa nada de útil (perceptível pelo ambiente), ou seja, executa uma seqüência infinita de ações internas. Se um processo pode divergir, então ele pode executar qualquer trace, recusar qualquer evento, e sempre divergir em qualquer trace posterior. Assim, divergences(P) contém não apenas os traces s nos quais P pode divergir, como também todas as extensões sat destes traces. No modelo de falhas e divergências, é necessário estender os conjuntos de traces e failures. Assim, o conjunto de traces de um processo P (traces⊥(P)) contém.

(28) 14. 2.3 LEIS ALGÉBRICAS. também as seqüências de eventos que levam o processo P a divergir. Já o conjunto de falhas (failures⊥(P)) deve também considerar os pares (s,X) tais que, depois de s, P diverge, ou seja, um processo divergente recusa qualquer evento. traces⊥(P) = traces(P) ∪ divergences(P) failures⊥(P) = failures(P) ∪ {(s,X) | s ∈ divergences(P)} Neste modelo, um processo é representado da forma apresentada a seguir. (failures⊥(P),divergences(P)) Com relação ao refinamento entre processsos, no modelo de falhas e divergências, um processo refina outro, P vFD Q, se e somente se failures⊥(Q) ⊆ failures⊥(P) ∧ divergences(Q) ⊆ divergences(P). 2.3. Leis Algébricas. Uma lei algébrica para processos é uma igualdade entre duas expressões envolvendo operadores e processos. Em CSP, afirmar que dois processos são iguais significa que seus comportamentos são indistingüíveis pelo ambiente. Assim, leis algébricas podem ser utilizadas para estabelecer que dois processos são equivalentes. Nesta seção, apresentamos as leis algébricas utilizadas para provar as regras de mapeamento de CSP para UML-RT. Estas leis são um subconjunto das encontradas em [RH98, CSW03a] e são válidas no modelo de falhas e divergências. A lei a seguir indica que o operador de renomeação distribui sobre o operador de escolha externa. Lei 2.1 ([[R]]-2-dist) (P 2 Q)[[R]] = P[[R]] 2 Q[[R]] A próxima lei mostra que o operador de renomeação pode introduzir não-determinismo quando mais de um evento em A está relacionado a um mesmo evento através da relação R. Esta situação não ocorre quando R é uma função injetiva. Neste caso, a escolha não-determinística é sobre um conjunto de apenas um processo, ou seja, não há escolha, já que há apenas um z tal que z R y. Lei 2.2 ([[R]]-step) (?x:A → P)[[R]] = ?y:R(A) →. u{(P[z/x])[[R]]. | z ∈ A ∧ z R y}. A aplicação de uma função de renomeação injetiva distribui sobre os operadores de internalização, de paralelismo generalizado, de escolha externa e de interleaving. Lei 2.3 (f[.]-hide-sym) f[P\X] = f[P]\f(X), se f for injetiva Lei 2.4 (f[.]- |[ X ]| -dist) f[P |[ X ]| Q] = f[P] |[ f (X) ]| f(Q), se f for injetiva Lei 2.5 (f[.]-2-dist) f[P 2 Q] = f[P] 2 f(Q), se f for injetiva Lei 2.6 (f[.]-|||-dist) f[P ||| Q] = f[P] ||| f(Q), se f for injetiva.

(29) 2.3 LEIS ALGÉBRICAS. 15. A aplicação do operador de renomeação no processo SKIP não tem nenhum efeito uma vez que não é permitido renomear X. Lei 2.7 (SKIP-[[R]]-id) SKIP[[R]] = SKIP A aplicação do operador de renomeação no processo STOP não tem nenhum efeito. Lei 2.8 ([[R]]-unit) STOP[[R]] = STOP O comportamento do operador de paralelismo generalizado é expresso pela lei seguinte, onde os conjuntos A e B representam, respectivamente, os alfabetos dos processos P e Q. A complexidade desta lei reflete a generalidade deste operador: um evento pode ser sincronizado entre os processos P e Q, não-sincronizado mas ambíguo (quando o evento pertence ao alfabeto dos dois processos mas não pertence ao conjunto de sincronização X, a escolha entre qual dos dois processos irá sincronizar é não-determinística), ou apenas de um dos dois processos. Considere que P = ?x:A → P’ e Q = ?x:B → Q’. Lei 2.9 ( |[ X ]| -step) P |[ X ]| Q = ?x:C → (P’ |[ X ]| Q’)<x ∈ X> (((P’ |[ X ]| Q) u (P |[ X ]| Q’))<x ∈ A ∩ B> ((P’ |[ X ]| Q) <x ∈ A> (P |[ X ]| Q’))) A lei a seguir indica que o paralelismo generalizado, entre SKIP e um processo cujo conjunto de eventos iniciais é representado por A, pode ser reescrito como um processo no qual o conjunto de eventos iniciais é representado por A\X, onde X é conjunto de sincronização. Lei 2.10 ( |[ X ]| -preterm) SKIP |[ X ]| (?x:A → P) = ?x:A\X → (SKIP |[ X ]| P) O paralelismo generalizado entre dois processos só finaliza com sucesso quando ambos os processos envolvidos no paralelismo finalizam com sucesso. A lei a seguir captura esta propriedade. Lei 2.11 ( |[ X ]| -termination) SKIP |[ X ]| SKIP = SKIP O operador de paralelismo generalizado tem a propriedade associativa quando ambas as interfaces de comunicação são iguais. Lei 2.12 ( |[ X ]| -assoc) P |[ X ]| (Q |[ X ]| R) = (P |[ X ]| Q) |[ X ]| R O operador de paralelismo generalizado é simétrico. Lei 2.13 ( |[ X ]| -sym) P |[ X ]| Q = Q |[ X ]| P O operador de paralelismo generalizado distribui sobre o operador de escolha interna. A lei a seguir captura este fato. Lei 2.14 ( |[ X ]| -dist) P |[ X ]| (Q u R) = (P |[ X ]| Q) u (P |[ X ]| R) O operador de paralelismo generalizado distribui sobre o operador de escolha externa caso o processo P seja deteminístico..

(30) 2.3 LEIS ALGÉBRICAS. 16. Lei 2.15 ( |[ X ]| -2-dist) P |[ X ]| (Q 2 R) = (P |[ X ]| Q) 2 (P |[ X ]| R) A lei a seguir ilustra quando ocorre deadlock entre dois processos executando em paralelo, desde que A ∩ B = 0. / Lei 2.16 ( |[ X ]| -deadlock) (?x:A → P) |[ A ∪ B ]| (?y:B → Q) = STOP A aplicação do operador de internalização não tem nenhum efeito caso o conjunto de eventos a ser escondido seja vazio. Lei 2.17 (null hiding) P\{} = P A próxima lei mostra a internalização de eventos ocorrendo: o evento a desaparece quando ele é um elemento do conjunto X. Lei 2.18 (hide-step) (a → P)\X = P\X <a ∈ X> a → (P\X) A aplicação do operador de internalização de eventos sobre o processo SKIP não tem nenhum efeito uma vez que não é permitido esconder X. Lei 2.19 (SKIP-hide-id) SKIP \ X = SKIP O operador de internalização de eventos distribui sobre o operador de escolha interna. Lei 2.20 (hide-dist) (P u Q) \ X = (P \ X) u (Q \ X) A aplicação do operador de internalização de eventos no processo STOP não tem nenhum efeito. Lei 2.21 (hide-unit) STOP \ X = STOP Dois processos compostos utilizando o operador de interleaving executam independentemente um do outro. Qualquer evento que a composição comunique ocorre precisamente em apenas um dos dois processos envolvidos. Se o evento comunicado pertence ao alfabeto dos dois processos, então a escolha de qual dos dois executou é não-determinística. A lei a seguir captura esta propriedade. Considere que P = ?x:A → P’ e Q = ?x:B → Q’. Lei 2.22 (|||-step) P|||Q = ?x:A∪B→(P’|||Q)u(P|||Q’)<x ∈ A ∩ B>(P’|||Q)<x ∈ A>(P|||Q’) O processo SKIP é a identidade do operador de interleaving. Lei 2.23 (SKIP-|||-id) SKIP ||| P = P A lei a seguir relaciona os operadores de prefixo e escolha externa. Se o ambiente tem a escolha entre eventos dos conjuntos A e B, então obtemos um processo oferecendo eventos do conjunto A ∪ B, e o comportamento subseqüente deste processo depende ao qual dos conjuntos A e B o primeiro evento pertence. Lei 2.24 (2-step) (?x:A → P)2(?x:B → Q) = ?x:A∪C →((P u Q) <x ∈ A ∩ B> (P <x ∈ A> Q)) A escolha externa entre qualquer processo e STOP não tem efeito algum. Lei 2.25 (2-unit) STOP 2 P = P.

(31) C APÍTULO 3. UML-RT. As abordagens tradicionais de UML usam diagramas estáticos (classes, objetos e componentes) e dinâmicos (estados, atividades e interações) para representar a estrutura e o comportamento de cada elemento do sistema ou de cenários específicos da aplicação. Apesar de serem de propósito geral, estes diagramas possuem poucos mecanismos para detalhar características internas de componentes e propriedades como concorrência, interação e distribuição. A solução mais empregada para especializar a notação UML é a criação de profiles para contextos específicos de aplicação [MRRR02]. A utilização de novos estereótipos ou a adaptação de diagramas facilitam a visualização de algumas propriedades de sistemas, geralmente mal representadas através dos elementos padrão de UML. UML-RT [SR98, Lyo98], desenvolvido pela ObjecTime Limited e Rational Corporation, é um profile conservativo de UML 1.5 proposto para a modelagem de sistemas baseados em componentes concorrentes, reativos e possivelmente distribuídos. Embora o nome Real-Time sugira a presença de conceitos de tempo real, como restrições de tempo e requisitos não-funcionais, este profile é mais adequado para modelar a arquitetura de sistemas distribuídos, com a facilidade para representar comportamentos reativos e concorrentes [FOW01]. UML-RT adiciona elementos de modelagem e formalismos de ROOM (Real-Time ObjectOriented Modeling) [Lyo98], que é uma notação visual orientada a objetos específica para modelagem de sistemas de tempo real, distribuídos e reativos. Em ROOM, cada componente (ou ator) de um sistema é modelado como uma entidade independente das demais, com estrutura e comportamento próprios. A estrutura interna de um componente pode ser composta por outros componentes e por pontos de comunicação (portas). A interface de comunicação com o ambiente externo é composta por portas públicas. O comportamento interno de um componente é definido através de máquinas de estado (ROOMCharts) baseadas no formalismo visual Statechart [Har87], e por isso têm potencial para serem usadas não apenas para especificação, mas também para geração do código destes componentes [Sel93]. A comunicação entre componentes é feita através de mensagens, que trafegam pelas portas de componentes conectados e obedecem algum protocolo de comunicação. UML-RT incorporou os conceitos de ROOM através de novos estereótipos e da adaptação de alguns diagramas convencionais de UML. Atores são representados através do novo estereótipo Cápsula, às quais pode-se associar adaptações dos diagramas de colaboração e de máquinas de estados. O novo diagrama de estados possui as características das máquinas de estados finitos de ROOM, e o diagrama de colaboração, chamado diagrama de estrutura, permite visualizar a configuração interna de uma cápsula. O estereótipo Protocolo é usado para definir as regras de comunicação entre portas de cápsulas, que são nada mais que instâncias de protocolos. 17.

(32) 3.1 CÁPSULAS. 18. Como mencionado anteriormente, UML-RT não é um padrão ideal para especificar sistemas críticos e de tempo real [GS03]. Entretanto, muitos autores concordam que a notação possui mecanismos para modelar algumas das principais características arquiteturais destes sistemas de forma satisfatória [CG01, GS03], seja pela aplicabilidade herdada de UML ou pelo formalismo específico de contexto de ROOM, além é claro das facilidades que as ferramentas de suporte oferecem [Sel93, Rat]. UML-RT permite que propriedades como concorrência, interação e condições de controle sejam facilmente identificadas em seus modelos. A estratégia adotada para a comunicação entre cápsulas é a de passagem de mensagens, que fortalece a independência e o encapsulamento de componentes, e é adequada para representar sistemas de software ou hardware, distribuídos ou não [Sel93]. UML-RT também foca mais em modelagem comportamental que UML, facilitando o uso da técnica desde as primeiras fases do desenvolvimento (análise) até a codificação. Isto reduz as descontinuidades conceituais nas mudanças de fases e fortalece o entendimento e a validação dos requisitos. Em [AH01], argumenta-se que máquinas de estado devem ser usadas inclusive para detalhar Use Cases, da mesma forma que diagramas de seqüência. Neste caso, o sistema é visto sob uma perspectiva caixa-preta, e os estados da máquina de estados correspondem a estados ou condições de todo o sistema, e não apenas a estados de um componente isolado.. 3.1 Cápsulas Cápsulas correspondem ao conceito de ator, ou componente ativo, de ROOM. Em UML-RT, cápsulas são classes ativas, que possuem seu próprio thread de controle lógico, e cujo fluxo de controle é sensível apenas à troca de mensagens com outras cápsulas. Estas mensagens podem apenas ser transmitidas e recebidas através das portas de uma cápsula. Cápsulas podem ainda conter instâncias internas de outras cápsulas. Estas instâncias, ou sub-cápsulas, são fortemente acopladas à cápsula que as contém, e não podem existir independentemente desta cápsula. A execução das sub-cápsulas é simultânea à da cápsula container. Cápsulas também possuem métodos e atributos, como classes ordinárias, mas que são visíveis apenas ao contexto interno da cápsula. Ou seja, todos os métodos e atributos de uma cápsula são necessariamente protegidos. A representação visual de uma cápsula é similar à de classes ordinárias, mas contêm o estereótipo «Capsule» e um compartimento adicional para portas (Figura 3.1).. 3.2 Portas Portas são a única interface de comunicação das cápsulas com o ambiente externo ou suas subcápsulas. Portas fortalecem o encapsulamento e o reuso de cápsulas, porque permitem que estas sejam usadas apenas em função das suas interfaces, sem necessidade de conhecimento de suas características internas. Da mesma forma, as cápsulas não precisam conhecer as características do ambiente externo ou de suas sub-cápsulas. Cada porta deve realizar algum protocolo de comunicação, que define o tipo e a sequência válida de mensagens que podem ser comunicadas pelas portas. O termo evento significa a.

(33) 3.3 PROTOCOLOS. 19. Figura 3.1 Representação de cápsulas em diagramas de classes. recepção de uma mensagem pela porta. Portas públicas são diferenciadas do lado de fora da cápsula apenas pelo protocolo que as definem, mas internamente as portas podem ainda ser classificadas como end ou relay. • Porta End: São conectadas diretamente à máquina de estados da cápsula, que pode identificar os eventos que ocorrem na porta e ler suas mensagens. As portas p2 e p3 da Figura 3.4 são exemplos de portas end. • Porta Relay: São conectadas a portas de sub-cápsulas, e seus eventos não são percebidos pela máquina de estados da cápsula que a contém. O uso destas portas se assemelha ao conceito de delegação, já que seus eventos são totalmente encaminhados a outro elemento. A porta p1 da Figura 3.4 é um exemplo de porta relay.. 3.3 Protocolos UML-RT usa o estereótipo «Protocol» para identificar todas as classes que definem as propriedades de portas que as implementam. Protocolos são classes abstratas puramente comportamentais, diferente de cápsulas, que são elementos estruturais. Em um mesmo protocolo é possível definir mais de uma interface, chamada papel, que será implementada pela porta. No padrão ROOM original, protocolos podem definir mais do que dois papéis. Entretanto, as ferramentas de apoio a UML-RT geralmente usam protocolos binários, envolvendo apenas dois papéis. Neste caso apenas um papel, chamado Base, precisa ser definido. O outro, Conjugado, é automaticamente derivado da inversão de sinais do papel Base. Portas podem realizar um único papel. A especificação de UML 2.0 [OMG04] define que protocolos multi-papéis são permitidos, mas não deixa claras as restrições à implementação de papéis pelas portas. Cada papel de um protocolo define os sinais de entrada e de saída que podem ser recebidos ou enviados por uma porta, respectivamente. O tipo do sinal determina exatamente o tipo das mensagens que serão transmitidas pelas portas através daquele sinal. A Figura 3.2 mostra a representação visual do protocolo binário ProtocoloComunicacao, onde apenas os sinais do papel base são informados. Neste exemplo, dois sinais são declarados: o sinal de.

(34) 3.4 MODELANDO A ESTRUTURA. 20. Figura 3.2 Representação de protocolos em diagramas de classes. Figura 3.3 Máquina de estados do papel base de ProtocoloComunicacao. saída enviarRequisicao, que carrega apenas mensagens do tipo X, e o sinal de entrada receberResposta, cujas mensagens são do tipo Y. O papel também define a sequência válida de utilização de seus sinais. Esta sequência é definida através de máquinas de estado, e deve representar o padrão comportamental para cada porta que implemente aquele papel em uma cápsula. A Figura 3.3 mostra a máquina de estados do papel base do protocolo ProtocoloComunicacao, cujas portas devem enviar mensagens usando o sinal enviarRequisicao, e receber mensagens usando o sinal receberResposta, nesta ordem. As cápsulas que contiverem portas que implementam este papel devem garantir que estas, quando usadas, atendam à ordem definida anteriormente, mesmo que a ocorrência dos sinais seja intercalada com eventos de outras portas ou ações internas. Assim, máquinas de estado de protocolo são usadas para indicar às cápsulas as regras de comunicação específicas de cada porta, mas não podem pré-determinar o comportamento interno das cápsulas. A ausência da máquina de estados do papel indica que não há restrições quanto ao uso de portas daquele papel.. 3.4 Modelando a Estrutura A estrutura de um sistema é definida através de instâncias cooperantes de seus elementos, cada uma desempenhando um papel no sistema. Cada elemento do sistema tem sua própria estrutura interna. A estrutura interna de cápsulas pode ser composta de sub-cápsulas (instâncias protegi-.

(35) 3.4 MODELANDO A ESTRUTURA. 21. Figura 3.4 Diagrama de estrutura de cápsula. das de outras cápsulas) e portas de comunicação, que podem ser públicas ou protegidas. Portas públicas compõem a interface de comunicação com o ambiente externo; portas protegidas são usadas para conectar sub-cápsulas e comunicar eventos internos. Em UML-RT, a estrutura interna de cápsulas é definida através de diagramas de colaboração especializados, chamados diagramas de estrutura. Estes diagramas são limitados à representação visual de portas e subcápsulas apenas no contexto da cápsula modelada, e não representam a colaboração geral entre as cápsulas que dão origem às sub-cápsulas. A colaboração entre cápsulas e seus atributos (que não são portas ou sub-cápsulas) deve ser modelada com diagramas de colaboração padrão. A condição básica para que duas cápsulas se comuniquem é que exista uma conexão estrutural entre suas portas. Esta conexão representa o meio de propagação de mensagens entre portas, e é representada no diagrama de estrutura por uma linha, sem orientação, entre duas portas de cápsulas. Apenas portas que possuam protocolos complementares ou simétricos podem ser conectadas. Protocolos complementares possuem sinais de saída e entrada invertidos um em relação ao outro. Protocolos simétricos possuem o mesmo conjunto de sinais, seja em tipo de dado ou orientação. Em protocolos binários, portas base e conjugadas são complementares entre si. Portas conjugadas são ilustradas por caixas brancas. Portas base são ilustradas por caixas pretas. A Figura 3.4 mostra uma cápsula contendo duas sub-cápsulas, C1 e C2. A porta relay, pública e conjugada p1 transmite mensagens do ambiente externo diretamente para C1, e vice versa. A porta end, base e pública p2 é usada para conectar a cápsula diretamente ao ambiente externo. As mensagens transmitidas por esta porta serão diretamente identificadas pela máquina de estados da cápsula em questão. A porta end, conjugada e protegida p3 não se comunica com o ambiente externo, mas permite que a máquina de estados da cápsula em questão troque mensagens com a cápsula C2. Adicionalmente, a conexão entre as duas portas de C1 e C2 garante que estas troquem mensagens entre si, sem a interferência de agentes externos. Toda cápsula é responsável pela utilização de todas as suas partes componentes. Geralmente.