Especifica¸c˜ ao do componente de sincroniza¸c˜ ao e comunica¸c˜ ao

O componente de sincroniza¸c˜ao e comunica¸c˜ao tem duas funcionalidades princi- pais:

1. Realizar a comunica¸c˜ao entre os frameworks;

2. Definir os contextos nos quais determinados eventos devem estar sincroniza- dos entre os frameworks compostos e as situa¸c˜oes nas quais estes eventos

devem ocorrer diretamente em resposta ao ambiente, sem haver comunica¸c˜ao entre os frameworks.

A parte do CSC respons´avel pela comunica¸c˜ao entre os frameworks, que cha- mamos de CSC com, pode ser extra´ıda das tabelas de casamento de seq¨uˆencias de eventos e de mapeameto de tipos (Se¸c˜oes 4.1.4 e 4.1.5). A sua especifica¸c˜ao ´e obtida a partir das seq¨uˆencias de eventos envolvidos nas comunica¸c˜oes entre os frameworks, das trocas de informa¸c˜oes entre estes eventos e dos mapeamentos entre os tipos de dados.

As seq¨uˆencias de eventos das comunica¸c˜oes representam as seq¨uˆencias de even- tos que o CSC com deve sincronizar com os dois frameworks durante as comu- nica¸c˜oes. Cada seq¨uˆencia representa a concatena¸c˜ao das seq¨uˆencias de cada linha da tabela de casamento de seq¨uˆencias de eventos. As passagens de parˆametros e os mapeamentos dos tipos s˜ao feitos atrav´es da fun¸c˜ao M apresentada na Se¸c˜ao 4.1.5.

O CSC com ´e composto pelos processos descritos a seguir:

1. Processo HANDSHAKE. Processo que sincroniza a seq¨uˆencia inicial de eventos da comunica¸c˜ao. Os eventos deste processo s´o est˜ao dispon´ıveis quando ambos os frameworks estiverem prontos para iniciar uma comu- nica¸c˜ao. Ao final do processo, ambos os frameworks devem estar aptos para sincronizar nos demais eventos envolvidos nos pontos de composi¸c˜ao;

2. Processo COMUNICACOES. Processo que sincroniza todas as poss´ıveis seq¨uˆencias de eventos da comunica¸c˜ao. O processo ´e iniciado ap´os o t´ermino do HANDSHAKE e ´e respons´avel por todos os pontos de composi¸c˜ao da comunica¸c˜ao. Ele ´e composto pelos dois processos a seguir:

(a) Processo CASAMENTOS. Processo que oferece e disponibiliza con- tinuamente todos os eventos das seq¨uˆencias dos pontos de composi¸c˜ao da comunica¸c˜ao, exceto a seq¨uˆencia final;

(b) Processo FINAIS. Processo que oferece e disponibiliza continuamente todos os eventos da seq¨uˆencia final da comunica¸c˜ao. Ao final deste processo, o CSC volta para o seu estado inicial.

A forma geral do CSC com ´e apresentada a seguir. CSC com(iniciais, casados, finais, F ) =

HANDSHAKE (iniciais, F ); COMUNICACOES (casados, finais, F ) Os parˆametros iniciais, casados e finais s˜ao os conjuntos de pares de seq¨uˆencias de eventos (ocorridos e disponibilizados) envolvidos na comunica¸c˜ao, onde iniciais representa as seq¨uˆencias de eventos que sinalizam o in´ıcio de uma comunica¸c˜ao, finais, o fim de uma comunica¸c˜ao e casados, as demais seq¨uˆencias. O parˆametro F representa a fun¸c˜ao de passagem de informa¸c˜oes e mapeamento de tipos. Os conjuntos iniciais e finais n˜ao s˜ao necessariamente iguais aos conjuntos de eventos iniciais e finais de CSP (initials e finals). Em CSP estes conjuntos representam

os eventos que o processo est´a inicialmente disposto a aceitar e os ´ultimos eventos que ele aceita. No nosso caso, os conjuntos representam os eventos que iniciam e finalizam comunica¸c˜oes entre os frameworks.

O processo HANDSHAKE ´e gerado pelo processo makeProcess. Note que o processo makeProcess recebe como parˆametro a concatena¸c˜ao das seq¨uˆencias do par de seq¨uˆencias p. O parˆametro F representa a fun¸c˜ao respons´avel pela passagem e pelo mapeamento de informa¸c˜oes

HANDSHAKE (iniciais, F ) =2 p : iniciais • makeProcess(first(p) _ second(p), F ) makeProcess(seq, F ) =2 i : {| head(seq) |} •

(i → makeSubProcess(< i >, tail (seq), F )) makeSubProcess(past , <>, F ) = Skip

makeSubProcess(past , togo, F ) =2 i : F (head(togo), past) • (i → makeSubProcess(past _< i >, tail (togo), F ))

Inicialmente, o processo gerado por makeProcess aceita o primeiro evento de cada seq¨uˆencia do conjunto de seq¨uˆencias seq. A partir deste momento o comporta- mento ´e definido por makeSubProcess, que aceita cada um dos pr´oximos eventos na seq¨uˆencia, sendo que os parˆametros destes eventos podem ter escopo introduzido pelo ambiente ou por eventos anteriores.

O processo COMUNICACOES, como mencionado anteriormente, ´e composto pelos processos CASAMENTOS e FINAIS .

COMUNICACOES (casados, finais, F ) =

CASAMENTOS (casados, F ); COMUNICACOES (casados, finais, F ) 2

FINAIS (finais, F )

Os processos CASAMENTOS e FINAIS tˆem a mesma forma de HANDSHAKE, s´o que as seq¨uˆencias de eventos envolvidos s˜ao os casados e os finais, respectiva- mente.

CASAMENTOS (casados, F ) = HANDSHAKE (casados, F ) FINAIS (finais, F ) = HANDSHAKE (finais, F )

Para o nosso exemplo, os conjuntos de pares de seq¨uˆencias de eventos s˜ao apresentados a seguir.

seqIniciais = {(< validaDados >, < validaInformacao >)} seqCasados = { (< processarDados >, < recebeSolicitacao >), (< informacaoValida >, < dadosValidos >) } seqFinais = { (< enviaResposta >, < obterResposta >), (< informacaoInvalida >, < dadosInvalidos >) }

Portanto,

CSC com CLISERV = CSC com(seqIniciais, seqCasados, seqFinais, M ) O CSC com CLISERV sincroniza com o CLIENTE e com o SERVIDOR em todos os eventos da tabela de casamento de seq¨uˆencias de eventos. A especifica¸c˜ao acima, por obrigar que os eventos do SERVIDOR sejam sempre precedidos por eventos do CLIENTE, impossibilita o SERVIDOR de receber solicita¸c˜oes do am- biente; ele ´e dedicado exclusivamente ao CLIENTE. Esta situa¸c˜ao foge ao prop´osito da composi¸c˜ao, que ´e apenas de delegar algumas funcionalidades do CLIENTE ao SERVIDOR.

Precisamos, portanto, especificar os contextos (em termos de eventos ocorridos) a partir dos quais o SERVIDOR dever´a responder a uma solicita¸c˜ao do CLIENTE. Em todos os outros, o SERVIDOR poder´a interagir diretamente com o ambiente. Denominamos o componente respons´avel por este controle de componente de sin- croniza¸c˜ao do CSC (CSC sinc). Este componente tem a fun¸c˜ao de sincronizar o CSC com o SERVIDOR e com o ambiente, permitindo que o SERVIDOR se comunique com o CLIENTE e com o ambiente, independentemente.

Geramos a especifica¸c˜ao do CSC sinc ap´os uma nova an´alise dos traces do SERVIDOR (em cada ponto de comunica¸c˜ao). Os parˆametros da especifica¸c˜ao do CSC sinc s˜ao os eventos, do framework invocado (no ponto de comunica¸c˜ao), envolvidos na composi¸c˜ao. Dividiremos estes eventos em trˆes conjuntos: iniciais, sincronizados e finais. O conjunto de eventos iniciais representa os eventos que iniciam a comunica¸c˜ao por parte do framework invocado. O conjunto de eventos finais representa os eventos que finalizam a comunica¸c˜ao por parte do framework invocado. O conjunto de eventos sincronizados representa os demais eventos, do framework invocado, envolvidos na comunica¸c˜ao.

Dados os conjuntos de eventos citados acima, a defini¸c˜ao do CSC sinc ´e au- tom´atica: escolha externa de todos os eventos iniciais seguida da escolha externa entre todos os eventos sincronizados e todos os poss´ıveis eventos finais.

CSC sinc(evIniciais, evSincronizados, evFinais) =2 i : evIniciais • (i → Skip); SINCRONIZACOES (evSincronizados, evFinais)

SINCRONIZACOES (evSincronizados, evFinais) = (2 c : evSincronizados • (c → Skip);

SINCRONIZACOES (evSincronizados, evFinais)) 2

(2 f : evFinais • (f → Skip)) ´

E f´acil descobrir, a partir da especifica¸c˜ao ou das tabelas de casamento de seq¨uˆencias de eventos, que todas as comunica¸c˜oes s˜ao iniciadas (do lado do SERVI- DOR, o framework invocado do nosso exemplo) pela ocorrˆencia dos eventos re- cebeSolicitacao e validaInformacao e finalizadas pela ocorrˆencia dos eventos en- viaResposta, informacaoValida e informacaoInvalida. Neste exemplo todos os eventos envolvidos nos pontos de comunica¸c˜ao s˜ao iniciais ou finais. O conjunto de eventos sincronizados ´e vazio. Vale lembrar que estes mesmos eventos fazem parte

de CSC com: a diferen¸ca ´e que, em CSC com, eles s˜ao precedidos por eventos do CLIENTE.

Partimos agora para a automa¸c˜ao da obten¸c˜ao dos parˆametros do CSC sinc. Como j´a foi dito na Se¸c˜ao 3.1.8, o conjunto de traces de um processo pode ser in- finito. Os conjuntos mencionados acima precisam ser gerados a partir de um con- junto finito de traces do processo. Devemos analisar todos os poss´ıveis traces dos processos, mas ignorando recurs˜ao. Por exemplo, suponhamos que seja necess´ario definir os eventos iniciais e finais do processo recursivo R.

R = a → b → R

Os traces de R est˜ao descritos abaixo. ´E f´acil definir o seu evento inicial. O evento final, no entanto, n˜ao pode ser definido j´a que o processo ´e infinito.

traces(R) = {<>, < a >, < a, b >, < a, b, a >, < a, b, a, b >, ...}

Para o nosso prop´osito, o evento final ´e b, como mostraremos posteriormente. O processo SERVIDOR tamb´em ´e recursivo e infinito. Por´em, cada intera¸c˜ao com o CLIENTE tem um in´ıcio e um fim bem definidos. Os traces nos quais estamos interessados s˜ao os traces de cada intera¸c˜ao. A fun¸c˜ao FiniteTraces abaixo representa o conjunto finito de traces de um processo; os traces que fazem parte de FiniteTraces s˜ao restritos a uma ´unica intera¸c˜ao de um processo recursivo.

FiniteTraces(P ) = FinTraces(∅, P )

O primeiro parˆametro da fun¸c˜ao FinTraces, chamado visited , representa um conjunto de processos. Ele ´e usado quando buscamos os traces finitos de um processo recursivo, para evitar que calculemos repetidamente os traces do processo, e sempre ´e inicializado como o conjunto vazio. O segundo parˆametro de FinTraces representa o processo do qual se queira definir os traces finitos.

FinTraces(visited , Stop) = {<>} FinTraces(visited , Skip) = {<>, < X >} FinTraces(visited , a → P ) = {<>} ∪ {< a >_ t | t ∈ FinTraces(visited , P )} FinTraces(visited , ?x : A → P ) = {<>} ∪ {< a >_ t | a ∈ A, t ∈ FinTraces(visited , P [a/x ])} FinTraces(visited , P 2 Q) = FinTraces(visited, P u Q) = FinTraces(visited , P ) ∪ FinTraces(visited , Q )

FinTraces(visited , P ; Q ) = FinTraces(P ) ∪ {s _ t | (s _ X) ∈ FinTraces(visited , P ), t ∈ FinTraces(visited , Q )} FinTraces(visited , µ X : A • F (X )) = if (X ∈ visited ) then ∅ else FinTraces(visited ∪ {X }, F (X ))

Vale a pena mencionar que assumimos que todos os processos da forma (µ X : A • F (X )) possuem nomes locais diferentes para X .

FinTraces(visited , X = Q ) = if (X ∈ visited )

then ∅

else FinTraces(visited ∪ {X }, Q )

Vamos agora apresentar a fun¸c˜ao FinTraces para processos em interleaving e em paralelismo alfabetisado. Inicialmente, vamos analisar o caso especial de dois processos P e Q em paralelismo alfabetisado com todos os eventos comuns dos seus alfabetos presentes no conjunto de sincroniza¸c˜ao X . Caso removamos de qualquer seq¨uˆencia dos traces do paralelismo os eventos presentes no alfabeto de apenas um dos processos, a seq¨uˆencia resultante dever´a ser um trace do outro.

FinTraces(visited , P [| X |]Q ) = {s | s  (αP \ X ) ∈ FiniteTraces(Q) ∧ s  (αQ \ X ) ∈ FiniteTraces(P)}

Quando o conjunto de eventos em comum nos dois processos possui elementos fora do conjunto de sincroniza¸c˜ao X , precisamos distinguir as ocorrˆencias destes eventos comuns (e n˜ao sincronizados) para cada um dos processos. Faremos isto atrav´es do operador de renomea¸c˜ao de eventos de CSP ([[ ]]). Usaremos as fun¸c˜oes R1 e R2 para renomear (identificar unicamente) cada um dos eventos n˜ao sin- cronizados dos processos. A especifica¸c˜ao abaixo define que, se s ´e um trace v´alido para o paralelismo dos processos resultantes da renomea¸c˜ao dos eventos (P0 e Q0), a seq¨uˆencia resultante da aplica¸c˜ao das fun¸c˜oes inversas sobre s ser´a um trace v´alido para o paralelismo dos processos originais. Na fun¸c˜ao abaixo, rename ´e uma fun¸c˜ao que aplica a uni˜ao das fun¸c˜oes inversas de R1 e R2 aos traces do paralelismo dos processos renomeados.

FinTraces(visited , P [| X |]Q ) = {s, R1, R2 | (∃ P0, Q0 | P0 _{= P [[R} 1]] ∧ Q0 = Q [[R2]] ∧ s  (αP0\ X ) ∈ FiniteTraces(Q0_{) ∧} s  (αQ0 \ X ) ∈ FiniteTraces(P0₎₎ • rename(s, R₁−1∪ R−1₂ )}

O interleaving ´e equivalente ao paralelismo alfabetisado de dois processos onde o conjunto de sincroniza¸c˜ao ´e vazio:

Para o processo R definido anteriormente (R = a → b → R), FiniteTraces(R) = {<>, < a >, < a, b >}

Os parˆametros do CSC sinc s˜ao obtidos a partir dos traces finitos do pro- cesso. Para obtermos o conjunto de eventos iniciais usamos a fun¸c˜ao Iniciais. Os parˆametros P e Casados representam, respectivamente, o processo a partir do qual desejamos definir os eventos iniciais e o conjunto de eventos do qual os eventos ini- ciais fazem parte (tipicamente, os eventos presentes nas tabelas de casamento). A fun¸c˜ao Iniciais, por sua vez, usa a fun¸c˜ao auxiliar PrimeiroEventoDe que retorna o primeiro evento de uma seq¨uˆencia (representanto um trace finito de P ) que ´e membro de um conjunto de eventos casados.

Iniciais(P , Casados) =S_{{PrimeiroEventoDe(seq, Casados) | seq ← FiniteTraces(P )}}

PrimeiroEventoDe(<>, Casados) = ∅

PrimeiroEventoDe(seq, Casados) = if (head (seq) ∈ Casados)then

{head (seq)} else

PrimeiroEventoDe(tail (seq), Casados)

Para obtermos o conjunto de eventos finais usamos a fun¸c˜ao Finais que, semel- hante `a Iniciais, tem como parˆametros o processo e os eventos casados. Esta fun¸c˜ao, por sua vez, usa a fun¸c˜ao auxiliar UltimoEventoDe que retorna o ´ultimo evento de uma seq¨uˆencia (representando um trace finito de P ) que ´e membro do conjunto de eventos casados. A fun¸c˜ao CompleteTraces retorna o conjunto de traces que representam a execu¸c˜ao de um processo at´e o seu t´ermino ou uma intera¸c˜ao completa de um processo recursivo.

Finais(P , Casados) =S_{{UltimoEventoDe(seq, Casados) |}

seq ← TracesCompletos(FiniteTraces(P )}

UltimoEventoDe(<>, Casados) = ∅

UltimoEventoDe(seq, Casados) = if (last (seq) ∈ Casados)then

{last (seq)} else

UltimoEventoDe(front (seq), Casados)

O conjunto de eventos sincronizados ´e composto por todos os eventos, do frame- work invocado, presentes na tabela de casamento de seq¨uˆencias de eventos sub- tra´ıdo dos eventos iniciais e finais.

Sincronizados = Casados \ (Iniciais ∪ Finais)

Para o nosso exemplo, os parˆametros do CSC sinc s˜ao os seguintes. eventosIniciais = {| recebeSolicitacao, validaInformacao |}

eventosFinais = {| enviaResposta, informacaoValida, informacaoInvalida |} eventosSinc = {}

Portanto, para o exemplo,

CSC sinc CLISERV = CSC sinc(eventosIniciais, eventosSinc, eventosFinais) Finalmente, o CSC ´e especificado da seguinte forma:

CSC =

(CSC com(seqInciais, seqCasados, seqFinais, F )2

CSC sinc(eventosIniciais, eventosSinc, eventosFinais)); CSC E, especificamente, para o nosso exemplo:

CSC CLISERV =

(CSC com CLISERV 2

CSC sinc CLISERV ); CSC CLISERV

Ou seja, o CSC CLISERV oferece, continuamente, a possibilidade de sin- croniza¸c˜ao entre os processos CLIENTE e SERVIDOR ou entre o ambiente e o SERVIDOR.

Observe que a defini¸c˜ao do CSC ´e parametrizada e completamente reutiliz´avel. Para uma composi¸c˜ao de frameworks espec´ıfica, ´e necess´ario apenas informar as seq¨uˆencias e os conjuntos de eventos (iniciais, casados, sincronizados e finais) e os mapeamentos de dados, conforme ilustrado por CSC CLISERV .

4.1.8

A composi¸c˜ao dos frameworks

At´e agora n´os analisamos os frameworks e o CSC separadamente. O objetivo final, entretanto, ´e a composi¸c˜ao propriamente dita. A comunica¸c˜ao entre os frameworks (e o CSC ) ´e realizada atrav´es da sincroniza¸c˜ao de eventos de CSP.

O CSC deve se comunicar (sincronizar) com o CLIENTE e com o SERVIDOR nos eventos presentes nas tabelas de casamentos de seq¨uˆencias de eventos (Se¸c˜ao 4.1.4). Os conjuntos abaixo representam os canais de comunica¸c˜ao do CSC com o CLIENTE e com o SERVIDOR, respectivamente:

Com CLIENTE CSC = {| processarDados, obterResposta, validaDados, dadosValidos, dadosInvalidos |}

E a composi¸c˜ao ´e especificada da seguinte forma:

COMPOSICAO = (CLIENTE[| Com CLIENTE CSC |]CSC ) [| Com SERVIDOR CSC |]SERVIDOR

Ou seja, a composi¸c˜ao paralela entre o CLIENTE, o CSC e o SERVIDOR. A nota¸c˜ao P [| CS |]Q de CSP denota a composi¸c˜ao paralela ente P e Q, sin- cronizando nos eventos do conjunto CS.