Tutorial de Uppaal

Joel Silva Carvalho e Simo Melo de Sousa Universidade da Beira Interior 16 de Maro de 2009

Contedo
1 Introduo 1.1 Objectivo . . . . . . . . . 1.2 Motivao . . . . . . . . . 1.3 Limitaes . . . . . . . . . 1.4 Organizao do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 4 5 5 5 5 5 6 6 6 6 6 6 7 7 8 9 10 12 13 13 13 13 14 14 14

Uppaal 2.1 Introduo . . . . . . . . . . . . . . . . . . 2.2 Autmatos Temporizados e Extenses . . . 2.2.1 Modelos . . . . . . . . . . . . . . 2.2.2 Constantes . . . . . . . . . . . . . 2.2.3 Variveis inteiras limitadas . . . . . 2.2.4 Matrizes . . . . . . . . . . . . . . . 2.2.5 Funes . . . . . . . . . . . . . . . 2.2.6 Posies urgentes . . . . . . . . . . 2.2.7 Posies committed . . . . . . . . 2.2.8 Sincronizaes por mensagem . . . 2.3 Modelao . . . . . . . . . . . . . . . . . . 2.3.1 Especicao Textual . . . . . . . . 2.3.2 Especicao Grca . . . . . . . . 2.3.3 Edges . . . . . . . . . . . . . . . . 2.3.4 Locations . . . . . . . . . . . . . . 2.4 Simulao . . . . . . . . . . . . . . . . . . 2.5 Vericao . . . . . . . . . . . . . . . . . 2.5.1 Correspondncias TCTL em Uppaal 2.5.2 Reachability . . . . . . . . . . . . 2.5.3 Safety . . . . . . . . . . . . . . . . 2.5.4 Liveness . . . . . . . . . . . . . . 2.5.5 Deadlock Freeness . . . . . . . . . 2.5.6 Interface . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

Casos de Estudo 3.1 Algoritmos de Dekker e Peterson 3.1.1 Descrio . . . . . . . . 3.1.2 Modelo . . . . . . . . . 3.1.3 Simulao . . . . . . . . 3.1.4 Vericao . . . . . . . 3.2 Biphase Mark Protocol . . . . . 3.2.1 Descrio . . . . . . . . 3.2.2 Modelo . . . . . . . . . 3.2.3 Vericao . . . . . . . Exerccios 4.1 Exerccio 1 - Protocolo v1 4.2 Exerccio 2 - Protocolo v2 4.3 Resolues . . . . . . . . 4.3.1 Exerccio 1 . . . . 4.3.2 Exerccio 2 . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

16 16 16 16 19 20 21 21 22 26 27 27 28 29 30 33 37

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

A TA e XTA BNF

Captulo 1

Introduo
Este tutorial descreve o Uppaal como ferramenta de Model Checking para sistemas de tempo real. O Uppaal surgiu em 1995 pela universidade de [Upp]sala e pela universidade de [Aal]borg. Esta ferramenta permite manipular trs fases da elaborao do modelo do sistema. Na primeira fase o Uppaal permite a modelao do modelo, na segunda fase permite a realizao de simulaes sobre a execuo do modelo e na terceira fase permite a vericao do modelo. A combinao destas trs fases permite que as equipas de desenvolvimento adquiram algumas garantias sobre o modelo construdo. Isto fornece maior segurana para a realizao das fases seguintes do desenvolvimento. A evoluo do Uppaal tem sido considervel existindo hoje uma panplia de ferramentas auxiliares. Estas ferramentas merecem o seu destaque no entanto no no mbito deste tutorial. Para mais informaes sobre este assunto recomenda-se a consulta da pgina ocial do Uppaal em http://www.uppaal.com.

1.1

Objectivo

Este tutorial serve como documento de iniciao utilizao do UPPAAL, quer no contexto acadmico como empresarial, sintetizando alguma informao necessria para a sua correcta e eciente utilizao.

1.2

Motivao

Grande parte dos sistemas de tempo real so considerados crticos e como tal exigem cuidados acrescidos no desenvolvimento. Por exemplo, reforando a importncia da fase de testes possvel reduzir o nmero de erros. No entanto os testes no so sucientes porque no fornecem certezas, apenas reduzem o espao de incerteza. Tornase evidente que as ferramentas de vericao representam uma mais-valia podendo fornecer certezas.

Inclusivamente no desenvolvimento de sistemas crticos recomendvel utilizar-se mais do que uma ferramenta de vericao. No caso especco dos sistemas de tempo real crticos possvel ver a combinao de ferramentas de vericao esttica como o SPARK com ferramentas de vericao de modelos como o Uppaal[6]. Diferentes tipos de ferramentas complementam-se e permitem a vericao de um maior nmero de propriedades.

1.3

Limitaes

A modelao e vericao de sistemas com a ajuda de ferramentas como o Uppaal possuem todavia algumas limitaes. Nomeadamente porque aquilo que se verica o modelo e no o sistema em si. O modelo necessita espelhar correctamente o que o sistema representa para alm de ser fundamental identicar e denir adequadamente as propriedades por vericar. De facto nada se pode armar sobre propriedades omissas.

1.4

Organizao do documento

Cap. 2 - Uppaal Introduo e descrio de aspectos funcionais do Uppaal, quer no que respeita modelao, como simulao e vericao. Juntamente so apresentados alguns conceitos tericos pertinentes. Cap. 3 - Casos de Estudo Descrio de dois casos de estudo relacionados com algoritmos de excluso mtua e descrio de um caso mais concreto de um protocolo utilizado na indstria. Cap. 4 - Exerccios Enunciado e resoluo de exerccios prticos a realizar em Uppaal para testar a compreenso da ferramenta.

Captulo 2

Uppaal
2.1 Introduo

O Uppaal consiste numa aplicao cliente/servidor. O cliente (java) consiste numa interface grca com um editor, um simulador e um vericador. Este cliente java comunica com um servidor (C++) que nada mais do que o vericador de modelos (verifyta). Assim existem duas formas de vericar um modelo, uma recorrendo aplicao grca Uppaal outra recorrendo directamente aplicao verifyta. As referncias principais para este captulo so [5][8][3].

2.2

Autmatos Temporizados e Extenses

O Uppaal utiliza e estende as redes de autmatos temporizados para especicar o modelo do sistema. De seguida apresentam-se alguns conceitos sobre autmatos temporizados em Uppaal e sobre as extenses introduzidas.

2.2.1

Modelos

No Uppaal os modelos (templates) so a representao individual de cada autmato, opcionalmente com parmetros. Os parmetros so um conjunto de declaraes de qualquer tipo de variveis existente no Uppaal e servem essencialmente para generalizar a especicao dos autmatos.

2.2.2

Constantes

As constantes so declaradas com a palavra reservada const seguida do tipo e uma inicializao, por exemplo: const int i = 2. Uma constante no pode ser modicada ao longo da execuo.

2.2.3

Variveis inteiras limitadas

Quando uma varivel inteira declarada o seu intervalo deve ser denido, no entanto se isso no for feito assumido um valor por defeito (-32768 e 32767).

2.2.4

Matrizes

No Uppaal tambm possvel denir matrizes de tipos de dados simples. A declarao deste novo tipo feita recorrendo aos tpicos parnteses rectos, por exemplo: int i[12].

2.2.5

Funes

O Uppaal permite denir e utilizar funes sintacticamente parecidas com a linguagem C. Estas funes so importantes nas transies onde necessrio realizar operaes mais complexas, um exemplo muito simples de uma declarao de funo bool teste(int a)return (a>2);.

2.2.6

Posies urgentes

Uma posio identicada como urgente permite que os relgios locais a esse autmato no evoluam enquanto essa posio for mantida.

2.2.7

Posies committed

Uma posio committed para alm de funcionar analogamente anterior ela ainda obriga que a prxima transio tenha origem nesta posio. A utilizao deste tipo de posio entrou em desuso com a introduo das sincronizaes mltiplas (ver 2.2.8), uma vez que esta era uma forma de simular as sincronizaes mltiplas utilizando apenas sincronizaes binrias.

2.2.8

Sincronizaes por mensagem

Existem dois tipos de sincronizaes possveis, o primeiro utiliza variveis globais e o segundo utiliza canais de sincronizao (sincronizao por mensagem). Esta seco aborda este ltimo tipo de sincronizao que utilizado ao nvel das transies. Uma transio com sincronizao precisa de pelo menos uma transio emissora, talvez uma ou mais transies receptoras e pelo menos um canal de sincronizao. O autmato que pretende comunicar envia o pedido de sincronizao recorrendo etiqueta !, antecedida do nome do canal de sincronizao, e o autmato receptor aguarda essa sincronizao com a etiqueta ?, antecedida do mesmo nome.

Canais binrios Os canais de sincronizao em Uppaal so declarados recorrendo palavra reservada chan. Estes canais so considerados binrios uma vez que a aco de sincronizao

feita apenas entre duas transies. Neste tipo de canal a existncia de uma transio emissora implica a existncia de uma transio receptora. Canais mltiplos Apesar das sincronizaes tradicionais serem binrias possvel denir sincronizaes de uma transio para um nmero arbitrrio de transies recorrendo aos canais de sincronizao broadcast chan. Neste tipo de canal a existncia de uma transio emissora no implica a existncia de uma transio receptora, mas obviamente que sem a existncia de pelo menos uma transio emissora a sincronizao nunca ocorre na realidade. Canais urgentes Qualquer um dos tipos de canais anteriormente referidos ainda pode ser considerdo urgente recorrendo palavra reservada urgent, por exemplo urgentbroadcastchana;. Isto obriga que as transies que usem este tipo de sincronizaes no utilizem restries de tempo, ou seja no contemplem guardas sobre relgios.

2.3

Modelao

A modelao de um sistema em Uppaal pode ser feita de duas formas distintas, textualmente ou gracamente. Ambas as formas possuem vantagens e desvantagens. Por exemplo, a especicao grca torna-se bastante intuitiva mas muito mais complexa de automatizar. Ao contrrio, a especicao textual permite ser automatizada, mas requer um profundo conhecimento da linguagem.

2.3.1

Especicao Textual

O Uppaal permite a leitura de trs tipos de cheiros, no entanto a verso actual j s permite gravar no formato mais recente. O formato mais antigo consiste num cheiro de texto plano de extenso .ta com a especicao da rede de autmatos temporizados. Neste formato cada autmato denido por process seguido do nome, mas estes no so equivalentes aos templates anteriormente falados. A partir da verso 3.0 foi introduzido o formato .xta, muito semelhante ao .ta e neste cada process corresponde realmente a um template com parmetros. O formato .xta permite ainda ser associado a um outro cheiro .ugi que contm as coordenadas x e y dos objectos. Na verso 3.2 foi introduzido o formato .xml. A expressividade deste tipo de cheiro semelhante ao .xta mas aqui os elementos so descritos recorrendo a tags. Este formato hoje utilizado nativamente pela interface grca e possui como grande vantagem a possibilidade de conseguir gravar modelos sintacticamente mal denidos para posterior correco. No apndice A apresentado a sintaxe no formato BNF para os cheiros .xta e .ta. 7

Associado a estes formatos de cheiros existe ainda o formato .q com a especicao das propriedades que se pretendem vericar. Este formato uma mera lista textual das propriedades, para mais informaes consultar a seco 2.5.

2.3.2

Especicao Grca

A especicao grca consiste na produo do modelo por intermdio do separador editor disponvel na interface grca do Uppaal. Esta interface de modelao (ver Figura 2.1) constituda por trs zonas distintas. A zona superior da interface inclui o menu da aplicao, alguns cones de atalho e os separadores de navegao entre os diferentes modos de visualizao (edio/simulao/vericao). Figura 2.1: Interface de modelao do Uppaal.

Na zona inferior esquerda consta uma estrutura de opes que permite mudar entre as diferentes partes descritivas do modelo. A opo Declarations contm a especicao das variveis globais do modelo (variveis inteiras, canais de sincronizao, relgios e constantes). A opo T emplate representa um autmato temporizado do modelo que por sua vez pode ter declaraes locais. Por m a opo System declarations contm a declarao dos processos com a devida atribuio de parmetros. Na zona inferior direita consta uma rea de trabalho que pode ser constituda por texto, no caso de uma das opes de declarao estar seleccionada, ou por uma representao grca de um autmato, no caso de algum template estar seleccionado. 8

Figura 2.2: Interface de modelao do Uppaal com o exemplo train-gate.

2.3.3

Edges

A cada transio entre dois estados de um autmato temporizado corresponde um edge no Uppaal. Na gura 2.3 apresentada a janela de edio de uma transio com algumas opes preenchidas. Select O parmetro select permite atribuir um valor a uma varivel temporria (apenas vlida para essa transio), dado um intervalo, de forma no determinista. Um exemplo de declarao possvel para um select i : int[0, 3]. Esta declarao permite que o i receba um valor entre 0 e 3 (inclusive) e que seja utilizado nas declaraes das restantes opes da transio. Guard O parmetro guard serve para activar a transio sobre uma dada condio. Um exemplo de declarao de uma guarda x >= 4. Considerando x como sendo um relgio, esta condio permite que a transio seja activada quando tiverem passado pelo menos quatro unidades de tempo no relgio x.

Figura 2.3: Janela de propriedades de um Edge.

Sync Outra forma de fazer evoluir os autmatos de forma "programada" recorrendo aos canais de sincronizao. Com este parmetro possvel invocar ou activar uma ou mais transies utilizando um canal de sincronizao previamente denido (ver 2.2.8). Sempre que numa transio o parmetro sync tiver uma declarao semelhante seguinte c1! signica que, pelo menos um outro autmato vai necessitar de uma transio semelhante a c1?. A utilizao da etiqueta ! pode ser vista como um envio e a etiqueta ? como uma recepo. Update O parmetro update serve para actualizar variveis globais ou locais, um exemplo de declarao x = 0. Considerando este x como sendo um relgio, esta declarao permite reinicializar o relgio o que prtica bastante comum na modelao de sistemas temporizados com Uppaal. O update tambm pode incluir a utilizao de funes ou at mesmo servir para invocar uma funo que no devolve nenhum valor mas que altera variveis locais ou globais. Caso a funo invocada no tenha um impacto no estado do sistema a mesma torna-se intil e gerado um warning aquando da vericao sintctica do modelo.

2.3.4

Locations

A cada estado de um autmato temporizado corresponde uma location no Uppaal. Na gura 2.4 apresentada a janela de edio de um estado com algumas opes preenchidas.

10

Figura 2.4: Janela de propriedades de uma Location.

Name Cada estado possui idealmente (mas no obrigatoriamente) um nome que serve de identicador para a linguagem de especicao do modelo e para a linguagem de especicao de propriedades. Caso o nome seja denido o mesmo deve estar em conformidade com ambas as linguagens. Por exemplo um nome no pode comear por um valor numrico. Invariant Os invariantes surgem da teoria dos autmatos temporizados e so propriedades associadas aos estados. Quando um invariante I associado ao estado P , ento P tem de vericar necessariamente I quando o mesmo tem o controlo. Quando I deixa de ser vericado P tem de deixar o controlo, isto , uma transio deve ser executada. No Uppaal, os estados que violem o seu invariante so indenidos, por denio estes estados no existem. Nesta ferramenta os invariantes so expresses limitadas a conjunes de condies simples sobre relgios, diferenas entre relgios e expresses booleanas que no envolvem relgios. Quando um invariante envolve a comparao do valor de um relgio com um inteiro no permitido vericar se o tempo maior do que o inteiro ou estritamente igual, por exemplo a > 4 ou a == 4. Assim apenas possvel utilizar expresses como a < 4 ou a <= 4. Initial/Urgent/Committed Estas opes so activadas com meras seleces na interface. Cada autmato tem obrigatoriamente de possuir um nico estado inicial. Mais informaes sobre as outras duass opes na seco 2.2.6 e 2.2.7.

11

2.4

Simulao

A simulao no um processo fundamental para a vericao de modelos no entanto torna-se til e intuitiva para uma avaliao eciente aquando da construo do modelo. Dada a especicidade dos modelos possvel recorrer simulao para realizar ajustes e correces. Inclusivamente com o problema da exploso de estados pode acontecer que um modelo complexo no seja facilmente vericvel. Neste tipo de situaes a simulao torna-se ainda mais importante. Interface O simulador do Uppaal permite trs modos de funcionamento distintos. No primeiro o utilizador executa a simulao passo a passo sendo livre de escolher a transio que pretende fazer. No segundo o utilizador executa a simulao de forma automtica e aleatria podendo controlar a velocidade de simulao. No terceiro o utilizador pode percorrer execues anteriormente realizadas. Cada um destes modos de funcionamento pode ser intercalado a qualquer momento dando ao simulador toda a sua exibilidade. Como possvel constatar na gura 2.5 a interface do simulador composta por diversas janelas. Na janela mais esquerda possvel controlar os modos de execuo do simulador. Na janela logo direita so listadas todas as variveis do sistema. Na janela inferior direita so apresentadas as sincronizaes entre os diferentes autmatos bem como os estados activos. Na janela logo acima desta so apresentados todos os autmatos e a vermelho as transies e estados activos. Figura 2.5: Interface de simulao do Uppaal.

12

2.5

Vericao

A vericao de modelos um processo automatizado por algoritmos que permitem conrmar que dadas propriedades esto presentes na representao feita do sistema. Estando a vericao de modelos baseados em autmatos temporizados associada a lgicas temporais, torna-se necessrio classicar os diferentes tipos de propriedades. O Uppaal recorre a uma fraco da lgica TCTL no permitindo por exemplo a combinao de mltiplos quanticadores de caminho.

2.5.1

Correspondncias TCTL em Uppaal

Correspondncias entre a Lgica TCTL e a especicao em Uppaal. A - Todos os caminhos(A em Uppaal). E - Existe um caminho (E em Uppaal). G - Todos os estados num caminho ([] em Uppaal). F - Algum estado num caminho (<> em Uppaal).

2.5.2

Reachability

As propriedades de acessibilidade so aquelas que permitem especicar que uma situao pode ser atingida. Sendo uma frmula de estado, a especicao desta propriedade faz-se recorrendo ao quanticador E e ao combinador F : EF . Por outras palavras, diz-se que seguindo uma das execues, pode ser vericado. Por exemplo num sistema de controlo de acessos, esta propriedade permite validar que existem sempre condies para que a porta se abra. Em Uppaal as propriedades de acessibilidade so expressas da seguinte forma: E <> .

2.5.3

Safety

As propriedades de segurana so aquelas que permitem especicar que algo negativo nunca vai acontecer. Este tipo de propriedades pode limitar-se a uma execuo ou abranger o conjunto de todas as execues possveis. Sendo uma frmula de estado, a especicao desta propriedade faz-se recorrendo quer ao quanticador E como ao quanticador A e ao combinador G: AG ou EG. Este tipo de propriedades fundamental para garantir situaes crticas num modelo. Recorrendo ao exemplo de um sistema de controlo de acessos com fecho automtico de portas, esta propriedade permite validar que uma porta nunca ca aberta mais de x unidades de tempo. Ou no caso de existirem vrias portas, como nos bancos,

13

que nunca esto abertas simultaneamente duas portas. Em Uppaal as propriedades de segurana so expressas de forma positiva: A[] ou E []. Sendo que na primeira especicao (com o quanticador universal A) obrigatoriamente verdade em todos os estados. Enquanto na segunda (com o quanticador existencial E ) verdade em todos os estados de uma execuo possvel. De notar que as restantes propriedades podem ser traduzidas em propriedades destes dois ltimos tipos via tcnicas conhecidas.

2.5.4

Liveness

As propriedades de evoluo permitem especicar que dentro de determinadas condies algo inevitavelmente vai acontecer. Recorrendo ao exemplo de um sistema de controlo de acessos, esta propriedade permite validar que quando algum identicado inevitavelmente uma porta vai abrir. Em Uppal estas propriedades so expressas da seguinte forma: A <> ou > . Sendo que a primeira especicao signica que inevitavelmente verdade nalgum estado de todas as execues. E a segunda signica que sempre que for verdade ento tambm vai ser verdade nalgum estado de todas as execues seguintes.

2.5.5

Deadlock Freeness

Por m a propriedade de ausncia de deadlock permite especicar que o sistema no entra numa situao da qual no consiga sair. Em Uppal esta propriedade expressa da seguinte forma: A[] not deadlock .

2.5.6

Interface

A interface de vericao possui uma lista de propriedades que pode ser seleccionada e aumentada ou reduzida. Cada propriedade possui uma declarao (query), um texto associado que facultativo (comment) e um objecto que representa a propriedade na lista. Quando uma prioridade avaliada a mesma ca com o indicador a verde ou vermelho. O verde signica que a propriedade foi correctamente vericada pelo algoritmo de vericao de modelos enquanto o vermelho signica o contrrio. Sempre que uma propriedade no vericada o Uppaal permite construir um contra-exemplo que ca exposto no ambiente de simulao. No entanto esse contra-exemplo no construdo por defeito. Para que isso seja feito necessrio ir ao menu Options > DiagnosticT race e escolher uma das trs opes Some, Shortest ou F astest.

14

Figura 2.6: Interface de vericao do Uppaal.

15

Captulo 3

Casos de Estudo
Como casos de estudo so apresentados os modelos de dois algoritmos de excluso mtua, mais precisamente o algoritmo de Dekker e de Peterson. Estes algoritmos no possuem qualquer restrio temporal, no entanto pela sua simplicidade tornam-se bons exemplos para iniciar uma apresentao concreta sobre Uppaal. Como terceiro caso de estudo apresentado o modelo do Biphase Mark Protocol. Trata-se de um caso mais completo com diversas restries temporais e mais de trinta propriedades especicadas e vericadas. As referncias principais para este captulo so [7][1][9].

3.1
3.1.1

Algoritmos de Dekker e Peterson

Descrio

Estes algoritmos permitem que dois processos partilhem um recurso conjunto recorrendo apenas memria partilhada. O primeiro algoritmo foi denido em 1964 por T. J. Dekker e o segundo em 1981 por G. Peterson.

3.1.2

Modelo

Na Figura 3.1 apresentado o nico template do modelo do algoritmo de Dekker tal como na Figura 3.2 para o modelo do algoritmo de Peterson. Ambos os modelos possuem a particularidade de serem constitudos por dois autmatos (representando os processos consumidores) que so nada mais do que uma declarao duplicada do template de cada um com alterao dos respectivos parmetros de entrada (ver Listing 3.1 e Listing 3.2). Listing 3.1: Declarao dos processos de sistema do modelo do algoritmo de Dekker. / / Insert process assignments . P0 = P r o c e s s ( 0 ) ; 16

Figura 3.1: Process(const int pid) do modelo do algoritmo de Dekker.

Figura 3.2: P(const int pid) do modelo do algoritmo de Peterson.

17

P1 = P r o c e s s ( 1 ) ; / / Edit system d e f i n i t i o n . s y s t e m P0 , P1 ; Listing 3.2: Declarao dos processos de sistema do modelo do algoritmo de Peterson. P0 = P ( 0 ) ; P1 = P ( 1 ) ; s y s t e m P0 , P1 ; Os dois modelos utilizam tambm algumas variveis globais (ver Listing 3.3 e Listing 3.4) para permitir que a excluso mtua seja devidamente realizada. A ausncia de canais de sincronizao entre os autmatos justica-se pela vontade de representar elmente os algoritmos. Listing 3.3: Declarao das variveis globais do modelo do algoritmo de Dekker. bool f l a g [2] = { false , f a l s e }; int turn = 1; No caso do algoritmo de Dekker declarada uma matriz booleana f lag de dois elementos, inicializados a f alse, e uma varivel inteira turn, inicializada a 1. A varivel f lag indica a inteno dos processos entrarem na zona crtica e a varivel turn indica qual dos processos possui prioridade para aceder zona crtica. Listing 3.4: Declarao das variveis globais do modelo do algoritmo de Peterson. const int N = 2; i n t [ 0 , 1 ] f l a g [N ] ; int [0 ,1] turn ; semelhana do caso do algoritmo de Peterson declarada uma constante inteira N , inicializada com o valor 2, uma matriz de inteiros f lag de N elementos limitados aos valores 0 e 1 e uma varivel inteira turn. As variveis inteiras que no so inicializadas assumem por defeito o valor 0 ou o valor do limite inferior caso elas tenham um limite denido na sua declarao. A constante N dene o tamanho da matriz f lag enquanto as duas restantes variveis assumem a funo descrita no caso do algoritmo de Dekker. De notar ainda que no autmato a matriz de inteiros actualizada com valores booleanos em vez de valores inteiros. semelhana do que acontece em C, o Uppaal assume valores inteiros para cada uma das expresses booleanas true (1) e f alse (0). Observando detalhadamente o modelo do algoritmo de Dekker (Figura 3.1) vericase que o mesmo inicia a sua execuo actualizando a f lag do processo corrente para true (Update f lag [pid] = true) indicando a inteno de aceder zona crtica. No estado seguinte existem duas execues possveis (Guard f lag [1 pid] == true e Guard f lag [1 pid] == f alse) consoante o outro processo esteja ou no a pedir 18

acesso zona crtica. No caso do outro processo no requerer acesso zona crtica a execuo do processo corrente entra directamente na zona crtica (estado critical_section) e efectua duas actualizaes seguidas (Update turn = 1 pid e Update f lag [pid] = f alse) voltando ao estado inicial remainder. A actualizao turn = 1 pid indica que o outro processo ganha prioridade e a actualizao f lag [pid] = f alse remove a indicao de acesso zona crtica por parte do processo corrente. No caso do outro processo estar a pedir acesso zona crtica so avaliadas mais duas guardas turn == pid, turn == 1 pid. Estas permitem vericar qual dos processos possui prioridade no acesso zona crtica. Caso a prioridade esteja do lado do processo corrente ento o modelo volta a avaliar a f lag do outro processo. Caso contrrio a f lag do processo corrente alterada para f alse (Update f lag [pid] = f alse) e a execuo seguinte ca avaliar as guardas turn == 1 pid, turn == pid. Estas guardas esto numa posio do ramo diferente no entanto so uma repetio das anteriores com uma ligeira nuance, desta vez no existe transio de estado enquanto o outro processo tiver prioridade de acesso zona crtica. Assim que o processo corrente ganhe prioridade no acesso zona crtica ento feita uma nova actualizao f lag [pid] = true para indicar a inteno de acesso zona crtica e o modelo volta a avaliar se existem condies para que o acesso seja feito. Observando detalhadamente o modelo do algoritmo de Peterson (Figura 3.2) vericase algo semelhante. Partindo do estado inicial a execuo do modelo comea por fazer duas actualizaes de variveis. A primeira f lag [pid] = true indica a inteno do processo corrente ter acesso zona crtica e a segunda turn = 1 pid d prioridade de acesso ao outro processo. No estado seguinte existem duas guardas que vericam se f lag [1 pid] f alse ou true. Se o outro processo no indicou inteno de aceder zona crtica (Guard f lag [1 pid] == f alse) ento o modelo entra na zona crtica (estado cs). Posteriormente a execuo volta ao estado inicial actualizando a inteno do processo corrente em no pretender aceder zona crtica (Update f lag [pid] = f alse). Se em contrapartida o outro processo indicou inteno de aceder zona crtica (Guard f lag [1 pid] == true) ento o modelo realiza uma segunda vericao mas desta vez sobre a varivel turn. Se a prioridade de acesso zona crtica for do outro processo turn == 1 pid ento o modelo volta ao estado anterior para nova avaliao caso contrrio turn == pid o modelo continua a sua execuo para a zona crtica (estado cs) e posteriormente volta ao estado inicial tal como anteriormente descrito.

3.1.3

Simulao

No modo de simulao do Uppaal possvel vericar que ambos os modelos possuem dois processos designados por P0 e P1, tal como foi descrito nas declaraes de sis19

tema. A simulao destes dois modelos permite vericar se a sua execuo retrata o comportamento desejado dos algoritmos. Apesar de aqui no existir uma relao formal entre os modelos e o respectivo algoritmo de excluso mtua possvel, mesmo assim, tirar algumas concluses sobre o seu funcionamento. Algo especialmente interessante para este tipo de problemas o de poder vericar visualmente e das formas j descritas se o modelo realmente est a fazer aquilo que se pretende. Esta metodologia pode inclusivamente ser utilizada para introduzir estes conceitos de uma forma bastante prtica. Programando estes algoritmos numa linguagem "no formal", no existe a possibilidade de visualizar directamente ou vericar formalmente possveis problemas. Neste tipo de simulao o mesmo j no acontece. muito intuitivo perceber que o modelo avalia as variveis descritas e consoante os seus valores o acesso zona crtica dada a um ou outro processo. Inclusivamente possvel vericar a validade de algumas propriedades do modelo tal como vai ser visto na seco seguinte. Figura 3.3: Simulao do modelo do algoritmo de Dekker.

3.1.4

Vericao

A vericao destes dois modelos consiste na vericao de duas propriedades. Na primeira verica-se, como de costume, se existe ou no deadlock freeness recorrendo seguinte especicao A[]notdeadlock . Executando a vericao desta propriedade no Uppaal verica-se que realmente ambos os modelos a cumprem.

20

Figura 3.4: Simulao do modelo do algoritmo de Peterson.

Na segunda verica-se que em todas as execues possveis o modelo nunca est simultaneamente na zona crtica dos dois processos. Essa especicao de propriedade de segurana faz-se em Uppaal com a seguinte frmula A[] (not (P 0.cs and P 1.cs)).

3.2
3.2.1

Biphase Mark Protocol

Descrio

Como terceiro caso de estudo apresenta-se o modelo do Biphase Mark Protocol. Este protocolo largamente utilizado especialmente para comunicao ao nvel fsico da arquitectura OSI. O mesmo encontra-se implementado em micro controladores como o Intel 82530 Serial Communications Controler. Resumidamente neste protocolo cada bit de uma mensagem codicado numa clula que consiste num nmero de ciclos do relgio divido logicamente numa mark subcell e numa code subcell. Tal como se pode ver na Figura 3.5 sempre que estas duas subcells formarem um par de sinais iguais (1 e 1 ou 0 e 0) o bit da mensagem correspondente 0, sempre que o par de sinais for diferente (1 e 0 ou 0 e 1) ento o bit da mensagem corresponde 1. A grande vantagem deste protocolo que a sincronizao dos relgios do codicador e do descodicador feita no incio de cada clula.

21

Figura 3.5: Terminologia do Biphase Mark Protocol.

3.2.2

Modelo

A Figura 3.6 representa a arquitectura do modelo Uppaal deste protocolo. Este modelo constitudo por 7 autmatos temporizados (representados na gura por rectngulos) que comunicam quer por variveis globais (representadas por crculos) como por sincronizaes (representadas por setas). Figura 3.6: Arquitectura do modelo do BMP.

De forma sucinta descreve-se de seguida a funcionalidade de cada um dos autmatos: [Clock ()] (Figura 3.7) - Modelao lgica do relgio fsico do sistema do lado do codicador. Este autmato produz ticks, no confundir com as variveis de relgio do Uppaal. [Coder()] (Figura 3.9) - Modelao do processo de codicao. Atravs de uma sequncia de bits (varivel in) e dos ticks do relgio (do autmato Clock ()) gera-se uma onda quadrada.

22

 [W ire()] (Figura 3.11) - Modelao do processo de transformao da onda quadrada (dita perfeita) num sinal digital. [Clock 2()] (Figura 3.8) - Semelhante ao Clock () mas desta vez para o descodicador. [Sampler()] (Figura 3.12) - Modelao do processo de cpia peridica do valor de w para new. [Decoder()] (Figura 3.10) - Modelao do processo de descodicao. Aquando de um novo tick se este autmato observar uma alterao da varivel new ele comea a contagem de um nmero especco de ticks e compara o valor inicial da varivel new com o seu valor nal. De seguida actualiza a varivel out e informa o T ester() da actualizao atravs da sincronizao put. [T ester()] (Figura 3.13) - Modelao do ambiente. Este autmato representa a ltima componente do modelo no entanto no faz parte integrante do protocolo. Neste modelo no existem declaraes de variveis locais nem existem parmetros nos templates criados. Assim a declarao do sistema (ver Listing 3.6) resume-se invocao de cada template e todos os canais de sincronizao e variveis utilizadas so globais (ver Listing 3.5). Listing 3.5: Declarao das variveis globais do modelo do BMP. / / Global Declar ations c h a n t i c k , t o c k , edge , g e t , p u t ; b r o a d c a s t c h a n f u z z , s e t t l e , Sample ; i n t m, n ; b o o l i n , o u t , v , w, s , new , o l d , b u f ; clock x , y , z ; c o n s t i n t c e l l =14 , mark =7 , s a m p l e = 1 0 ; c o n s t i n t min =93 , max =100 , e d g e l e n g t h = 1 0 0 ; Listing 3.6: Declarao de sistema do modelo do BMP. s y s t e m Coder , Clock , Wire , Sampler , Clock2 , Decoder , T e s t e r ; Clock() e Clock2() Tanto o Clock() como o Clock2() so compostos por um nico estado e uma transio. Ambos utilizam variveis de relgio distintas (x e y respectivamente) reinicializadas a cada tick . Cada um destes autmatos possui um invariante que controla o tempo durante o qual podem permanecer no estado inicial sem produzir um tick . Ambos possuem uma guarda que activa a respectiva transio apenas quando a mesma for verdade. Deste modo o Clock() s produz um tick entre as 93 e as 100 unidades de tempo tal como o Clock2(), mas este ltimo ainda precisa que a varivel s tenha o valor true (1). Esta varivel serve para que o Sampler() apenas seja executado uma vez por cada tick do Clock2(). 23

Figura 3.7: Clock().

Figura 3.8: Clock2().

Figura 3.9: Coder(). Figura 3.10: Decoder().

Figura 3.11: Wire(). Figura 3.12: pler(). Sam-

Figura 3.13: Tester().

24

Coder() O Coder() comea por permanecer no estado inicial enquanto a sincronizao get? no for invocada, sendo o estado inicial urgente o tempo no evolui. Assim que o Tester() efectuar a sincronizao get! o Coder() transita para o estado C 1 (tambm ele urgente) e consoante o valor do bit transmitido seja 1 ou 0 a respectiva transio efectuada gerando imediatamente uma nova aresta da onda quadrada. Se o bit for 1 o autmato ca no estado C 2 durante 6 ticks do Clock(), a transio para o estado C 4 corresponde a mais um tick e ento gerada uma nova aresta da onda quadrada. O processo volta-se a repetir de forma anloga at ser gerada outra aresta ao 14o tick (contando do nicio). Se em contrapartida o bit for 0 o autmato passa directamente para o estado C 3 gerando uma aresta na transiao e ao 14o tick do Clock() gera outra ao voltando ao estado inicial. Wire() Este autmato introduz o pressuposto que indica que um sinal elctrico s estabiliza aps algum tempo da ocorrncia de uma aresta da onda quadrada. Assim considera-se que no estado W 0 o sinal estvel enquanto no estado W 1 no. Para os parmetros que permitem que o protocolo esteja correcto fundamental que o Coder() nunca gere uma nova aresta enquanto o sinal instvel, isto , enquanto o Wire() se encontre no estado W 1. No caso de ser gerada uma nova aresta sobre estas condies ento o Wire() passa ao estado W 2. No entanto a vericao do modelo vai provar que esta situao nunca ocorre. Sampler() Este autmato apenas possui um estado e uma transio responsvel por copiar o valor do sinal w para a varivel new utilizada como varivel de entrada pelo Decoder(). Para garantir que apenas copiado um valor por cada tick do Clock2() utilizada uma varivel booleana s. Decoder() O Decoder() modela o processo de descodicao do sinal recolhido pelo Sampler(). De forma anloga ao Coder() este autmato rege a sua execuo por ticks, mas desta feita do Clock2(). No estado inicial cada tick responsvel pela comparao do valor recolhido do Sampler() com o valor anterior. Enquanto os valores forem iguais o processo de comparao repete-se. Assim que for detectada uma variao no sinal o autmato passa para o estado D1 armazenando o ltimo valor recolhido. A execuo vai manter-se no estado D1 enquanto no passarem um nmero de ticks iguais ao valor da varivel sample. Quando for efectuada a transio para o estado D2 novamente avaliado se o valor do sinal recolhido naquele momento pelo Sampler() o mesmo do que o inicial para permitir gerar o bit correspondente. Isto , se os valores forem diferentes o bit gerado vai ser 1 caso contrrio 0. Quando a execuo voltar ao estado inicial efectuada a sincronizao put! para informar o Tester() de que um novo bit foi gerado. 25

Tester() Este autmato selecciona no deterministicamente bits e coloca-os na varivel in, posteriormente conrma se os bits recebidos atravs da varivel out correspondem aos anteriores. Sempre que for observada uma diferena nos valores o autmato entra num estado de erro. Se o modelo estiver correcto esse estado nunca atingido.

3.2.3

Vericao

Das 39 propriedades especicadas para este modelo descrevem-se apenas as seguintes: A[] Coder.C0 imply Tester.T0 - Sempre que o Coder est no estado inicial isso implica que o Tester tambm se encontre no seu estado inicial. A[] not (Tester.T2 or Tester.T3 or Tester.Error) - Para qualquer execuo o Tester nunca atinge o estado T2, T3 ou Error. Esta vericao acaba por ser redundante com a de deadlock freeness porque em ambas as situaes se esses estados so atingidos o modelo entra em deadlock. A[] Coder.C0 or Coder.C1 imply n == 0 - Sempre que o estado C0 ou C1 do Coder o estado corrente ento a varivel n tem de ser igual a 0. Isto , o contador de ticks tem de estar reinicializado. A[] Decoder.D0 imply m == 0 - Sempre que o Decoder est no estado D0 ento a varivel m tem de ser igual a 0. Anlogo ao anterior. A[] y >= 0 and y <= Max - O relgio y est sempre compreendido entre 0 e Max. Isto , em nenhuma situao o tick do Clock2 ultrapassa o valor de Max. A[] Coder.C1 or Coder.C2 or Coder.C4 imply Tester.T1 - Sempre que o Coder est num outro estado que no o C0 ou o C3 ento o Tester est obrigatoriamente no estado T1. A[] not Wire.W2 - O estado W2 do coder nunca atingido. Isto garante que o modelo nunca produz uma nova aresta da onda quadrada enquanto o Wire est na posio W1 (de sinal instvel).

26

Captulo 4

Exerccios
Neste captulo apresentam-se alguns exerccios a resolver com a ferramenta de vericao de modelos Uppaal. Estes exerccios contemplam quer a modelao, como a simulao e a vericao dos modelos. No m do captulo encontram-se resolues para os exerccios propostos. No entanto vivamente recomendado que essas resolues s sejam consultadas no m dos exerccios estarem resolvidos. As referncias principais para este captulo so [2][4].

4.1

Exerccio 1 - Protocolo v1

Num contexto de comunicao, o mais simplista possvel, sugerida a implementao de um protocolo com trs componentes interligadas: emissor, meio e receptor (ver Figura 4.1). O emissor transmite uma mensagem de tamanho xo. Esse tamanho corresponde ao tempo entre o incio do envio e o m do envio da mensagem. O meio corresponde componente central responsvel pela passagem da mensagem do emissor para o receptor. Este meio introduz um atraso xo na comunicao que corresponde ao tempo entre o incio do envio por parte do emissor e o incio da recepo por parte do receptor ou o m do envio por parte do emissor e o m da recepo por parte do receptor. O receptor recepciona a mensagem vinda do meio de comunicao. Nesta primeira verso parte-se do princpio que o tamanho menor que o atraso (tamanho < atraso), i.e. o meio s transmite a mensagem para o receptor depois do envio (por parte do emissor) ter sido nalizado. recomendada a utilizao de constantes inteiras para o tamanho e para o atraso. O meio no deve, nesta primeira verso, ter conhecimento do tamanho da mensagem, 27

Figura 4.1: Esquema das componentes do protocolo.

nem o emissor do atraso. O sistema modela-se com uma rede de autmatos sincronizados, utilizando o incio e m de comunicao do emissor e do receptor como sincronizaes com o meio. Pretende-se ainda que o modelo seja vericado garantido a no existncia de deadlocks e identicando qual o tempo decorrido do incio do envio at ao m da recepo da mensagem.

4.2

Exerccio 2 - Protocolo v2

Este exerccio consiste na alterao do protocolo modelado anteriormente de modo a que o mesmo agora consiga lidar com mensagens de tamanho maior que o atraso do meio. Nesta verso no exigido que o modelo seja rigoroso, admite-se a possibilidade das execues nem sempre escolherem a forma mais rpida de comunicar a mensagem. Isto partindo do princpio que o meio continua a no conhecer o tamanho da mensagem. Pretende-se que o modelo seja vericado pelo menos com as propriedades anteriormente denidas.

28

4.3

Resolues

29

4.3.1

Exerccio 1

Para este exerccio apresentam-se duas resolues ligeiramente distintas. Numa as sincronizaes so urgentes (ver Figura 4.3) enquanto na outra no (ver Figura 4.2). Para esta situao ambos os modelos cumprem o objectivo anteriormente denido, no entanto existem diferenas signicativas entre as sincronizaes urgentes e as no urgentes. Como foi referido numa sincronizao urgente a passagem de tempo no ocorre e consequentemente torna-se impossvel utilizar guardas sobre relgios simultaneamente. Figura 4.2: Modelo com sincronizaes no urgentes.

Nestas duas solues as execues no so realmente paralelas, porque seguem uma sequncia linear que se repete, logo o facto de utilizar, ou no, sincronizaes ur30

Figura 4.3: Modelo com sincronizaes urgentes.

31

gentes no provoca alteraes nos modelos.No caso contrrio o mesmo poderia j no se vericar, excepto se os estados intermdios fossem sempre committed. A declarao de variveis globais e declarao de variveis locais de ambos os modelos so iguais (ver Listing 4.1 e 4.2). Listing 4.1: Declarao de variveis globais. / / Place global d e c l a r a t i o n s here . clock tglobal ; bool m_enviada ; Listing 4.2: Declarao de variveis locais do Meio. clock atraso_i , atraso_f ; J a declarao de sistema muda ligeiramente devido existncia dos canais de sincronizao urgentes e no urgentes. Na Listing 4.3 possvel ver uma declarao completa e na Listing 4.4 apresenta-se a diferena do modelo com os canais de sincronizao urgentes. Listing 4.3: Declarao de sistema do modelo da Figura 4.2. / / Place template i n s t a n t i a t i o n s here . c h a n i n i c i o _ e , fim_e , i n i c i o _ r , f i m _ r ; c o n s t i n t tamanho =3 , a t r a s o = 1 0 ; e = E m i s s o r ( i n i c i o _ e , fim_e , tamanho ) ; r = Receptor ( i n i c i o _ r , fim_r ) ; m = Meio ( i n i c i o _ e , fim_e , i n i c i o _ r , f i m _ r , a t r a s o ) ; / / L i s t one o r more p r o c e s s e s t o be composed i n t o a s y s t e m . s y s t e m e , r , m; Listing 4.4: Parte da declarao de sistema do modelo da Figura 4.3. u r g e n t c h a n i n i c i o _ e , fim_e , i n i c i o _ r , f i m _ r ; / / R e p e t i o d a s d e c l a r a e s de s i s t e m a do o u t r o modelo / / sem a o u t r a d e c l a r a o de c a n a i s de s i n c r o n i z a o . Olhando mais detalhadamente para a soluo apresentada na Figura 4.2 e aps terem sido apresentadas todas as declaraes sabe-se que cada template vai dar origem a um nico autmato do modelo. Existindo trs estados iniciais a execuo poderia comear por qualquer um deles, mas dois dos estados iniciais esperam por sincronizaes. Assim s existe uma primeira execuo possvel que consiste na transio para o estado Envio do Emissor. A primeira transio para alm de umas actualizaes de variveis faz ainda uma sincronizao com o Meio dando incio execuo do mesmo. Esta sincronizao representa o incio do envio da mensagem por parte do Emissor e coloca o Meio no estado Recepcao.

32

De seguida s possvel executar a transio que volta a por o autmato Emissor no estado P ronto. Existe uma guarda nessa transio indicando que tglobal >= tamanho, logo a transio s vai ser activada quando for atingida esta condio. Por outras palavras, a execuo s evolui, nalizando o envio da mensagem, quando o tempo correspondente ao tamanho da mensagem passar. Esta transio faz ainda uma sincronizao com o Meio para permitir que de seguida seja iniciado o processo de recepo da mensagem por parte do Receptor. No esquecer que a mensagem totalmente enviada antes de ser iniciado este processo porque partiu-se do pressuposto que o tamanho sempre menor que o atraso. A prxima execuo consiste na transio para o estado Envio do Meio. Nesta transio possvel vericar a existncia da guarda atraso_i >= atraso que permite que a evoluo do autmato s seja realizada quando o tempo de atraso tenha sido atingido. A transio inicia o processo de recepo da mensagem por parte do receptor atravs da sincronizao colocando o Receptor no estado Recepcao. A execuo seguinte remete o Meio para o estado P ronto. A transio responsvel por essa execuo possui a guarda atraso_f >= atraso indicando que a evoluo s feita quando o atraso de nalizao do processo de comunicao seja cumprido. Esta transio faz ainda uma sincronizao com o Receptor, por sua vez a transio do Receptor realiza a actualizao m_enviada = true. Esta actualizao permite saber quando o Receptor est no estado P ronto se o tglobal contm o tempo total de comunicao ou se o mesmo j foi reinicializado. Simulando e estudando este protocolo chega-se concluso que o tempo total de comunicao corresponde soma do tamanho com o atraso. Assim o modelo deve vericar correctamente as propriedades A[] not deadlock e A[] (r.P ronto and m_enviada == true imply tglobal >= (tamanho + atraso)). Outra propriedade que pode ser interessante vericar E <> (r.P ronto and m_enviada == true and tglobal < (tamanho + atraso)). Isto , ser que existe algum caminho com tempo total de comunicao menor que a soma do tamanho com o atraso? A resposta bvia no. No entanto esta propriedade pode ser interessante para descortinar erros no modelo numa fase intermdia.

4.3.2

Exerccio 2

A resoluo deste exerccio consiste meramente na alterao do Meio para conseguir lidar com a situao citada no enunciado. Na Figura 4.4 e na Figura 4.5 possvel ver o Meio de cada uma das solues. Uma vez que as alteraes entre ambas as solues so menores, lidando com a questo da sincronizao de maneira diferente, de seguida descreve-se apenas as alteraes para a Figura 4.4. Alm da alterao grca, que irrelevante funcionalmente, verica-se que o Meio possui um novo estado com transies que sincronizam primeiro com o autmato Receptor e posteriormente com o autmato Emissor. A primeira transio possui a guarda atraso_i >= atraso limitando a evoluo do modelo a este ramo apenas quando esta 33

Figura 4.4: Meio do modelo com sincronizaes no urgentes.

Figura 4.5: Meio do modelo com sincronizaes urgentes.

34

condio se vericar primeiro que a sincronizao que segue o outro ramo. Em termos de vericao as duas solues seguem o comportamento do exerccio anterior, o que seria de esperar uma vez que as propriedades denidas mantm-se. No entanto se for pretendido um modelo rigoroso, nota-se com a simulao, que em ambas as solues o Meio necessita conhecer o tamanho da mensagem para tomar a deciso correcta sobre qual dos ramos a executar.

35

Referncias
[1] http://www.ita.cs.ru.nl/publications/papers/fvaan/ MCinEdu/mutex.html. [2] http://www.it.uu.se/edu/course/homepage/realtid/ p1ht08/uppaal. [3] Systems and software verication: model-checking techniques and tools. SpringerVerlag New York, Inc., New York, NY, USA, 1999. [4] Hugh Anderson. Verication of real time systems - cs5270 (lecture 11). http://www.comp.nus.edu.sg/~cs5270/2006-semesterII/ foils11.print.pdf, March 2007. [5] Gerd Behrmann, Alexandre David, and Kim G. Larsen. A tutorial on UPPAAL. In Marco Bernardo and Flavio Corradini, editors, Formal Methods for the Design of Real-Time Systems: 4th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM-RT 2004, number 3185 in LNCS, pages 200236. SpringerVerlag, September 2004. [6] A. Burns and T. M. Lin. An engineering process for the verication of real-time systems. Form. Asp. Comput., 19(1):111136, 2007. [7] R. "Hamberg and F.W."Vaandrager. "Using Model Checkers in an Introductory Course on Operating Systems". Technical Report "ICISR07031", "Radboud University Nijmegen", "December2007". [8] Kim G. Larsen, Paul Pettersson, and Wang Yi. U PPAAL in a Nutshell. Int. Journal on Software Tools for Technology Transfer, 1(12):134152, Oct 1997. [9] F.W. Vaandrager and A.L. de Groot. Analysis of a biphase mark protocol with Uppaal and PVS. Formal Aspects of Computing Journal, 18(4):433458, December 2006.

36

Apndice A

TA e XTA BNF
Informao retirada da pgina pessoal do Professor Gerd Behrmann. Esta sintaxe assemelha-se da linguagem C, tanto que possvel declarar funes C dentro da especicao do modelo. Listing A.1: BNF do formato TA/XTA v3.x OldXTA : : = < O l d D e c l a r a t i o n > < I n s t a n t i a t i o n > <System > O l d D e c l a r a t i o n : : = < VariableDecl > | <OldConstDecl > | <OldProcDecl > OldConstDecl : : = const <OldConstDeclId > ( , <OldConstDeclId >) ; O l d C o n s t D e c l I d : : = ID < A r r a y D e c l > [ < I n i t i a l i s e r > ] O l d P r o c D e c l : : = p r o c e s s ID [ < O l d P r o c P a r a m s > ] { <OldProcBody > } O l d P r o c P a r a m s : : = ( [ < OldProcParam > ( ; < OldProcParam > ) ] ) O l d P r o c P a r a m : : = <Type > ID < A r r a y D e c l > ( , ID < A r r a y D e c l > ) | c o n s t ID < A r r a y D e c l > ( , ID < A r r a y D e c l > ) OldProcBody : : = ( < VarDecl > | < O l d C o n s t D e c l > ) < O l d S t a t e s > [ < Commit > ] [ < U r g e n t > ] < I n i t > [ < O l d T r a n s i t i o n s > ] O l d S t a t e s : : = s t a t e < OldStateDecl > ( , < OldStateDecl >) ; O l d S t a t e D e c l : : = ID [ { < O l d I n v a r i a n t > } ] O l d I n v a r i a n t : : = < Expression > ( , < Expression >) OldTransitions ::= trans <OldTransition > ( , < O l d T r a n s i t i o n O p t >) ; O l d T r a n s i t i o n : : = ID > ID < OldTransBody > O l d T r a n s i t i o n O p t : : = O l d T r a n s i t i o n | > ID < OldTransBody > 37

OldTransBody : : = { [ < OldGuard > ] [ < Sync > ] [ < A s s i g n > ] } OldGuard : : = g u a r d < E x p r e s s i o n > ( , < E x p r e s s i o n > ) ; Listing A.2: BNF do formato XTA v4.x XTA : : = < D e c l a r a t i o n > < I n s t a n t i a t i o n > <System > D e c l a r a t i o n : : = < F u n c t i o n D e c l > | < V a r i a b l e D e c l > | <TypeDecl > | <ProcDecl > I n s t a n t i a t i o n : : = ID ASSIGNMENT ID ( < A r g L i s t > ) ; System : : = s y s t e m ID ( , ID ) ; ParameterList : : = ( [ <Parameter > ( , <Parameter > ) ] P a r a m e t e r : : = <Type > [ & ] ID < A r r a y D e c l > F u n c t i o n D e c l : : = <Type > ID < P a r a m e t e r L i s t > < Block > P r o c D e c l : : = p r o c e s s ID < P a r a m e t e r L i s t > { <ProcBody > } ProcBody : : = ( < F u n c t i o n D e c l > | < V a r i a b l e D e c l > | <TypeDecl > ) < S t a t e s > [ < Commit > ] [ < U r g e n t > ] < I n i t > [ < T r a n s i t i o n s > ] S t a t e s : : = s t a t e < S t a t e D e c l > ( , < S t a t e D e c l >) ; S t a t e D e c l : : = ID [ { < E x p r e s s i o n > } ] Commit : : = commit S t a t e L i s t Urgent : : = urgent S t a t e L i s t S t a t e L i s t : : = ID ( , ID ) I n i t : : = i n i t ID ; T r a n s i t i o n s : : = t r a n s < T r a n s i t i o n > ( , < T r a n s i t i o n O p t >) ; T r a n s i t i o n : : = ID > ID < T r a n s i t i o n B o d y > T r a n s i t i o n O p t : : = T r a n s i t i o n | > ID < T r a n s i t i o n B o d y > T r a n s i t i o n B o d y : : = { [ < Guard > ] [ < Sync > ] [ < A s s i g n > ] } Guard : : = g u a r d < E x p r e s s i o n > ; Sync : : = sync < E x p r e s s i o n > ( ! | Assign : : = assign <ExprList > ; ; ; )

? )

TypeDecl : : = t y p e d e f <Type > < T y p e I d L i s t > ( , < TypeIdList >) ; T y p e I d L i s t : : = ID < A r r a y D e c l > Listing A.3: BNF da declarao de variveis V a r i a b l e D e c l : : = <Type > < D e c l I d > ( , < D e c l I d > ) ; D e c l I d : : = ID < A r r a y D e c l > [ ASSIGNMENT < I n i t i a l i s e r > ] 38

I n i t i a l i s e r : : = <Expression > | { < F i e l d I n i t > ( , < F i e l d I n i t > ) } F i e l d I n i t : : = [ ID : ] < I n i t i a l i s e r > ArrayDecl : : = [ <Expression > ]

Type : : = < P r e f i x > ID [ <Range > ] | < P r e f i x > s t r u c t { < F i e l d D e c l >+ } F i e l d D e c l : : = <Type > < F i e l d D e c l I d > ( , < F i e l d D e c l I d > ) ; F i e l d D e c l I d : : = ID < A r r a y D e c l > Pref ix : : = ( [ urgent ] [ broadcast ] | [ const ] ) Range : : = [ < E x p r e s s i o n > , < E x p r e s s i o n > ] Listing A.4: BNF das instrues B l o c k : : = { ( < V a r i a b l e D e c l > | <TypeDecl > ) < S t a t e m e n t > } S t a t e m e n t : : = <Block > | ; | <Expression > ; | for ( < ExprList > ; < ExprList > ; <ExprList > ) <Statement > | while ( < ExprList > ) < Statement > | do < S t a t e m e n t > w h i l e ( < E x p r L i s t > ) ; | if ( <ExprList > ) <Statement > [ else <Statement > ] | break ; | continue ; | s w i t c h ( < E x p r L i s t > ) { <Case >+ } | return ; | return <Expression > ; Case : : = c a s e < E x p r e s s i o n > : < S t a t e m e n t > | d e f a u l t : < S t a t e m e n t > Listing A.5: BNF das expresses ExprList : : = <Expression > ( , <Expression > ) E x p r e s s i o n : : = ID | NAT | true | f a l s e | ID ( < A r g L i s t > ) | <Expression > [ <Expression > ] | ( <Expression > ) | < E x p r e s s i o n > ++ | ++ < E x p r e s s i o n > | < E x p r e s s i o n > | < E x p r e s s i o n > | < E x p r e s s i o n > <AssignOp > < E x p r e s s i o n > | <UnaryOp > < E x p r e s s i o n > 39

| | | | |

<Expression > <Expression > <Expression > <Expression > <Expression >

<Rel > < E x p r e s s i o n > <BinIntOp > < Expression > <BinBoolOp > < E x p r e s s i o n > ? <Expression > : <Expression > . ID>

AssignOp : : = ASSIGNMENT | += | = | = | / = | %= | | = | &= | ^ = | < <= | > >= UnaryOp : : = | ! R e l : : = < | <= | == | ! = | >= | > B i n I n t O p : : = + | | | / | % | & | | | ^ | << | >> BinBoolOp : : = && | | | ArgList : : = [ <Expression > ( , <Expression > ) ]

40