Tutorial Uppaal

8/4/2019 Tutorial Uppaal

1/41

Tutorial de Uppaal

Joel Silva Carvalho e Simo Melo de Sousa

Universidade da Beira Interior

16 de Maro de 2009


2/41

Contedo

1 Introduo 3

1.1 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Limitaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Organizao do documento . . . . . . . . . . . . . . . . . . . . . . . 4

2 Uppaal 5

2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Autmatos Temporizados e Extenses . . . . . . . . . . . . . . . . . 5

2.2.1 Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Variveis inteiras limitadas . . . . . . . . . . . . . . . . . . . 62.2.4 Matrizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.5 Funes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.6 Posies urgentes . . . . . . . . . . . . . . . . . . . . . . . . 62.2.7 Posies committed . . . . . . . . . . . . . . . . . . . . . . 62.2.8 Sincronizaes por mensagem . . . . . . . . . . . . . . . . . 6

2.3 Modelao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Especificao Textual . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Especificao Grfica . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Simulao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Verificao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Correspondncias TCTL em Uppaal . . . . . . . . . . . . . . 132.5.2 Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.3 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.4 Liveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.5 Deadlock Freeness . . . . . . . . . . . . . . . . . . . . . . . 142.5.6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1


3/41

3 Casos de Estudo 16

3.1 Algoritmos de Dekker e Peterson . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Descrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 Simulao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.4 Verificao . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Biphase Mark Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1 Descrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.3 Verificao . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Exerccios 27

4.1 Exerccio 1 - Protocolo v1 . . . . . . . . . . . . . . . . . . . . . . . 274.2 Exerccio 2 - Protocolo v2 . . . . . . . . . . . . . . . . . . . . . . . 284.3 Resolues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Exerccio 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2 Exerccio 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A TA e XTA BNF 37

2


4/41

Captulo 1

Introduo

Este tutorial descreve o Uppaal como ferramenta de Model Checking para sistemas detempo real. O Uppaal surgiu em 1995 pela universidade de [Upp]sala e pela univer-sidade de [Aal]borg. Esta ferramenta permite manipular trs fases da elaborao domodelo do sistema. Na primeira fase o Uppaal permite a modelao do modelo, na se-gunda fase permite a realizao de simulaes sobre a execuo do modelo e na terceirafase permite a verificao do modelo. A combinao destas trs fases permite que asequipas 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 ferra-mentas auxiliares. Estas ferramentas merecem o seu destaque no entanto no no mbitodeste tutorial. Para mais informaes sobre este assunto recomenda-se a consulta dapgina oficial do Uppaal em http://www.uppaal.com.

1.1 Objectivo

Este tutorial serve como documento de iniciao utilizao do UPPAAL, quer no con-texto acadmico como empresarial, sintetizando alguma informao necessria para asua correcta e eficiente utilizao.

1.2 Motivao

Grande parte dos sistemas de tempo real so considerados crticos e como tal exigemcuidados acrescidos no desenvolvimento. Por exemplo, reforando a importncia da

fase de testes possvel reduzir o nmero de erros. No entanto os testes no so sufi-cientes porque no fornecem certezas, apenas reduzem o espao de incerteza. Torna-se evidente que as ferramentas de verificao representam uma mais-valia podendofornecer certezas.

3
http://www.uppaal.com/http://www.uppaal.com/http://www.uppaal.com/


5/41

Inclusivamente no desenvolvimento de sistemas crticos recomendvel utilizar-semais do que uma ferramenta de verificao. No caso especfico dos sistemas de tempo

real crticos possvel ver a combinao de ferramentas de verificao esttica comoo SPARK com ferramentas de verificao de modelos como o Uppaal[6]. Diferentestipos de ferramentas complementam-se e permitem a verificao de um maior nmerode propriedades.

1.3 Limitaes

A modelao e verificao de sistemas com a ajuda de ferramentas como o Uppaalpossuem todavia algumas limitaes. Nomeadamente porque aquilo que se verifica o modelo e no o sistema em si. O modelo necessita espelhar correctamente o que osistema representa para alm de ser fundamental identificar e definir adequadamente aspropriedades por verificar. De facto nada se pode afirmar sobre propriedades omissas.

1.4 Organizao do documento

Cap. 2 - Uppaal Introduo e descrio de aspectos funcionais do Uppaal, quer noque respeita modelao, como simulao e verificao. Juntamente so apresen-tados alguns conceitos tericos pertinentes.

Cap. 3 - Casos de Estudo Descrio de dois casos de estudo relacionados comalgoritmos de excluso mtua e descrio de um caso mais concreto de um protocoloutilizado na indstria.

Cap. 4 - Exerccios Enunciado e resoluo de exerccios prticos a realizar em Up-paal para testar a compreenso da ferramenta.

4


6/41

Captulo 2

Uppaal

2.1 Introduo

O Uppaal consiste numa aplicao cliente/servidor. O cliente (java) consiste numainterface grfica com um editor, um simulador e um verificador. Este cliente java co-munica com um servidor (C++) que nada mais do que o verificador de modelos(verifyta). Assim existem duas formas de verificar um modelo, uma recorrendo aplicao grfica 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 especificar o mod-elo do sistema. De seguida apresentam-se alguns conceitos sobre autmatos tempo-rizados 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 dequalquer tipo de variveis existente no Uppaal e servem essencialmente para gener-alizar a especificao dos autmatos.

2.2.2 Constantes

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

5


7/41

2.2.3 Variveis inteiras limitadas

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

2.2.4 Matrizes

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

2.2.5 Funes

O Uppaal permite definir e utilizar funes sintacticamente parecidas com a linguagemC. Estas funes so importantes nas transies onde necessrio realizar operaesmais complexas, um exemplo muito simples de uma declarao de funo bool

teste(int a)return (a>2);.

2.2.6 Posies urgentes

Uma posio identificada como urgente permite que os relgios locais a esse autmatono evoluam enquanto essa posio for mantida.

2.2.7 Posies committed

Uma posio committed para alm de funcionar analogamente anterior ela aindaobriga que a prxima transio tenha origem nesta posio. A utilizao deste tipo deposio 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 eo segundo utiliza canais de sincronizao (sincronizao por mensagem). Esta secoaborda este ltimo tipo de sincronizao que utilizado ao nvel das transies. Umatransio com sincronizao precisa de pelo menos uma transio emissora, talvez umaou mais transies receptoras e pelo menos um canal de sincronizao. O autmato quepretende comunicar envia o pedido de sincronizao recorrendo etiqueta !, antecedidado nome do canal de sincronizao, e o autmato receptor aguarda essa sincronizaocom a etiqueta ?, antecedida do mesmo nome.

Canais binrios

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

6


8/41

feita apenas entre duas transies. Neste tipo de canal a existncia de uma transioemissora implica a existncia de uma transio receptora.

Canais mltiplos

Apesar das sincronizaes tradicionais serem binrias possvel definir sincroniza-es de uma transio para um nmero arbitrrio de transies recorrendo aos canaisde sincronizao broadcast chan. Neste tipo de canal a existncia de uma transioemissora no implica a existncia de uma transio receptora, mas obviamente quesem a existncia de pelo menos uma transio emissora a sincronizao nunca ocorrena realidade.

Canais urgentes

Qualquer um dos tipos de canais anteriormente referidos ainda pode ser considerdo ur-

gente recorrendo palavra reservada urgent, por exemplo urgentbroadcastchana;.Isto obriga que as transies que usem este tipo de sincronizaes no utilizem re-stries 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, tex-tualmente ou graficamente. Ambas as formas possuem vantagens e desvantagens. Porexemplo, a especificao grfica torna-se bastante intuitiva mas muito mais complexade automatizar. Ao contrrio, a especificao textual permite ser automatizada, masrequer um profundo conhecimento da linguagem.

2.3.1 Especificao Textual

O Uppaal permite a leitura de trs tipos de ficheiros, no entanto a verso actual j spermite gravar no formato mais recente. O formato mais antigo consiste num ficheirode texto plano de extenso .ta com a especificao da rede de autmatos temporizados.Neste formato cada autmato definido por process seguido do nome, mas estes noso equivalentes aos templates anteriormente falados.

A partir da verso 3.0 foi introduzido o formato .xta, muito semelhante ao .ta eneste cada process corresponde realmente a um template com parmetros. O formato.xta permite ainda ser associado a um outro ficheiro .ugi que contm as coordenadas xe y dos objectos.

Na verso 3.2 foi introduzido o formato .xml. A expressividade deste tipo deficheiro semelhante ao .xta mas aqui os elementos so descritos recorrendo a tags.Este formato hoje utilizado nativamente pela interface grfica e possui como grandevantagem a possibilidade de conseguir gravar modelos sintacticamente mal definidospara posterior correco. No apndice A apresentado a sintaxe no formato BNF paraos ficheiros .xta e .ta.

7


9/41

Associado a estes formatos de ficheiros existe ainda o formato .q com a especi-ficao das propriedades que se pretendem verificar. Este formato uma mera lista

textual das propriedades, para mais informaes consultar a seco 2.5.

2.3.2 Especificao Grfica

A especificao grfica consiste na produo do modelo por intermdio do separadoreditor disponvel na interface grfica do Uppaal. Esta interface de modelao (verFigura 2.1) constituda por trs zonas distintas. A zona superior da interface incluio menu da aplicao, alguns cones de atalho e os separadores de navegao entre osdiferentes modos de visualizao (edio/simulao/verificao).

Figura 2.1: Interface de modelao do Uppaal.

Na zona inferior esquerda consta uma estrutura de opes que permite mudar entreas diferentes partes descritivas do modelo. A opo Declarations contm a especifi-cao das variveis globais do modelo (variveis inteiras, canais de sincronizao, rel-gios e constantes). A opo Template representa um autmato temporizado do mod-

elo que por sua vez pode ter declaraes locais. Por fim a opo System declarationscontm a declarao dos processos com a devida atribuio de parmetros.

Na zona inferior direita consta uma rea de trabalho que pode ser constituda portexto, no caso de uma das opes de declarao estar seleccionada, ou por uma repre-sentao grfica de um autmato, no caso de algum template estar seleccionado.

8


10/41

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 edgeno Uppaal. Na figura 2.3 apresentada a janela de edio de uma transio com algu-

mas opes preenchidas.

Select

O parmetro select permite atribuir um valor a uma varivel temporria (apenas vlidapara essa transio), dado um intervalo, de forma no determinista. Um exemplo dedeclarao possvel para um select i : int[0, 3]. Esta declarao permite que o ireceba um valor entre 0 e 3 (inclusive) e que seja utilizado nas declaraes das restantesopes da transio.

Guard

O parmetro guard serve para activar a transio sobre uma dada condio. Um exem-

plo 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 menosquatro unidades de tempo no relgio x.

9


11/41

Figura 2.3: Janela de propriedades de um Edge.

Sync

Outra forma de fazer evoluir os autmatos de forma "programada" recorrendo aoscanais de sincronizao. Com este parmetro possvel invocar ou activar uma ou maistransies utilizando um canal de sincronizao previamente definido (ver 2.2.8). Sem-pre que numa transio o parmetro sync tiver uma declarao semelhante seguintec1! significa que, pelo menos um outro autmato vai necessitar de uma transio semel-hante 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 dedeclarao x = 0. Considerando este x como sendo um relgio, esta declarao per-mite reinicializar o relgio o que prtica bastante comum na modelao de sistemastemporizados com Uppaal. O update tambm pode incluir a utilizao de funes ouat mesmo servir para invocar uma funo que no devolve nenhum valor mas quealtera variveis locais ou globais. Caso a funo invocada no tenha um impacto noestado do sistema a mesma torna-se intil e gerado um warning aquando da verifi-cao sintctica do modelo.

2.3.4 Locations

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

10

12/41

Figura 2.4: Janela de propriedades de uma Location.

Name

Cada estado possui idealmente (mas no obrigatoriamente) um nome que serve de iden-tificador para a linguagem de especificao do modelo e para a linguagem de especifi-cao de propriedades. Caso o nome seja definido o mesmo deve estar em conformi-dade com ambas as linguagens. Por exemplo um nome no pode comear por um valornumrico.

Invariant

Os invariantes surgem da teoria dos autmatos temporizados e so propriedades asso-

ciadas aos estados. Quando um invariante I associado ao estado P, ento P tem deverificar necessariamente I quando o mesmo tem o controlo. Quando I deixa de serverificado P tem de deixar o controlo, isto , uma transio deve ser executada. NoUppaal, os estados que violem o seu invariante so indefinidos, por definio estes es-tados no existem.

Nesta ferramenta os invariantes so expresses limitadas a conjunes de condiessimples sobre relgios, diferenas entre relgios e expresses booleanas que no en-volvem relgios. Quando um invariante envolve a comparao do valor de um relgiocom um inteiro no permitido verificar se o tempo maior do que o inteiro ou es-tritamente igual, por exemplo a > 4 ou a == 4. Assim apenas possvel utilizarexpresses como a < 4 ou a


13/41

2.4 Simulao

A simulao no um processo fundamental para a verificao de modelos no entantotorna-se til e intuitiva para uma avaliao eficiente aquando da construo do modelo.Dada a especificidade dos modelos possvel recorrer simulao para realizar ajustese correces. Inclusivamente com o problema da exploso de estados pode acontecerque um modelo complexo no seja facilmente verificvel. Neste tipo de situaes asimulao torna-se ainda mais importante.

Interface

O simulador do Uppaal permite trs modos de funcionamento distintos. No primeiroo utilizador executa a simulao passo a passo sendo livre de escolher a transio quepretende fazer. No segundo o utilizador executa a simulao de forma automtica ealeatria podendo controlar a velocidade de simulao. No terceiro o utilizador pode

percorrer execues anteriormente realizadas. Cada um destes modos de funciona-mento pode ser intercalado a qualquer momento dando ao simulador toda a sua flexi-bilidade.

Como possvel constatar na figura 2.5 a interface do simulador composta pordiversas janelas. Na janela mais esquerda possvel controlar os modos de execuodo simulador. Na janela logo direita so listadas todas as variveis do sistema. Najanela inferior direita so apresentadas as sincronizaes entre os diferentes autmatosbem como os estados activos. Na janela logo acima desta so apresentados todos osautmatos e a vermelho as transies e estados activos.

Figura 2.5: Interface de simulao do Uppaal.

12


14/41

2.5 Verificao

A verificao de modelos um processo automatizado por algoritmos que permitemconfirmar que dadas propriedades esto presentes na representao feita do sistema.Estando a verificao de modelos baseados em autmatos temporizados associada algicas temporais, torna-se necessrio classificar os diferentes tipos de propriedades.

O Uppaal recorre a uma fraco da lgica TCTL no permitindo por exemplo acombinao de mltiplos quantificadores de caminho.

2.5.1 Correspondncias TCTL em Uppaal

Correspondncias entre a Lgica TCTL e a especificao 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 especificar que uma situ-ao pode ser atingida. Sendo uma frmula de estado, a especificao desta pro-priedade faz-se recorrendo ao quantificador E e ao combinador F: EF . Por outraspalavras, diz-se que seguindo uma das execues, pode ser verificado.

Por exemplo num sistema de controlo de acessos, esta propriedade permite validarque 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 especificar que algo negativonunca vai acontecer. Este tipo de propriedades pode limitar-se a uma execuo ouabranger o conjunto de todas as execues possveis. Sendo uma frmula de estado,a especificao desta propriedade faz-se recorrendo quer ao quantificador E como aoquantificador A e ao combinador G: AG ou EG.

Este tipo de propriedades fundamental para garantir situaes crticas num mod-elo. Recorrendo ao exemplo de um sistema de controlo de acessos com fecho au-tomtico de portas, esta propriedade permite validar que uma porta nunca fica abertamais de x unidades de tempo. Ou no caso de existirem vrias portas, como nos bancos,

13


15/41

que nunca esto abertas simultaneamente duas portas.

Em Uppaal as propriedades de segurana so expressas de forma positiva: A[] ouE[]. Sendo que na primeira especificao (com o quantificador universal A) obri-gatoriamente verdade em todos os estados. Enquanto na segunda (com o quantificadorexistencial E) verdade em todos os estados de uma execuo possvel.

De notar que as restantes propriedades podem ser traduzidas em propriedades destesdois ltimos tipos via tcnicas conhecidas.

2.5.4 Liveness

As propriedades de evoluo permitem especificar que dentro de determinadas condiesalgo inevitavelmente vai acontecer.

Recorrendo ao exemplo de um sistema de controlo de acessos, esta propriedadepermite validar que quando algum identificado inevitavelmente uma porta vai abrir.

Em Uppal estas propriedades so expressas da seguinte forma: A ou >. Sendo que a primeira especificao significa que inevitavelmente verdade nal-gum estado de todas as execues. E a segunda significa que sempre que for verdadeento tambm vai ser verdade nalgum estado de todas as execues seguintes.

2.5.5 Deadlock Freeness

Por fim a propriedade de ausncia de deadlock permite especificar que o sistema noentra 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 verificao possui uma lista de propriedades que pode ser seleccionadae aumentada ou reduzida. Cada propriedade possui uma declarao (query), um textoassociado que facultativo (comment) e um objecto que representa a propriedade nalista. Quando uma prioridade avaliada a mesma fica com o indicador a verde ouvermelho. O verde significa que a propriedade foi correctamente verificada pelo algo-ritmo de verificao de modelos enquanto o vermelho significa o contrrio. Sempreque uma propriedade no verificada o Uppaal permite construir um contra-exemploque fica exposto no ambiente de simulao. No entanto esse contra-exemplo no construdo por defeito. Para que isso seja feito necessrio ir ao menu Options >

DiagnosticTrace e escolher uma das trs opes Some, Shortest ou Fastest.

14


16/41

Figura 2.6: Interface de verificao do Uppaal.

15


17/41

Captulo 3

Casos de Estudo

Como casos de estudo so apresentados os modelos de dois algoritmos de exclusomtua, mais precisamente o algoritmo de Dekker e de Peterson. Estes algoritmos nopossuem qualquer restrio temporal, no entanto pela sua simplicidade tornam-se bonsexemplos 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 trintapropriedades especificadas e verificadas.

As referncias principais para este captulo so [7][1][9].

3.1 Algoritmos de Dekker e Peterson

3.1.1 Descrio

Estes algoritmos permitem que dois processos partilhem um recurso conjunto recor-rendo apenas memria partilhada. O primeiro algoritmo foi definido 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 talcomo na Figura 3.2 para o modelo do algoritmo de Peterson. Ambos os modelospossuem a particularidade de serem constitudos por dois autmatos (representandoos processos consumidores) que so nada mais do que uma declarao duplicada do

template de cada um com alterao dos respectivos parmetros de entrada (ver Listing3.1 e Listing 3.2).

Listing 3.1: Declarao dos processos de sistema do modelo do algoritmo de Dekker.

/ / I n s e r t p r o c e s s a s s i g n m e n t s .

P0 = P r o c e s s ( 0 ) ;

16


18/41

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


19/41

P1 = P r o c e s s ( 1 ) ;

/ / E d i t s y s t e m d e f i n i t i o n .s ys 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 ) ;

sys tem P0 , P1 ;

Os dois modelos utilizam tambm algumas variveis globais (ver Listing 3.3 e List-ing 3.4) para permitir que a excluso mtua seja devidamente realizada. A ausncia decanais de sincronizao entre os autmatos justifica-se pela vontade de representar fiel-mente os algoritmos.

Listing 3.3: Declarao das variveis globais do modelo do algoritmo de Dekker.

b oo l f l a g [ 2 ] = { f a l s e , f a l s e } ;i n t t u r n = 1 ;

No caso do algoritmo de Dekker declarada uma matriz booleana flag de dois el-ementos, inicializados a false, e uma varivel inteira turn, inicializada a 1. A varivelflag indica a inteno dos processos entrarem na zona crtica e a varivel turn indicaqual dos processos possui prioridade para aceder zona crtica.

Listing 3.4: Declarao das variveis globais do modelo do algoritmo de Peterson.

c on s t i n t N = 2 ;i n t [ 0 , 1 ] f l a g [N ] ;

i n t [ 0 , 1 ] t u r n ;

semelhana do caso do algoritmo de Peterson declarada uma constante inteiraN, inicializada com o valor 2, uma matriz de inteiros flag de N elementos limitadosaos valores 0 e 1 e uma varivel inteira turn. As variveis inteiras que no so ini-cializadas assumem por defeito o valor 0 ou o valor do limite inferior caso elas tenhamum limite definido na sua declarao. A constante N define o tamanho da matriz flagenquanto as duas restantes variveis assumem a funo descrita no caso do algoritmode Dekker.

De notar ainda que no autmato a matriz de inteiros actualizada com valoresbooleanos em vez de valores inteiros. semelhana do que acontece em C, o Uppaalassume valores inteiros para cada uma das expresses booleanas true (1) e false (0).

Observando detalhadamente o modelo do algoritmo de Dekker (Figura 3.1) verifica-se que o mesmo inicia a sua execuo actualizando a flag do processo corrente paratrue (Update flag[pid] = true) indicando a inteno de aceder zona crtica. Noestado seguinte existem duas execues possveis (Guard flag[1 pid] == true eGuard flag[1 pid] == false) consoante o outro processo esteja ou no a pedir

18


20/41

acesso zona crtica.

No caso do outro processo no requerer acesso zona crtica a execuo do pro-cesso corrente entra directamente na zona crtica (estado critical_section) e efectuaduas actualizaes seguidas (Update turn = 1 pid e Update flag[pid] = false)voltando ao estado inicial remainder. A actualizao turn = 1 pid indica que ooutro processo ganha prioridade e a actualizao flag[pid] = false remove a indi-cao de acesso zona crtica por parte do processo corrente.

No caso do outro processo estar a pedir acesso zona crtica so avaliadas maisduas guardas turn == pid, turn == 1 pid. Estas permitem verificar qual dos pro-cessos possui prioridade no acesso zona crtica. Caso a prioridade esteja do lado doprocesso corrente ento o modelo volta a avaliar a flag do outro processo. Caso con-trrio a flag do processo corrente alterada para false (Update flag[pid] = false) ea execuo seguinte fica avaliar as guardas turn == 1 pid, turn == pid.

Estas guardas esto numa posio do ramo diferente no entanto so uma repetiodas anteriores com uma ligeira nuance, desta vez no existe transio de estado en-quanto o outro processo tiver prioridade de acesso zona crtica. Assim que o processocorrente ganhe prioridade no acesso zona crtica ento feita uma nova actualizaoflag[pid] = true para indicar a inteno de acesso zona crtica e o modelo volta aavaliar se existem condies para que o acesso seja feito.

Observando detalhadamente o modelo do algoritmo de Peterson (Figura 3.2) verifica-se algo semelhante. Partindo do estado inicial a execuo do modelo comea por fazerduas actualizaes de variveis. A primeira flag[pid] = true indica a inteno doprocesso 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 verificamse flag[1 pid] false ou true.

Se o outro processo no indicou inteno de aceder zona crtica (Guard flag[1pid] == false) ento o modelo entra na zona crtica (estado cs). Posteriormente aexecuo volta ao estado inicial actualizando a inteno do processo corrente em nopretender aceder zona crtica (Update flag[pid] = false).

Se em contrapartida o outro processo indicou inteno de aceder zona crtica(Guard flag[1 pid] == true) ento o modelo realiza uma segunda verificao masdesta vez sobre a varivel turn. Se a prioridade de acesso zona crtica for do outroprocesso turn == 1pid ento o modelo volta ao estado anterior para nova avaliaocaso 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 verificar que ambos os modelos possuemdois processos designados por P0 e P1, tal como foi descrito nas declaraes de sis-

19


21/41

tema. A simulao destes dois modelos permite verificar se a sua execuo retrata ocomportamento desejado dos algoritmos. Apesar de aqui no existir uma relao for-

mal entre os modelos e o respectivo algoritmo de excluso mtua possvel, mesmoassim, tirar algumas concluses sobre o seu funcionamento.

Algo especialmente interessante para este tipo de problemas o de poder verificarvisualmente e das formas j descritas se o modelo realmente est a fazer aquilo que sepretende. Esta metodologia pode inclusivamente ser utilizada para introduzir estes con-ceitos de uma forma bastante prtica. Programando estes algoritmos numa linguagem"no formal", no existe a possibilidade de visualizar directamente ou verificar formal-mente possveis problemas.

Neste tipo de simulao o mesmo j no acontece. muito intuitivo perceber queo modelo avalia as variveis descritas e consoante os seus valores o acesso zonacrtica dada a um ou outro processo. Inclusivamente possvel verificar a validade dealgumas propriedades do modelo tal como vai ser visto na seco seguinte.

Figura 3.3: Simulao do modelo do algoritmo de Dekker.

3.1.4 Verificao

A verificao destes dois modelos consiste na verificao de duas propriedades. Naprimeira verifica-se, como de costume, se existe ou no deadlock freeness recorrendo seguinte especificao A[]notdeadlock. Executando a verificao desta propriedadeno Uppaal verifica-se que realmente ambos os modelos a cumprem.

20


22/41

Figura 3.4: Simulao do modelo do algoritmo de Peterson.

Na segunda verifica-se que em todas as execues possveis o modelo nunca estsimultaneamente na zona crtica dos dois processos. Essa especificao de propriedadede segurana faz-se em Uppaal com a seguinte frmula A[] (not (P0.cs and P1.cs)).

3.2 Biphase Mark Protocol

3.2.1 Descrio

Como terceiro caso de estudo apresenta-se o modelo do Biphase Mark Protocol. Esteprotocolo largamente utilizado especialmente para comunicao ao nvel fsico daarquitectura OSI. O mesmo encontra-se implementado em micro controladores comoo Intel 82530 Serial Communications Controler.

Resumidamente neste protocolo cada bit de uma mensagem codificado numaclula que consiste num nmero de ciclos do relgio divido logicamente numa marksubcell e numa code subcell. Tal como se pode ver na Figura 3.5 sempre que estas duassubcells formarem um par de sinais iguais (1 e 1 ou 0 e 0) o bit da mensagem corre-spondente 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 sincronizaodos relgios do codificador e do descodificador feita no incio de cada clula.

21


23/41

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 figura por rectngulos)que comunicam quer por variveis globais (representadas por crculos) como por sin-cronizaes (representadas por setas).

Figura 3.6: Arquitectura do modelo do BMP.

De forma sucinta descreve-se de seguida a funcionalidade de cada um dos aut-matos:

[Clock()] (Figura 3.7) - Modelao lgica do relgio fsico do sistema do ladodo codificador. Este autmato produz ticks, no confundir com as variveis de

relgio do Uppaal. [Coder()] (Figura 3.9) - Modelao do processo de codificao. Atravs de uma

sequncia de bits (varivel in) e dos ticks do relgio (do autmato Clock())gera-se uma onda quadrada.

22


24/41

[Wire()] (Figura 3.11) - Modelao do processo de transformao da onda quadrada(dita perfeita) num sinal digital.

[Clock2()] (Figura 3.8) - Semelhante ao Clock() mas desta vez para o descodi-ficador.

[Sampler()] (Figura 3.12) - Modelao do processo de cpia peridica do valorde w para new.

[Decoder()] (Figura 3.10) - Modelao do processo de descodificao. Aquandode um novo tick se este autmato observar uma alterao da varivel new elecomea a contagem de um nmero especfico de ticks e compara o valor inicialda varivel new com o seu valor final. De seguida actualiza a varivel out einforma o Tester() da actualizao atravs da sincronizao put.

[Tester()] (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 parmetrosnos 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 utilizadasso globais (ver Listing 3.5).

Listing 3.5: Declarao das variveis globais do modelo do BMP.

/ / G l o b a l D e c l a r a t i o n s

c ha n t i c k , t oc k , e dg e , g et , p u t ;b r o a d c a s t c ha n f uz z , s e t t l e , S am pl e ;i n t m , n ;b o ol i n , o ut , v , w , s , new , o ld , b uf ;

c l o c k x , y , z ;c on s t i n t c e l l = 1 4 , m ar k = 7 , s a m p le = 1 0 ;c on s t i n t m in = 9 3 , max = 1 00 , 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 C od er , C l oc k , W ir e , S a mp l er , C lo ck 2 , D e co d er , 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) reinicializadasa 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. Ambospossuem uma guarda que activa a respectiva transio apenas quando a mesma forverdade. Deste modo o Clock() s produz um tick entre as 93 e as 100 unidades detempo tal como o Clock2(), mas este ltimo ainda precisa que a varivel s tenha ovalor true (1). Esta varivel serve para que o Sampler() apenas seja executado umavez por cada tick do Clock2().

23


25/41

Figura 3.7: Clock(). Figura 3.8: Clock2().

Figura 3.9: Coder().

Figura 3.10: Decoder().

Figura 3.11: Wire().

Figura 3.12: Sam-pler().

Figura 3.13: Tester().

24


26/41

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 oTester() efectuar a sincronizao get! o Coder() transita para o estado C1 (tambmele 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 for1 o autmato fica no estado C2 durante 6 ticks do Clock(), a transio para o estadoC4 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 14 o tick(contando do nicio). Se em contrapartida o bit for 0 o autmato passa directamentepara o estado C3 gerando uma aresta na transiao e ao 14o tick do Clock() gera outraao voltando ao estado inicial.

Wire()

Este autmato introduz o pressuposto que indica que um sinal elctrico s estabilizaaps algum tempo da ocorrncia de uma aresta da onda quadrada. Assim considera-seque no estado W0 o sinal estvel enquanto no estado W1 no. Para os parmetros quepermitem que o protocolo esteja correcto fundamental que o Coder() nunca gere umanova aresta enquanto o sinal instvel, isto , enquanto o Wire() se encontre no estadoW1. No caso de ser gerada uma nova aresta sobre estas condies ento o Wire() passaao estado W2. No entanto a verificao do modelo vai provar que esta situao nuncaocorre.

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 umavarivel booleana s.

Decoder()

O Decoder() modela o processo de descodificao do sinal recolhido pelo Sampler().De forma anloga ao Coder() este autmato rege a sua execuo por ticks, mas destafeita do Clock2(). No estado inicial cada tick responsvel pela comparao do valorrecolhido do Sampler() com o valor anterior. Enquanto os valores forem iguais o pro-cesso de comparao repete-se. Assim que for detectada uma variao no sinal o aut-mato passa para o estado D1 armazenando o ltimo valor recolhido. A execuo vaimanter-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 novamenteavaliado se o valor do sinal recolhido naquele momento pelo Sampler() o mesmodo que o inicial para permitir gerar o bit correspondente. Isto , se os valores foremdiferentes o bit gerado vai ser 1 caso contrrio 0. Quando a execuo voltar ao estadoinicial efectuada a sincronizao put! para informar o Tester() de que um novo bit foigerado.

25


27/41

Tester()

Este autmato selecciona no deterministicamente bits e coloca-os na varivel in, pos-teriormente confirma se os bits recebidos atravs da varivel out correspondem aosanteriores. Sempre que for observada uma diferena nos valores o autmato entra numestado de erro. Se o modelo estiver correcto esse estado nunca atingido.

3.2.3 Verificao

Das 39 propriedades especificadas para este modelo descrevem-se apenas as seguintes:

A[] Coder.C0 imply Tester.T0 - Sempre que o Coder est no estado inicial issoimplica que o Tester tambm se encontre no seu estado inicial.

A[] not (Tester.T2 or Tester.T3 or Tester.Error) - Para qualquer execuo o Testernunca atinge o estado T2, T3 ou Error. Esta verificao acaba por ser redundantecom a de deadlock freeness porque em ambas as situaes se esses estados soatingidos o modelo entra em deadlock.

A[] Coder.C0 or Coder.C1 imply n == 0 - Sempre que o estado C0 ou C1 doCoder o estado corrente ento a varivel n tem de ser igual a 0. Isto , ocontador de ticks tem de estar reinicializado.

A[] Decoder.D0 imply m == 0 - Sempre que o Decoder est no estado D0 entoa varivel m tem de ser igual a 0. Anlogo ao anterior.

A[] y >= 0 and y

28/41

Captulo 4

Exerccios

Neste captulo apresentam-se alguns exerccios a resolver com a ferramenta de veri-ficao de modelos Uppaal. Estes exerccios contemplam quer a modelao, como asimulao e a verificao dos modelos. No fim do captulo encontram-se resoluespara os exerccios propostos. No entanto vivamente recomendado que essas res-olues s sejam consultadas no fim 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 implementaode um protocolo com trs componentes interligadas: emissor, meio e receptor (ver

Figura 4.1).

O emissor transmite uma mensagem de tamanho fixo. Esse tamanho corre-sponde ao tempo entre o incio do envio e o fim do envio da mensagem.

O meio corresponde componente central responsvel pela passagem da men-sagem do emissor para o receptor. Este meio introduz um atraso fixo na comu-nicao que corresponde ao tempo entre o incio do envio por parte do emissor eo incio da recepo por parte do receptor ou o fim do envio por parte do emissore o fim 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 doenvio (por parte do emissor) ter sido finalizado.

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


29/41

Figura 4.1: Esquema das componentes do protocolo.

nem o emissor do atraso. O sistema modela-se com uma rede de autmatos sin-

cronizados, utilizando o incio e fim de comunicao do emissor e do receptor comosincronizaes com o meio.

Pretende-se ainda que o modelo seja verificado garantido a no existncia de dead-locks e identificando qual o tempo decorrido do incio do envio at ao fim da recepoda mensagem.

4.2 Exerccio 2 - Protocolo v2

Este exerccio consiste na alterao do protocolo modelado anteriormente de modoa que o mesmo agora consiga lidar com mensagens de tamanho maior que o atrasodo meio. Nesta verso no exigido que o modelo seja rigoroso, admite-se a possi-bilidade das execues nem sempre escolherem a forma mais rpida de comunicar amensagem. Isto partindo do princpio que o meio continua a no conhecer o tamanhoda mensagem.

Pretende-se que o modelo seja verificado pelo menos com as propriedades anteri-ormente definidas.

28


30/41

4.3 Resolues

29


31/41

4.3.1 Exerccio 1

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

Figura 4.2: Modelo com sincronizaes no urgentes.

Nestas duas solues as execues no so realmente paralelas, porque seguemuma sequncia linear que se repete, logo o facto de utilizar, ou no, sincronizaes ur-

30


32/41

Figura 4.3: Modelo com sincronizaes urgentes.

31


33/41

gentes no provoca alteraes nos modelos.No caso contrrio o mesmo poderia j nose verificar, excepto se os estados intermdios fossem sempre committed.

A declarao de variveis globais e declarao de variveis locais de ambos osmodelos so iguais (ver Listing 4.1 e 4.2).

Listing 4.1: Declarao de variveis globais.

/ / P l a c e g l o b a l d e c l a r a t i o n s h e r e .

c l oc k t g l o b a l ;bool m_e nvi ada ;

Listing 4.2: Declarao de variveis locais do Meio.

c l oc k a t r a s o _ i , a t r a s o _ f ;

J a declarao de sistema muda ligeiramente devido existncia dos canais desincronizao urgentes e no urgentes. Na Listing 4.3 possvel ver uma declaraocompleta e na Listing 4.4 apresenta-se a diferena do modelo com os canais de sin-cronizao urgentes.

Listing 4.3: Declarao de sistema do modelo da Figura 4.2.

/ / P l a c e t e m p l a t e i n s t a n t i a t i o n s h e r e .

c ha n i n i c i o _ e , f im _e , i n i c i o _ r , f i m _r ;c on s t i n t t am an ho = 3 , a t r a s o = 1 0;

e = E m i s s o r ( i n i c i o _ e , f i m_ e , t a ma n ho ) ;r = R e c ep t o r ( i n i c i o _ r , f i m_ r ) ;m = Meio ( i n i c i o _ e , f im _e , i n i c i o _ r , f im _ r , a t r a s o ) ;

/ / L i s t on e o r mo re 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 te 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 ha n i n i c i o _ e , f im _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 mod elo

/ / se m 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 apsterem sido apresentadas todas as declaraes sabe-se que cada template vai dar origema um nico autmato do modelo. Existindo trs estados iniciais a execuo poderiacomear por qualquer um deles, mas dois dos estados iniciais esperam por sincroniza-

es. Assim s existe uma primeira execuo possvel que consiste na transio parao estado Envio do Emissor. A primeira transio para alm de umas actualizaes devariveis 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 ecoloca o Meio no estado Recepcao.

32


34/41

De seguida s possvel executar a transio que volta a por o autmato Emis-sor no estado Pronto. Existe uma guarda nessa transio indicando que tglobal >=tamanho, logo a transio s vai ser activada quando for atingida esta condio. Poroutras palavras, a execuo s evolui, finalizando o envio da mensagem, quando otempo correspondente ao tamanho da mensagem passar. Esta transio faz ainda umasincronizao com o Meio para permitir que de seguida seja iniciado o processo derecepo da mensagem por parte do Receptor. No esquecer que a mensagem total-mente enviada antes de ser iniciado este processo porque partiu-se do pressuposto queo tamanho sempre menor que o atraso.

A prxima execuo consiste na transio para o estado Envio do Meio. Nestatransio possvel verificar a existncia da guarda atraso_i >= atraso que permiteque a evoluo do autmato s seja realizada quando o tempo de atraso tenha sidoatingido. A transio inicia o processo de recepo da mensagem por parte do receptoratravs da sincronizao colocando o Receptor no estado Recepcao.

A execuo seguinte remete o Meio para o estado Pronto. A transio responsvelpor essa execuo possui a guarda atraso_f >= atraso indicando que a evoluo s feita quando o atraso de finalizao do processo de comunicao seja cumprido. Estatransio faz ainda uma sincronizao com o Receptor, por sua vez a transio do Re-ceptor realiza a actualizao m_enviada = true. Esta actualizao permite saberquando o Receptor est no estado Pronto se o tglobal contm o tempo total de comu-nicao ou se o mesmo j foi reinicializado.

Simulando e estudando este protocolo chega-se concluso que o tempo total decomunicao corresponde soma do tamanho com o atraso. Assim o modelo deve veri-ficar correctamente as propriedades A[] not deadlock e A[] (r.P ronto and m_enviada ==

true imply tglobal >= (tamanho + atraso)). Outra propriedade que pode ser in-teressante verificar E (r.P ronto and m_enviada == true and tglobal = atraso limitando a evoluo do modelo a este ramo apenas quando esta

33


35/41

Figura 4.4: Meio do modelo com sincronizaes no urgentes.

Figura 4.5: Meio do modelo com sincronizaes urgentes.

34


36/41

condio se verificar primeiro que a sincronizao que segue o outro ramo.

Em termos de verificao as duas solues seguem o comportamento do exerccioanterior, o que seria de esperar uma vez que as propriedades definidas mantm-se. Noentanto se for pretendido um modelo rigoroso, nota-se com a simulao, que em ambasas solues o Meio necessita conhecer o tamanho da mensagem para tomar a decisocorrecta sobre qual dos ramos a executar.

35


37/41

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 verification: model-checking techniques and tools. Springer-Verlag New York, Inc., New York, NY, USA, 1999.

[4] Hugh Anderson. Verification of real time systems - cs5270 (lecture11). 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. InMarco Bernardo and Flavio Corradini, editors, Formal Methods for the Design ofReal-Time Systems: 4th International School on Formal Methods for the Design of

Computer, Communication, and Software Systems, SFM-RT 2004, number 3185 inLNCS, pages 200236. SpringerVerlag, September 2004.

[6] A. Burns and T. M. Lin. An engineering process for the verification of real-timesystems. Form. Asp. Comput., 19(1):111136, 2007.

[7] R. "Hamberg and F.W."Vaandrager. "Using Model Checkers in an IntroductoryCourse on Operating Systems". Technical Report "ICISR07031", "Radboud Uni-versity Nijmegen", "December2007".

[8] Kim G. Larsen, Paul Pettersson, and Wang Yi. UPPAAL in a Nutshell. Int. Journalon 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 Up-paal and PVS. Formal Aspects of Computing Journal, 18(4):433458, December2006.

36
http://www.ita.cs.ru.nl/publications/papers/fvaan/MCinEdu/mutex.htmlhttp://www.ita.cs.ru.nl/publications/papers/fvaan/MCinEdu/mutex.htmlhttp://www.it.uu.se/edu/course/homepage/realtid/p1ht08/uppaalhttp://www.it.uu.se/edu/course/homepage/realtid/p1ht08/uppaalhttp://www.it.uu.se/edu/course/homepage/realtid/p1ht08/uppaalhttp://www.comp.nus.edu.sg/~cs5270/2006-semesterII/foils11.print.pdfhttp://www.comp.nus.edu.sg/~cs5270/2006-semesterII/foils11.print.pdfhttp://www.comp.nus.edu.sg/~cs5270/2006-semesterII/foils11.print.pdfhttp://www.comp.nus.edu.sg/~cs5270/2006-semesterII/foils11.print.pdfhttp://www.it.uu.se/edu/course/homepage/realtid/p1ht08/uppaalhttp://www.it.uu.se/edu/course/homepage/realtid/p1ht08/uppaalhttp://www.ita.cs.ru.nl/publications/papers/fvaan/MCinEdu/mutex.htmlhttp://www.ita.cs.ru.nl/publications/papers/fvaan/MCinEdu/mutex.html

38/41

Apndice A

TA e XTA BNF

Informao retirada da pgina pessoal do Professor Gerd Behrmann. Esta sintaxeassemelha-se da linguagem C, tanto que possvel declarar funes C dentro daespecificao 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 > O l d D e c l a r a t i o n : : = < V a r i a b l e D e cl > | < O ld C on s tD e cl >

| < Ol dPr oc De c l >O l dC o ns t De c l : : = c o n s t < O l dC o ns t D ec l Id >

( , < Ol dCons t De c l I d > ) ; O l d C o n s t D e c l I d : : = ID < A r r a y D ec l > [ ]

O l dP r oc D e cl : : = p r o c e s s ID [ < O ld Pr oc P ar am s > ] { < Ol dPr oc Body> }

O l d P ro c P ar a m s : : = ( [ < O ld P ro c Pa r am >( ; ) ] )

Ol dPr oc Pa r a m : : = < Type > I D < Ar r a yDe c l > ( , I D < Ar r a yDe c l > )| c o n s t ID < A rr a yD e cl > ( , ID )

O l dP r oc B od y : : = ( < V a r De c l > | < O l dC o n st D e cl > )< O l d S t a t e s > [ < Commit > ] [ ] [ < 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 < O l d S t a te D e c l > ( , < O l d S t a te D e c l > ) ; O l d S ta t e D ec 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 : : = < E x p r e s si o n > ( , < E x p r e s si o n > )

O l d T r a n s i t i o n s : : = t r a n s < O l d T r a n s i ti o n >( , < O l d T r a n s i t i o n O p t > ) ;

O l dT r a ns i t i o n : : = ID > I D < Ol dTr a ns Body>O l dT r an si t io n Op t : : = O l dT r a ns i t i o n | > I D < Ol dTr a ns Body>

37
http://www.cs.aau.dk/~behrmann/utap/syntax.htmlhttp://www.cs.aau.dk/~behrmann/utap/syntax.html

39/41

O l dT r an s Bo d y : : = { [ < O l dG ua rd > ] [ < S yn c > ] [ < A s s i g n > ] }

O ld G ua rd : : = 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 > D e c l a r a t i o n : : = < F u n c ti o n D ec l > | < V a r i a b l e D ec l > | < Ty pe De cl >

| < Pr oc De c l >I n s t a n t i a t i o n : : = ID ASSIGNMENT ID ( ) ; S ys te m : : = s y s te m ID ( , ID ) ;

P a r a m e t e r L i s t : : = ( [ ( , ) ] ) P a r a m e t e r : : = [ & ] ID < A r r ay D ec l >

F u n c t i o n D e c l : : = ID 

P r o cD e c l : : = p r o c e s s ID { < Pr oc Bo dy > } P ro c Bo dy : : = ( < F u n c t i o n D e c l > | < V a r i a b l e D e c l > | < Ty pe De cl > )

< S t a t e s > [ < C om mit > ] [ ] [ < 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 te D e c l > ( , < S t a te D e c l > ) ; S t a t e D e c l : : = ID [ { < E x pr e ss i on > } ]

Commit : : = commit S t a t e L i s t ; U rg en t : : = u r ge n t 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 io 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 ns i t i o nO p t : : = T r a ns 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 : : = { [ < G u ar d > ] [ < S yn c > ] [ < A s s i g n > ] }

G ua rd : : = g u a rd < E x p r e s si o n > ; S yn c : : = s yn c < E x pr e ss i on > ( ! | ? ) ; A s s ig n : : = a s s i g n < E x p r L i st > ;

T y pe D ec l : : = t y p e d e f < Ty pe > < T y p e I d L i s t >( , < Typ e I dLi s t >) ;

T y p e I d L i s t : : = ID < A rr a yD e cl >

Listing A.3: BNF da declarao de variveis

V a r i a b l e D e c l : : = < Ty pe > < D e c l Id > ( , < D e c lI d > ) ; D e c l Id : : = ID < A rr a yD e cl > [ ASSIGNMENT ]

38

40/41

I n i t i a l i s e r : : = | { < 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 : ] 

A r r ay D e cl : : = [ < E x p r e s si o n > ]

T yp e : : = I D [ < Rang e > ]| < Pr ef ix > s t r u c t { < F i e l d D e c l >+ }

F i e l d D e c l : : = < 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 ay D ec l >

P r e f ix : : = ( [ u rg en t ] [ b ro a dc as t ] | [ c on st ] )R an ge : : = [ < E x p r e s si o n > , < E x p r e ss i o n > ]

Listing A.4: BNF das instruesB lo ck : : = { ( < V a ri a b le D e cl > | < Ty pe De cl > ) < St a t e me nt > } S t a t em e n t : : = < Bl oc k >

| ; | < E xp re ss io n > ; | f o r ( < E x p r L i st > ; < E x p r L i st > ;

< E x p r L i s t > ) < S t a t e m e n t >| wh i l e ( < E x p r L i st > ) < S t a t em e n t >| do < S t a t em e n t > wh i l e ( < E x pr L is t > ) ; | i f ( < E x p r L i st > ) < S t a t em e n t >

[ e l s e < S t a t em e n t > ]| b re ak ; | c o nt i nu e ;

| s w i tc h ( < E x p r L i st > ) { < Ca se >+ } | r e t ur n ; | r e t u r n < E x pr e s si o n > ;

Case : : = c as e < E xp re ss io n > : < S ta te me nt >| d e f a u l t : < S ta te m en t >

Listing A.5: BNF das expresses

E x p r L i s t : : = < E x pr e ss i o n > ( , < E x pr e s si o n > )E x pr e ss i on : : = ID

| NAT| t r u e | f a l s e | ID ( < Ar gL is t > )

| < E x pr e ss i on > [ < E x pr e ss i on > ] | ( < Ex pr es si on > ) | < E xp re ss io n > ++ | ++ < E xp re ss io n >| < Ex pr es si on > | < E x p r e s s i o n >| < E x p r e s si o n > < As si gn Op > < E x p r e s s i o n >| < UnaryOp > < E x p r e s si o n >

39

41/41

| < E x pr e ss i on > < Re l > < E xp r es s io n >| < E x p r e s si o n > < E x p r e s s i o n >

| < E x p r e s si o n > < Bin Bo olO p > < E x p r e ss i o n >| < E x pr e ss i on > ? < E x pr e ss i on > : < E x pr e ss i on >| < Ex pr es si on > . ID>

AssignOp : : = ASSIGNMENT | += | = | = | /= | %=| |= | &= | ^= | =

U na ry Op : : = | ! Re l : : = B in In tO p : : = + | | | / | % | & | | | ^

| > B in Bo ol Op : : = && | | | A r g L is t : : = [ < E x pr e s si o n > ( , < E x pr e s si o n > ) ]

Documents

Tutorial Uppaal