Especificação
dos processos
Especificação
dos processos
4.2 Declaração de conjunto de sinais
4.4 Comunicação entre processos
4.5 Criando e terminando processos
4.6 Outros conceitos de processos em SDL
Esta é a parte do SDL pelo qual ele é mais conhecido. Aqui é tratado o comportamento dinâmico do sistema. Como dito anteriormente, o comportamento dos blocos e do sistema não são especificados diretamente mas derivados do comportamento dos processos constituintes.
No nível de processos, o comportamento é especificado diretamento por um processo sem a necessidade de outros conceitos estruturais. Qualquer número de processos pertencentes a um determinado tipo podem co-existir em um determinado tempo. O número de processos correspondentes a data tipo pode mudar durante a vida útil do sistema.
| Sintaxe gráfica:
|
Sintaxe textual:
process <nome do processo> <declarações> <corpo do processo> endprocess [<nome do processo>] |
A especificação de processo se constitui em duas partes distintas: aparte das declarações, análoga às declarações dos níveis superiores; e o corpo do processo, que especifica o comportamento do processo.
O corpo do processo é chamado de grafo do processo na representação gráfica. As declarações estão contidas na área de declarações do processo. O grafo de um processo pode ser apresentado em várias páginas diferentes.
É permitido a um processo receber apenas sinais que pertençam a um conjunto de entradas válidas. Sinais que pertençam a este conjunto devem ser especificados tanto implicitamnete, através de sinais que pertençam às rotas entre os processos, ou explicitamente através da declaração signalset. Adeclaração explícita é necessária porque alguns sinais não pertencem a nenhuma rota de sinal. Estes são sinais que são locais ao processo.
<signalset> ::= signalset <signal list>;
O conjunto de entradas válidas é a união de todos os sinais das declarações signalset e os sinais contidos nas listas de sinais das rotas de sinais que se conectam com o processo.
O corpo de um processo é baseado no conceito de uma máquina de transição de estados.
A máquina de transição de estados de um processo pode tanto se encontrar em estado estável ou executando uma transição entre dois estados. Uma transição é iniciada por uma entrada. Assim, os elementos essenciais do corpo de um processo são estados, entradas e próximos estados. Na representação gráfica, estados e próximos estados obviamente são representados através do mesmo símbolo.
Estados são os pontos estáveis do comportamento do processo. Uma transição de um estado específico é iniciado por uma entrada e terminada por um próximo estado. Uma entrada consome o correspondente sinal da fila de entrada associada ao processo.
| Representação gráfica:
|
Representação textual:
state <nome do estado>; input <nome do sinal>; [<transições>] nextstate <nome do estado>; [endstate [<nome do estado>];] |
Se uma transição for vazia teremos então a situação corresondente à uma máquina finita de estados pura. Deve ser notado que isto não é necessário agrupar todas as transições de um dado estado na representação textual. A representação textual também pode ter uma declaração endstate para terminar um lista parcial de transições de um dado estado. A declaração endstate não possui equivalente na sintaxe gráfica.
Variáveis podem ter novos valores associados em uma tarefa. Isto é feito dentro de um sinal de tarefe na representação gráfica.
Figura 4.3 Sintaxe gráfica de uma tarega
A sintaxe textual começa com a palavra chave task. Entretando, é importante notar que o símbolo de tarefa é também usado por outras operações, nas quais palavras chaves diferentes são empregadas. Em outras palavras, não há uma correspondência um para um entre um símbolo de tarefa e a palavra chave task. Dentro de uma tarefa, texto informal pode ser usado ao invés de atribuições. A seguir a sintaxe textual de uma tarefa.
state <nome do estado>;
input <nome do sinal>;
...
task <corpo da tarefa>;
...
nextstate <nome do estado>;
[endstate [<nome do estado>];]
<corpo da tarefa> ::=
<nome de variável> := <expressão>
{, <nome de variável> := <expressão> }*
| <texto informal> {, <texto informal>}*
Uma transição pode, em um determinado estágio, seguir por dois ou mais caminhos diferentes, dependendo de alguma condição. Para tal usa-se a constução decision. Uma decisão contém uma questão (question) e um número de respostas (answers), uma para cada caminho.
A avaliação da expressão question junto com a avaliação das respostas determina que caminho a transição tomará. Questões e respostas pode ser formais ou informais.
A questão na figura 4.4 não é necessariamente uma condição booleana. A questão pode ser também uma vairável ou alguma combinação de variáveis com uma faixa específica de possíveis respostas. Uma das respostas pode ser também else, que cobre todas as opções restantes.
As respostas devem ser do mesmo sort da questão. Entretanto, é permitido misturar questões formais e informais e respostas. Neste caso, a parte formal (questão ou resposta) deve ser de um mesmo sort. A resposta false para a questão x+y*2 é um erro. Obviamente, variáveis que são usadas em questões e respostas devem ser declaradas.
| Representação gráfica:
|
Representação textual:
state <nome do estado>; input <nome do sinal>; ... decision <questão> <resposta>: nextstate <nome do estado>; <resposta>: nextstate <nome do estado>; ... enddecision; ... [endstate [nome do estado];] <respota> ::= (<faixa de valores>|<texto informal>) | else |
Não existe nenhuma consistência estática para saber se as respostas cobrem todas as possíveis respostas de uma questão. Um erro dinâmico resulta se a avaliação de uma questão em tempo de execução não possuir uma resposta.
Existe uma fila de entradas (input queue) associada a todo processo. Qualquer sinal recebido por um processo que pertença ao chamado conjunto completo de entradas válidas é posto na fila de entrada. O conjunto completo de entradas válidas define aqueles sinais para os quais o processo está pronto a aceitar.
A figura a seguir mostra o comportamento do tratamento de sinais no nível de processos
Figura 4.5 O macanismo da fila de entrada de um processo
Outputs são usado para enviar sinais e possíveis valores como parâmetros para outro processos, assim permitindo a comunicação entre processos. A sintaxe de um output é monstrada na figura 4.6. Um output gera a criação de um sinal que é despachado para o processo destino através de uma rota de sinais e possivelmente através também de um canal. Um output pode ter parâmetros reais, isto é, uma lista de expressões que denotam valores. Estes valores são dados ao sinal criado, que é consumido pelo processo destinatário. As variáveis carregadas pelo sinal podem assim tornar-se disponível ao processo receptor.
| Representação gráfica:
|
Representação textual:
state <nome do estado>; input <nome do sinal>; ... output <nome do sinal> <to ou via>; ... nextstate <nome do estado>; [endstate [<nome do estado>];] <to ou via> := to <endereço> | via <nome da rota> |
Um exemplo para a omissão de parâmetros reais é:
output X(1,2,,0,).
Um exemplo para a omissão de nomes de variáveis em um input é:
input X(i,,j,,).
Neste caso, o valor 2 no sinal será perdido e o valor da variável j será indefinido.
Para qualquer sinal enviado por um processo, deve existir um e apenas um destino. Este destino pode ser especificado:
Ambas as regras devem ser totalmente cumpridas. Se não for o caso, um erro dinâmico ocorrerá e o comportamento futuro do sistema será indefinido. Os possíveis caminhos de comunicação que um sinal pode tomar pode ser restrito especificando-se a rota de sinais ou canal em que o sinal deverá ser enviado na declaração output.
Endereçamento de um processo
Todo processo tem um único endereço. O endereço não é determinado pelo usuário, mas definido durante a criação do processo. É garantido que todo processo terá um endereço único. O endereço de um processo é, naturalmente, diferente do nome do processo, porque devem existir vários processo de um dado tipo com um certo nome. Os endereços não são sorts.
Para cado processo, existem quatro expressões pré-definidas do sort PId (process identification):
Para todos os processo que são criados quando o sistema é criado, a expressão parent possui valor vazio. Para todos os processos, as expressões sender e offspring possuem o valor inicial também vazio. Estas expressões podem ser usadas como todas as outras expressões, e o usuário de SDL pode armazenas seus valores em variáveis do tipo PId, que pode ser também usado para especificar o destino em uma expressão output.
Endereçamento explícito
Para o endereçamento explícito de processos, o SDL possui a construção to. Esta palavra chave é usada nos outputs, e é seguida por uma expressão contendo o endereço do processo destino. A expressão pode ser qualquer expressão pré-definida (self, sender, offspring, parent), ou uma variável declarada pelo usuário.
Figura 4.7 Endereçamento explícito
Endereçamento implícito
A especificação explícita do endereço destino não é necessaria se o destino for unicamente definido na estrutura do sistema (isto é, existe apenas um processo, e apenas este processo e o ambiente podem receber o sinais).
Na figura 4.8, o bloco B1 contém dois processos do tipo P1 e P2. Exite um processo para cada tipo. P1 pode enviar sinais pela rota de sinais Sr1 e Sr2. O sinal B pode apenas ser enviado na rota Sr1. Portanto, o processo destino para um output de B em P1 não precisa ser explicitamente especificado.
Este é o meio mais simples de endereçamento. É de fato a única alternativa de estabelecimento de contato entre diferentes blocos, visto que inicialmente os processos em blocos diferentes não conhecem o endereço um do outro.
Figura 4.8 Endereçamento implícito
Endereçamento através de rota de sinais ou canais
Em alguns casos, o endereço do processo destino não é conhecido explicitamente nem tederminado unicamente pela estrutura do sistema. Neste caso, um processo único de destino pode ser especificado indicando-se uma rota de sinais ou canal em que o sinal deve ser enviado. Isto pode ser feito apenas através da construção via.
A figura 4.8 mostra o uso desta construção. O sinal A pode ser transportado pela rotas Sr1 e Sr2. Endereçamento implícito aqui não é possível, porque o destino de A não é determindado pela estrutura do sistema. Com a palavra-chave via seguida pelo nome da rota de sinais, o destino pode ser especificado unicamente, como é feito no exemplo.
Os processo são ou criados na inicialização do sistema ou mais tarde por outros processos dentro de um mesmo bloco. Quando um processo é criado, todas as suas variáveis são criadas e, em alguns casos, inicializadas com algum valor inicial. Outras variáveis possuem valores iniciais indefinidos.
Dentro de um processo, pode-se declarar parâmetros de processos. Existe um número arbitrário de processos para cada tipo de processo especificado. SDL fornece um mecanismo de declaração do número de instâncias de um tipo de processo que podem existir, e o número de processos que devem ser criados na inicialização do sistema. Este mecanismo é mostrado na figura 4.9.
| Representação gráfica:
|
Representação textual:
process <nome do processo> [([<init>],[<max>])] referenced; |
| Representação gráfica:
|
Representação textual:
process <nome do processo> [([<init>],[<max>])] [<parâmetros formais>;} <declarações> <corpo do processo> endprocesso [<nome do processo>]; <parâmetros formais> ::= fpar <nome de variável> {,<nome de variável>}* <sort> {, <nome de variável> {,<nome de variável>}* <sort>}*; |
A figura 4.10 mostra também que a especificação de um processo pode ter um conjunto de parâmetros formais que podem ser usados para passar valores para novos processos criados. Parâmetros formais podem ser tratados como outras variáveis (que são declaradas na declaração do processo). Os parâmetros formais são apenas relevantes se os mesmos são criados por outros processos durante a vida do sistema. Se os processo forem criados na inicialização, seus valores iniciais são indefinidos.
Uma vez criado, o processo começa sua vida útil pela interpretação da construção start do corpo do processo. O processo pode, durante algumas de suas transições, criar outros processo dentro do mesmo bloco. O processo pode terminar apenas pela sua própria interpretação de uma contrução stop.
O processo possui um ponto por onde sua vida útil é iniciada. A construção start identifica este pondo inicial.
| Representação gráfica:
|
Representação textual:
start; [<transições>] nextstate <nome do estado>; |
Um processo pode possuir apenas uma contrução start. Caso contrário, existiriam um número ambiguo de pontos de entrada. A declaração start deve ser seguida por uma transição que termina em algum estado, que se torna então no primeiro estado do processo.
Um processo pode "parar" ou terminar suas próprias operações. Isto é feito pela construção stop. Após a interpretação desta construção, o processo e todas as variáveis associadas e expressões pré-definidas terminam. Além da construção nextsate, esta é o único geito de termina um processo de transição.
A construção stop pode não possuir parâmetros associados. Pode ser usado para terminar um número arbitrário de transições.
| Representação gráfica:
|
Representação textual:
state <nome do estado>; input <nome do sinal>; [<transições>] stop; [endstate [<nome do estado>];] |
Um processo pode ser criado por outro processo dentro do mesmo bloco. Isto é feito pela construção create dentro de uma transição.
Assim que o novo processo é criado, ele passa a operar idenpendentemente e assincronamente em relação ao processo criador. No caso de um output e um correspondente input, aos parâmetros formais de criação de um processo são atribuídos os valores dos parâmetros reais na construção create.
O novo processo começa pela interpretação da construção start. Se na criação de um novo processo exceder o número máximo de processos permitidos, então nenhum processo novo é criado e a expressão offspring fica com valor nulo.
Não é permitido omitir qualquer parâmetro formal na especificação de um processo, de forma oposta com o que acontece em um input. Logicamente, alguns dos parâmetros formais podem ser do sort PId, de forma a transmitir informações de endereços conhecidos pelo processo criador.
Figura 4.13 Start e create
Frequentemente pode não ser interessante consumir um sinais na ordem em que ele chegou. Nestes casos, pode ser necessário instruir à fila de entrada para "segurar" os sinais passados ao processo. Isto é o chamado salvamento de sinais em SDL.
state <nome do estado>;
save <nome do sinal>;
...
[endstate [<nome do estado>];]
Deve ser lembrado que sinais que não são explicitamente salvos por um estado e não são mencionados explicitamente em nenhum input são consumidos quando chegam ao fim da fila de entrada como uma operação implícita. Como no caso de um input, um save segue um state. Um save contém o nome do sinal que será salvo.
Figura 4.14 Salvamento de sinal (save)
A diferença para a exemplo anterior é que aqui o sinal Status é salvo na fila de entrada no caso de ele alcançar o fim da fila no momento em que o processo alcança o estado waiting. Portanto, este sinal seria disponível para alguma transição no próximo estado. Na figura 4.15, o sinal Status seria consumido sem mudar o estado (waiting).
Os processos em SDL tem acesso a um tempo global usando a expressão pré-definida now. Isto pode ser usado para atribuir valores à variáveis e influenciar transições. Quando o tempo for usado, variáveis e expressões do tipo Time e Duration são usadas. Estes tipos não podem ser intercambiáveis, pois possuem diferentes significados. Enquanto Time é o tempo absoluto, Duration é um tempo relativo. Variáveis teste sort devem ser declaradas como segue:
dcl x1 Time;
dcl diff Duration;
Na figura 4.16, quando fazemos uma adição com o resultado do sort Time, o primeiro operador deve ser do sort Time e o segundo do sort Duration. A expressao now do sort Time é disponível a qualquer momento e retorna o valor do tempo absoluto corrente.
Figura 4.15 Usando Time e Duration
