U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
PROGRAMAC
¸ ˜
AO DE REDES SENSORES BASEADA
EM EVENTOS
Bruno Alexandre Valdez Fernandes
DISSERTAC
¸ ˜
AO
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Engenharia de Software
2014
U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
PROGRAMAC
¸ ˜
AO DE REDES SENSORES BASEADA
EM EVENTOS
Bruno Alexandre Valdez Fernandes
DISSERTAC
¸ ˜
AO
MESTRADO EM ENGENHARIA INFORM ´
ATICA
Especializac¸˜ao em Engenharia de Software
Dissertac¸˜ao orientada pelo Prof. Doutor Francisco Cipriano da Cunha Martins
Agradecimentos
Aos meus av´os por me terem dado a oportunidade de poder ter tirado tanto o Mestrado como a Licenciatura. Sem eles este meu percurso acad´emico n˜ao seria poss´ıvel. Por isso a sua ajuda foi muito importante.
Ao meu irm˜ao por ser um chato e assim conseguir distrair-me da faculdade sempre que eu precisei. Mas apesar disso vai continuar a perder comigo. `A minha m˜ae por me ter sempre apoiado ao longo destes anos e dado a sua forc¸a. Ao Buddy e ao Rex por terem sido os meus companheiros de estudo durante estes anos. `A minha tia Susana tamb´em por me ter apoiado.
Ao Professor Francisco por ter contruibu´ıdo para a minha aprendizagem ao longo deste ano, pela sua disponibilidade sempre que eu necessitei e pela sua camaradagem. Ele fez-me perceber o que ´e realmente trabalhar num projeto em inform´atica e fez-me crescer como um profissional na ´area de inform´atica. Ao Carlos por me ter ajudado sempre que precisei e ter comparticipado neste meu trabalho.
`
A fam´ılia da parte do meu pai por me terem ajudado e apoiado sempre que eu precisei ao longo destes cinco anos.
Ao F´abio por me ter acompanhado desde o primeiro ano de faculdade. Aprendemos juntos e partilh´amos muito desde o primeiro ano. Que continuemos a trabalhar juntos ao longo de v´arios anos. Aos meus restantes colegas por me terem acompanhado durante os diversos projetos e por terem contibu´ıdo para o meu percurso acad´emico.
Resumo
As redes de sensores s˜ao constitu´ıdas por dispositivos com recursos muito limita-dos e na maior parte limita-dos casos, utilizam pilhas com baixa capacidade como fonte de alimentac¸˜ao. Muitos destes dispositivos disp˜oem de uma pequena quantidade de armaze-namento – apenas 2 KB de mem´oria RAM – o que ilustra bem as suas grandes limitac¸˜oes computacionais. Ainda assim, estes dispositivos s˜ao utilizados em diversas ´areas. A t´ıtulo de exemplo podemos salientar aplicac¸˜ao nas ´areas da medicina, monitorizac¸˜ao de incˆendios, em operac¸˜oes militares e at´e em alarmes de incˆendios dentro dos edif´ıcios.
A programac¸˜ao destes dispositivos est´a relacionado com o seu microcontrolador, sendo assim dependente do fabricante que produz o dispositivo. Tendo em conta que os fa-bricantes constroem dispositivos com diferentes microcontroladores, s˜ao usadas diver-sas linguagens de programac¸˜ao. A linguagem que propomos ´e baseada em eventos, ou seja, reage a est´ımulos. Exemplificando, se tivermos um dispositivo que esteja a fazer monitorizac¸˜ao de incˆendios e que determine que existe um fogo, este dispositivo vai rea-gir a esse est´ımulo, executando a parte do programa correspondente a este evento.
Para a linguagem Macaw, foi desenvolvido um compilador, de forma a receber como inputum programa sint´aticamente v´alido. Este programa vai ser validado pelo sistema de tipos e processado por um conjunto de algoritmos de otimizac¸˜ao. Por fim, vai ser conver-tido para bytecode, de modo a poder ser executado na M´aquina Virtual. Com este compi-lador pretende-se calcular em tempo de compilac¸˜ao o tamanho m´aximo que a aplicac¸˜ao vai ocupar no dispositivo. Assim, permite ao programador saber se o dispositivo tem espac¸o de armazenamento suficiente para armazenar a aplicac¸˜ao, permitindo contornar uma das limitac¸˜oes destes dispositivos.
Com esta linguagem, ´e poss´ıvel resolver alguns dos problemas existentes relativa-mente a outras linguagens de programac¸˜ao. Ao poder ser utilizada em diversos dispositi-vos, permite que n˜ao seja necess´ario ter o conhecimento de todos os microcontroladores dispon´ıveis. Uma outra vantagem importante, consiste em o compilador com o seu sis-tema de tipos identificar diversos erros cometidos pelo programador antes do programa ser executado.
Palavras-chave: Redes Sensores, Macroprogramac¸˜ao, Eventos, Compiladores, Algoritmos de Otimizac¸˜ao
Abstract
Sensor networks consist of devices with limited resources and in most cases use bat-teries with lower capacity for power source. Many of these devices have a small amount of storage - only 2 KB of RAM - which illustrates their large computational limitations. Yet, these devices are used in many areas. For example, we can stress application in medicine, fire monitoring, military operations and even fire alarms within buildings.
The programming of these devices is related to its microcontroller, and thus dependent on the manufacturer that produces the devices. Given that manufacturers build devices with different microcontrollers are used several programming languages. The language we propose is based on events, or responds to stimuli. For example, if we have a device that is to do monitoring of fires and to determine that there is a fire, this device will react to this stimulus, the running of the program corresponding to this event.
For Macaw language, a compiler is designed so as to receive as input syntactically valid program. This program will be validated by the type system and processed by a set of optimization algorithms. Finally, it will be converted to bytecode, so it can be run in Virtual Machine. With this compiler is intended to calculate at compile time the maxi-mum size that the application will occupy on the device. Thus allows the programmer to determine if the device has enough storage to store the application, allowing around one of the limitations of these devices.
With this language, it is possible to solve some of the problems relative to other pro-gramming languages. Power to be used on various devices, lets not necessary to have knowledge of all microcontrollers available. Another important advantage consists of the compiler with your system to identify various types of mistakes made by the programmer before the program run.
Keywords: Sensors Networking, Macroprogramming, Events, Compilers, Optimization Algorithms
Conte ´udo
Lista de Figuras xiv
Lista de Tabelas xv 1 Introduc¸˜ao 1 1.1 Motivac¸˜ao . . . 2 1.2 Objetivos . . . 4 1.3 Calendarizac¸˜ao . . . 5 1.4 Contribuic¸˜oes . . . 5 1.5 Estrutura do documento . . . 6 2 Trabalho relacionado 7 2.1 Tipo de comunicac¸˜ao . . . 7 2.2 Paradigmas de programac¸˜ao . . . 9
2.3 Linguagem de programac¸˜ao Callas . . . 10
2.4 Testes e depurac¸˜ao de aplicac¸˜oes . . . 10
2.4.1 NodeMD . . . 11
2.4.2 Clairvoyant . . . 12
2.4.3 TOSSIM . . . 13
2.5 Aplicac¸˜ao das redes de sensores . . . 14
2.5.1 Classificac¸˜ao da aplicabilidade de redes de sensores . . . 14
2.5.2 Exemplos pr´aticos da aplicabilidade das redes de sensores . . . . 15
2.6 Considerac¸˜oes finais . . . 16
3 Linguagem de programac¸˜ao Macaw 17 3.1 Sintaxe da linguagem . . . 17
3.2 Semˆantica operacional . . . 20
3.3 Sistema de tipos . . . 23
3.4 Sintaxe da linguagem interm´edia . . . 25
3.5 Formato do bytecode gerado . . . 27 ix
4 Implementac¸˜ao compilador Macaw 31 4.1 Xtext . . . 35 4.2 Tabela de s´ımbolos . . . 37 4.3 Sistema de tipos . . . 38 4.4 Linguagem interm´edia . . . 40 4.5 Gerador de c´odigo . . . 41
4.5.1 Construc¸˜ao AST interm´edia . . . 41
4.5.2 Gerador bytecode . . . 42
4.6 Algoritmo de gerac¸˜ao do grafo de estados . . . 43
4.7 C´alculo do tamanho do mapa de eventos . . . 45
4.8 C´alculo do tamanho da pilha de chamada e operandos . . . 45
4.9 Plataforma UI . . . 46 4.9.1 Outline . . . 46 4.9.2 Quick fixes . . . 48 4.9.3 Content assist . . . 50 4.9.4 Formatac¸˜ao . . . 51 5 Algoritmos de otimizac¸˜ao 53 5.1 Processo de construc¸˜ao . . . 53
5.1.1 Grafo fluxo de controlo . . . 54
5.1.2 Arvore dominadores . . . .´ 56
5.1.3 Fronteira dominadores . . . 57
5.1.4 Static Single-Assignment Form . . . 58
5.2 Copy propagation . . . 61
5.3 Constant folding. . . 61
5.4 Conditional constant propagation . . . 62
5.5 Dead code elimination . . . 64
5.6 Outros algoritmos de otimizac¸˜ao . . . 65
6 Testes 67 6.1 Testes realizados . . . 68 6.2 Erros encontrados . . . 69 7 Exemplos pr´aticos 71 7.1 Exemplo blink . . . 71 7.2 Exemplo blink-button-pressed . . . 72 8 Conclus˜ao 75 8.1 Trabalho futuro . . . 76
8.2 Exemplo sistema de rega inteligente . . . 77 x
A Sintaxe da linguagem Macaw 79
B Semˆantica operacional 81
C Regras do sistema de tipos 85
D Sintaxe da linguagem interm´edia 89
E Formato bytecode 91
F Func¸˜oes de traduc¸˜ao para bytecode 93
G Programas exemplo 105
H Nova sintaxe da linguagem Macaw 117
Bibliografia 121
Lista de Figuras
2.1 Grupos Multi-Hop . . . 8
3.1 Transformac¸˜ao para bytecode . . . 27
4.1 Fluxo de informac¸˜ao do compilador Macaw - Parte I . . . 32
4.2 Fluxo de informac¸˜ao do compilador Macaw - Parte II . . . 33
4.3 Hierarquia de tipos da linguagem Macaw . . . 34
4.4 Fluxo de informac¸˜ao Xtext . . . 37
4.5 Grafo de estados do programa blink-button-pressed . . . 44
4.6 Outlineexemplo de um ficheiro .macaw . . . 47
4.7 Outlineexemplo de um ficheiro .macawh . . . 48
4.8 Quick Fixapresentada para solucionar erro de parˆametros “handler” main 49 4.9 Exemplo do Content Assist da linguagem Macaw . . . 51
5.1 Grafo de fluxo de controlo exemplo main blink . . . 55
5.2 Arvore de dominadores do exemplo main blink . . . .´ 56
5.3 Grafo SSA do exemplo main blink . . . 60
5.4 Reticulado do algoritmo Conditional Constant Propagation . . . 62
5.5 Regra para o operadoru . . . 63
5.6 Regra para express˜oes . . . 63
A.1 Sintaxe da linguagem Macaw – Parte I . . . 79
A.2 Sintaxe da linguagem Macaw – Parte II . . . 80
B.1 Sintaxe de ambiente de execuc¸˜ao Macaw . . . 81
B.2 Estado de boot de um programa Macaw . . . 81
B.3 Semˆantica de reduc¸˜ao de programas Macaw - part I . . . 82
B.4 Semˆantica de reduc¸˜ao de programas Macaw - part II . . . 83
C.1 Sistema de tipos para um programa Macaw – Parte I . . . 85
C.2 Sistema de tipos para um programa Macaw – Parte II . . . 86
C.3 Sistema de tipos para um programa Macaw – Parte III . . . 86
C.4 Sistema de tipos para vari´aveis globais . . . 87
C.5 Sistema de tipos para membros e c´odigo local – Parte I . . . 87 xiii
C.6 Sistema de tipos para membros e c´odigo local – Parte II . . . 88
D.1 Sintaxe da linguagem interm´edia Macaw . . . 89
E.1 Formato do bytecode . . . 92
F.1 Func¸˜oes de traduc¸˜ao para bytecode I . . . 94
F.2 Func¸˜oes de traduc¸˜ao para bytecode II . . . 95
F.3 Func¸˜oes de traduc¸˜ao para bytecode III . . . 96
F.4 Func¸˜oes de traduc¸˜ao para bytecode IV . . . 97
F.5 Func¸˜oes de traduc¸˜ao para bytecode V . . . 98
F.6 Func¸˜oes de traduc¸˜ao para bytecode VI . . . 99
F.7 Func¸˜oes de traduc¸˜ao para bytecode VII . . . 100
F.8 Func¸˜oes de traduc¸˜ao para bytecode VIII . . . 101
F.9 Func¸˜oes de traduc¸˜ao para bytecode IX . . . 102
F.10 Func¸˜oes de traduc¸˜ao para bytecode X . . . 103
G.1 Programa exemplo blink.macawh . . . 105
G.2 Programa exemplo blink.macaw . . . 106
G.3 Excerto de bytecode gerado para o exemplo blink.macaw . . . 107
G.4 Programa exemplo blink-button-pressed.macawh . . . 108
G.5 Programa exemplo blink-button-pressed.macaw . . . 109
G.6 Programa exemplo rega.macawh – Parte I . . . 110
G.7 Programa exemplo rega.macawh – Parte II . . . 111
G.8 Programa exemplo rega.macawh – Parte III . . . 112
G.9 Programa exemplo rega.macawh – Parte IV . . . 113
G.10 Programa exemplo rega.macaw – Parte I . . . 114
G.11 Programa exemplo rega.macaw – Parte II . . . 115
G.12 Programa exemplo rega.macaw – Parte III . . . 116
H.1 Proposta de nova sintaxe da linguagem Macaw – Parte I . . . 117
H.2 Proposta de nova sintaxe da linguagem Macaw – Parte II . . . 118
Lista de Tabelas
3.1 Diferenc¸a de valores de inteiros . . . 20
3.2 Instruc¸˜oes bytecode sem parˆametros . . . 29
3.3 Instruc¸˜oes bytecode com parˆametros . . . 30
4.1 Valores por definic¸˜ao . . . 33
5.1 Fronteira dominadores exemplo main blink . . . 57
Cap´ıtulo 1
Introduc¸˜ao
As redes de sensores s˜ao compostas por um conjunto de dispositivos capazes de me-dir vari´aveis do ambiente e tomar algumas ac¸˜oes relativamente a essas medic¸˜oes. S˜ao tamb´em capazes de transmitir dados entre dispositivos presentes na mesma rede. Estes dispositivos tˆem muitas limitac¸˜oes de processamento, de mem´oria e de bateria. A possibi-lidade de algumas redes de sensores serem colocadas em zonas com pouca acessibipossibi-lidade exp˜oe ainda mais as dificuldades destes dispositivos e a resoluc¸˜ao de poss´ıveis problemas que possam existir. Se uma rede de sensores, ´e colocada num local em que a acessi-bilidade ´e escassa e o programa a ser executado tem uma falha, o acesso f´ısico a esses sensores para a resoluc¸˜ao desse problema pode apresentar custos muito elevados.
Atualmente existem muitas linguagens de programac¸˜ao para redes de sensores. Desde linguagens de alto n´ıvel que abstraem a informac¸˜ao de hardware dos programadores, a linguagens de baixo n´ıvel em que o programador necessita de definir o comportamento do hardware na rede. Outra caracter´ıstica das linguagens de programac¸˜ao, consiste em estas permitirem definir o comportamento geral da rede ou o comportamento de cada dispositivo individualmente. A maior dificuldade no uso destas linguagem consiste em garantir o bom funcionamento destas nas redes. Isto deve-se ao facto dos mecanismos de depurac¸˜ao ainda n˜ao estarem muito desenvolvidos.
Esta dissertac¸˜ao pretende desenvolver uma linguagem de programac¸˜ao de alto n´ıvel baseada em eventos que verifique estaticamente, em tempo de compilac¸˜ao, erros que pos-sam dar origem a problemas de execuc¸˜ao do programa. Este tipo de linguagem permite di-minuir significativamente o tempo de desenvolvimento das aplicac¸˜oes, a sua manutenc¸˜ao e assim diminuir a possibilidade dos erros que possam acontecer durante a execuc¸˜ao do programa. Para facilitar a depurac¸˜ao das aplicac¸˜oes desenvolvidas pela linguagem, ´e gerado em tempo de compilac¸˜ao um grafo que apresenta os v´arios estados em que o pro-grama pode estar durante a sua execuc¸˜ao.
Este trabalho foi realizado no ˆambito do Projeto em Engenharia Inform´atica do Mes-trado em Engenharia Inform´atica e tamb´em no ˆambito do projeto MACAW do Departa-mento de Inform´atica da Faculdade de Ciˆencias da Universidade de Lisboa. Este projeto
Cap´ıtulo 1. Introduc¸˜ao 2
´e financiado pela Fundac¸˜ao para a Ciˆencia e Tecnologia (PTDC/EIA-EIA/115730/2009). Al´em do desenvolvimento do compilador para a linguagem Macaw, o projeto tamb´em tem como objetivo desenvolver a m´aquina virtual para a execuc¸˜ao da linguagem.
1.1
Motivac¸˜ao
As redes de sensores tˆem cada vez mais utilizac¸˜ao, tanto pelo seu potencial, como pela facilidade de aplicac¸˜ao em diversos ambientes, sendo que muitos destes ambientes s˜ao cr´ıticos. Estas redes s˜ao utilizadas muitas vezes para controlar condic¸˜oes ambientais. As primeiras aplicac¸˜oes para redes de sensores comec¸aram por ser aplicadas no ambiente mi-litar, mas hoje em dia a sua utilizac¸˜ao em diversos ambientes est´a a aumentar [20]. O uso destas redes num futuro pr´oximo vai-se tornar cada vez mais importante, pois muitos dos processos que atualmente necessitam de ser controlados por um humano podem tornar-se autom´aticos devido `a monitorizac¸˜ao destes dispositivos.
Outra grande vantagem que estas redes de sensores tˆem ´e a facilidade com que se pode construir uma rede. Muitos dos dispositivos s˜ao modulares, ou seja, depois de se obter o corpo principal pode-se adicionar m´odulos a este corpo. Estes m´odulos podem ser desde receptores wi-fi para a comunicac¸˜ao com outros sensores, ou m´odulos com uma porta HDMI para a visualizac¸˜ao dos dados no dispositivo. Um exemplo de um dispositivo com estas caracter´ısticas ´e o Raspberry Pi [16].
Um grande conjunto das linguagens de programac¸˜ao para sensores s˜ao de baixo n´ıvel, muito pr´oximas do hardware, o que dificulta a programac¸˜ao, pois ´e necess´ario ter em conta detalhes de baixo n´ıvel dos dispositivos que se est´a a programar. Outro problema que estas linguagens de programac¸˜ao apresentam ´e o facto de serem desenvolvidas para um hardware espec´ıfico, tornando a sua aplicabilidade confinada aos dispositivos em quest˜ao. O leque de linguagens de programac¸˜ao para redes de sensores ´e muito grande.
A capacidade de processamento destes dispositivos ´e outro problema, pois possuem recursos escassos. ´E nossa convicc¸˜ao que num futuro pr´oximo, quando estas limitac¸˜oes forem ultrapassadas, a utilizac¸˜ao destes dispositivos vai aumentar exponencialmente. Es-tes podem vir a ser utilizados em ambienEs-tes adversos, onde os humanos n˜ao tˆem qualquer acesso e obter informac¸˜oes sobre esses locais. Com o aumento da aplicabilidade destes dispositivos, torna-se cada vez mais importante que o seu comportamento seja o esperado, trazendo assim uma maior confianc¸a na sua utilizac¸˜ao. N˜ao se quer que um equipamento que esteja a fazer monitorizac¸˜ao de uma situac¸˜ao cr´ıtica pare a meio porque a bateria sua terminou ou porque se esgotou o espac¸o na mem´oria para armazenar os dados que est´a a controlar.
Por isso, ´e cada vez mais importante ter linguagens de programac¸˜ao que acompanhem a evoluc¸˜ao das redes de sensores e que fornec¸am as abstrac¸˜oes adequadas a este modelo de programac¸˜ao. Assim, ´e relevante ter linguagens f´aceis de entender e que permitam um
Cap´ıtulo 1. Introduc¸˜ao 3
desenvolvimento r´apido de aplicac¸˜oes, mas que tamb´em facilitem a fase de teste e que sejam conscientes das limitac¸˜oes f´ısicas destes dispositivos. Isto contribui para a garantia de qualidade das aplicac¸˜oes.
Como foi referido anteriormente esta proposta pretende, desenvolver uma linguagem de programac¸˜ao que seja de alto n´ıvel, ou seja, possa abstrair o hardware e facilitar o trabalho de programac¸˜ao, tentando diminuir o n´umero de erros que a aplicac¸˜ao possa ter. Tamb´em pretende aumentar a qualidade das aplicac¸˜oes desenvolvidas para estes dispositi-vos, facilitando a sua depurac¸˜ao. Devido aos dispositivos pertencentes na rede de sensores serem reativos a linguagem desenvolvida ´e baseada em eventos. Estes dispositivos s˜ao re-ativos pois reagem a est´ımulos externos. Pode ser desde a recec¸˜ao de uma mensagem de outro dispositivo na rede, a um fator ambiental que este dispositivo esteja a monitorizar.
Esta linguagem vai utilizar a noc¸˜ao de macroprogramac¸˜ao para abstrair o programa-dor do hardware e os detalhes de rede. Outra verificac¸˜ao que vai fazer em tempo de compilac¸˜ao ´e o espac¸o total que a aplicac¸˜ao vai ocupar no dispositivo. Isto vai servir para que o compilador, quando for executado possa avisar o programador que o dispositivo n˜ao tem mem´oria suficiente para essa aplicac¸˜ao. Devido a este problema de mem´oria que os dispositivos tˆem, foram desenvolvidos algoritmos de optimizac¸˜ao de forma a di-minuir o tamanho do bytecode gerado pelo compilador. Aumentando assim, o leque de poss´ıveis programas que podem ser definidos com a linguagem. Alguns dos algoritmos de optimizac¸˜ao utilizados foram: Conditional Constant Propagation, Constant Folding, Constant Propagation, etc.
Uma vantagem desta linguagem ´e o facto de se poder fazer chamadas a func¸˜oes de hardware definidas na M´aquina Virtual. Para que esta funcionalidade seja poss´ıvel, basta que a M´aquina Virtual e o compilador contenham os mesmos dados relativamente `a configurac¸˜ao do hardware. Esta caracter´ıstica facilita que a linguagem possa ser apli-cada sobre v´arios tipos de hardware. Sempre que for necess´ario aplicar a linguagem a um novo hardware, basta apenas ser definido um novo ficheiro contendo as configurac¸˜oes de hardware que se vai utilizar. O facto da linguagem poder ser aplicada a v´arios tipos de hardware´e uma das suas grandes vantagens.
1.2
Objetivos
O objetivo desta dissertac¸˜ao consiste em desenvolver uma linguagem de programac¸˜ao ba-seada em eventos que resolva alguns dos problemas identificados na secc¸˜ao anterior. Um dos objetivos espec´ıficos consiste em desenhar a linguagem e a sua semˆantica operacional. Para o desenho da linguagem, teve-se em conta que os dispositivos onde esta linguagem vai ser executada tˆem muitas limitac¸˜oes.
O desenho e a implementac¸˜ao de um sistema de tipos ´e outro objetivo espec´ıfico. Esta caracter´ıstica da linguagem permite diminuir o n´umero de erros que possam acontecer em tempo de execuc¸˜ao. Este aspeto traz uma maior confianc¸a na utilizac¸˜ao da linguagem desenvolvida.
O terceiro objetivo consiste em determinar em tempo de compilac¸˜ao o tamanho m´axi-mo que a pilha de operandos vai ter durante a execuc¸˜ao do programa. Por isso, desenvol-vemos um analisador sint´atico para c´alcular o tamanho m´aximo da pilha. Este analisador sint´atico ´e desenvolvido a partir da AST (Abstract Syntax Tree) gerada inicialmente pelo pluginutilizado nesta dissertac¸˜ao.
O desenho do bytecode teve de se analisar quais os tipos de instruc¸˜oes necess´arias para a execuc¸˜ao da linguagem no compilador, inclusive o formato do bytecode, que al´em das instruc¸˜oes do bytecode, tem de ter outras informac¸˜oes necess´arias para o funcionamento da m´aquina virtual, sendo este o quarto objetivo.
O quinto objetivo consiste em executar o c´odigo gerado em diversos tipos de dispo-sitivos, onde cada um deles tem caracter´ısticas espec´ıficas. Assim, ´e necess´ario que o bytecodegerado seja o menor poss´ıvel, aumentando assim a possibilidade de a linguagem poder ser executado em diversos dispositivos mesmo naqueles que tˆem menor capacidade. Teve de se ter em conta que algumas optimizac¸˜oes diminuem o c´odigo gerado mas outras aumentam o c´odigo gerado s´o para facilitar o trabalho da M´aquina Virtual.
O sexto objetivo consise em desenvolver um grafo de estados do hardware, utilizando a especificac¸˜ao de hardware desenvolvida, de modo a que os programadores consigam analisar o comportamento do hardware. Este grafo permite identificar comportamentos errados por parte do hardware e assim ajudar na depurac¸˜ao das aplicac¸˜oes.
O ´ultimo objetivo deste trabalho passa por desenvolver testes unit´arios para garantir o bom funcionamento do compilador. Os testes desenvolvidos utilizaram cobertura por grafos. Em m´etodos sem ciclos foi feita a cobertura de todos os caminhos do grafo, caso contrario foi feita cobertura dos caminhos primos. Estes testes foram feitos ao sistema de tipos da linguagem, aos algoritmos de optimizac¸˜ao e a gerac¸˜ao de c´odigo. Um outro objetivo ´e o de averiguar a expressividade da linguagem utilizando casos de uso com dimens˜ao apreci´avel.
Cap´ıtulo 1. Introduc¸˜ao 5
1.3
Calendarizac¸˜ao
Esta dissertac¸˜ao teve a seguinte calendarizac¸˜ao:
• At´e fim de Outubro elaborar um estudo do estado da arte em programac¸˜ao de sen-sores e linguagem de programac¸˜ao baseada em eventos;
• At´e fim de Janeiro elaborar o desenho da linguagem e implementac¸˜ao do analisador sint´atico;
• At´e fim de Fevereiro elaborar o desenho do bytecode;
• At´e fim de Marc¸o desenvolvimento de algoritmos de optimizac¸˜ao no compilador; • At´e fim de Abril gerac¸˜ao de c´odigo e desenvolvimento de testes unit´arios;
• At´e fim de Maio implementac¸˜ao de um caso de uso para validac¸˜ao da soluc¸˜ao de-senvolvida;
• At´e fim de Junho escrita da tese.
1.4
Contribuic¸˜oes
Foi desenvolvido um compilador para a linguagem Macaw que tem como objetivo dimi-nuir o n´umero de erros que possam acontecer em tempo de execuc¸˜ao, dimidimi-nuir ao m´aximo o tamanho do bytecode de modo a aumentar o leque de programas v´alidos para a lingua-gem, entre outros. Outra vantagem que o compilador apresenta, ´e o facto de calcular em tempo de compilac¸˜ao o tamanho de utilizac¸˜ao de mem´oria dos programas. O compilador e a M´aquina Virtual da linguagem permitem que a linguagem possa ser executada em di-versos tipos de hardware, o que ´e uma vantagem comparativamente `as outras linguagens j´a existentes.
As contribuic¸˜oes deste trabalho s˜ao:
• Desenvolvimento de uma linguagem de programac¸˜ao baseada em eventos para sen-sores;
• Compilador utiliza algoritmos de optimizac¸˜ao para diminuic¸˜ao do c´odigo gerado; • Possibilidade de chamada de func¸˜oes nativas do hardware na linguagem, o que
permite aumentar a aplicabilidade da linguagem;
• Criar um compilador que permita, em tempo de compilac¸˜ao, determinar se o sensor tem espac¸o de mem´oria suficiente para armazenar o programa ou se tem bateria suficiente para executar o mesmo;
Cap´ıtulo 1. Introduc¸˜ao 6
• Desenvolvimento de um grafo de estados onde ´e poss´ıvel identificar os diversos estados em que o hardware pode estar;
• Utilizando o resultado final dos algoritmos de otimizac¸˜ao, ´e demonstrado no Eclipse IDE quais as mudanc¸as poss´ıveis no c´odigo fonte de modo a apr´oximar o c´odigo fonte do bytecode gerado pelo compilador.
1.5
Estrutura do documento
O documento est´a organizado em cinco cap´ıtulos para al´em desta introduc¸˜ao. O Cap´ıtulo 2 – Trabalho Relacionado – que descreve as linguagens de programac¸˜ao com intuitos se-melhantes a esta proposta e faz um resumo de dois casos pr´aticos onde as redes de sen-sores foram aplicadas. O Cap´ıtulo 3 – Linguagem de programac¸˜ao Macaw – apresenta uma descric¸˜ao dos componentes principais da linguagem. O Cap´ıtulo 4 – Implementac¸˜ao Compilador Macaw – descreve os detalhes de implementac¸˜ao do compilador. O Cap´ıtulo 5 – Algoritmos de Optimizac¸˜ao – descreve os algoritmos de otimizac¸˜ao e a sua aplicac¸˜ao. O Cap´ıtulo 6 – Testes – descreve os testes desenvolvidos no compilador, os seus resulta-dos e os erros encontraresulta-dos. O Cap´ıtulo 7 – Exemplos Pr´aticos – explica alguns exemplos pr´aticos da linguagem Macaw e o Cap´ıtulo 8 – Conclus˜ao – faz uma an´alise do trabalho desenvolvimento e s˜ao descritas as conclus˜oes finais do projeto.
Cap´ıtulo 2
Trabalho relacionado
Neste capitulo faz-se uma an´alise das linguagens de programac¸˜ao para redes de senso-res existentes tendo em conta o tipo de comunicac¸˜ao e o paradigma de programac¸˜ao das mesmas. Vai ser apresentada uma descric¸˜ao pr´evia da linguagem de programac¸˜ao Cal-las, devido aos princ´ıpios desta linguagem serem semelhantes `a linguagem desenvolvida nesta dissertac¸˜ao. Tamb´em v˜ao ser apresentadas algumas plataformas que permitem a depurac¸˜ao e simulac¸˜ao de aplicac¸˜oes para redes de sensores. Para finalizar, vai ser feita uma an´alise das aplicabilidade das redes de sensores onde s˜ao apresentados casos de uso.
2.1
Tipo de comunicac¸˜ao
A comunicac¸˜ao entre sensores pode ser definida como um conjunto de n´os da rede de sen-sores que trocam informac¸˜ao entre si para concretizar uma determinada aplicac¸˜ao. H´a trˆes abordagens principais: “comunicac¸˜ao entre vizinhos”, “grupos multi-hop” e “comunicac¸˜ao entre todo o sistema” [28].
As linguagens de programac¸˜ao para a abordagem “comunicac¸˜ao entre vizinhos” per-mitem que os dados possam ser trocados apenas por sensores que estejam em contato direto entre si (utilizando por exemplo o sistema de r´adio dos sensores).
A linguagem nesC e ActiveMessages s˜ao exemplos deste tipo de abordagem. As aplicac¸˜oes desenvolvidas com o nesC [18] s˜ao constru´ıdas interligando os sensores da rede atrav´es de interfaces. Nestas interfaces podem-se definir comandos ou eventos, onde os comandos s˜ao utilizados para comec¸ar operac¸˜oes e os eventos s˜ao utilizados para obter os resultados de forma ass´ıncrona. O comportamento da linguagem ActiveMessages ´e um pouco diferente do nesC, pois esta linguagem utiliza mensagens com um identificador que especifica qual o sensor que deve receber a mensagem, tendo assim um comportamento semelhante aos sockets [28].
Os “grupos multi-hop” s˜ao conjuntos de sensores dentro de uma rede e podem ser divididos em dois grupos: “grupos multi-hop” ligados e n˜ao ligados. A diferenc¸a entre ambos est´a rebresentado na Figura 2.1 [28]. Os “grupos multi-hop” ligados permitem
Cap´ıtulo 2. Trabalho relacionado 8
a troca de mensagens entre sensores que n˜ao estejam ligados entre si desde que este-jam dentro do mesmo hop. De realc¸ar, que quaisquer dois n´os que esteeste-jam neste grupo est˜ao ligados, utilizando outros n´os que pertenc¸am ao mesmo grupo. Uma linguagem de programac¸˜ao utilizada para este caso ´e o EnviroSuite, ´e uma plataforma orientada a obje-tos, direcionada para fazer monitorizac¸˜ao e aplicac¸˜oes para rastrear eventos. Os objetos nesta linguagem representam as entidades f´ısicas (sensores) na rede. Estes objetos s˜ao criados dinamicamente quando as entidades s˜ao detetadas na rede [28].
Os sensores pertencentes aos “grupos multi-hop” n˜ao ligados entre si n˜ao tˆem qualquer assunc¸˜ao sobre o local dos n´os que pertencem ao grupo. Uma linguagem utilizada neste caso ´e o Logical Neighborhoods. Esta permite aos programadores redefinir os vizinhos baseando-se nas propriedades l´ogicas dos sensores na rede [28].
Na “comunicac¸˜ao entre todo o sistema” todos os sensores na rede podem estar en-volvidos na troca de dados (tamb´em pode ser definido como macroprogramac¸˜ao). Uma linguagem utilizada para este caso ´e o TinyDB [25]. O utilizador introduz express˜oes SQLna estac¸˜ao base da rede e esta envia para todos os sensores essas consultas. Quando um sensor recebe a consulta, este processa-a fazendo algumas leituras do ambiente, e se for necess´ario encapsula os dados enviando-os de novo para a estac¸˜ao base. A estac¸˜ao base depois de receber os dados de todos os sensores faz o tratamento destes e devolve o resultado ao utilizador que inseriu as consultas.
Todos estes tipos de comunicac¸˜ao tˆem as suas vantagens e desvantagens. Quando se quer desenvolver alguma aplicac¸˜ao para redes de sensores deve-se escolher o mais indicado para a aplicac¸˜ao pretendida. Algumas das linguagens definidas anteriormente s˜ao de baixo n´ıvel (como por exemplo o nesC), enquanto outras s˜ao de alto n´ıvel (como por exemplo o EnviroSuite).
(a) Multi-Hop ligados (b) Multi-Hop n˜ao ligados entre si
Figura 2.1: Grupos Multi-Hop
A linguagem que vai ser desenvolvida incorporar-se neste ´ultimo grupo “comunicac¸˜ao entre todo o sistema”, pois vai ser poss´ıvel definir o comportamento de toda a rede de sensores e n˜ao individualmente. Uma das grandes vantagens deste tipo de comunicac¸˜ao consiste no programador n˜ao ter de se preocupar em programar cada um dos n´os da rede (se for uma rede muito grande ter de programar cada um dos n´os pode ser complicado) e
Cap´ıtulo 2. Trabalho relacionado 9
assim trazer alguma abstrac¸˜ao no programa.
2.2
Paradigmas de programac¸˜ao
As linguagens de programac¸˜ao utilizadas nas redes de sensores podem-se dividir em trˆes paradigmas diferentes: imperativo, declarativo e h´ıbrido.
Em relac¸˜ao ao paradigma de programac¸˜ao imperativo o processamento da aplicac¸˜ao ´e expresso atrav´es de instruc¸˜oes que indicam claramente como mudar o estado do sistema. Este paradigma pode ser dividido em duas categorias: sequencial e baseado em eventos. Como vimos anteriormente o nesC ´e baseado em eventos e um exemplo de linguagem sequencial ´e Pleiades. Esta linguagem ´e uma extens˜ao ao C em que ´e poss´ıvel indicar quais s˜ao os n´os na rede e aceder ao seu estado local [28]. As linguagens de programac¸˜ao neste paradigma tˆem a vantagem de que o programador consegue controlar facilmente o comportamento do sistema.
No paradigma de programac¸˜ao declarativo o objetivo da aplicac¸˜ao ´e descrito sem in-dicar como ´e que ´e cumprido. Este paradigma pode ser dividido em trˆes categorias: fun-cional, baseado em regras e utilizando consultas SQL. Como j´a vimos anteriormente o TinyDB ´e um exemplo de uma linguagem que utiliza consultas SQL no seu funciona-mento. Uma linguagem que ´e do tipo funcional ´e o Regiment [29]. Nesta linguagem os programadores manipulam conjuntos de dados chamados sinais. Esta linguagem tamb´em tem conhecimento sobre regi˜oes e aplica as func¸˜oes programadas aos sinais em certas regi˜oes da rede. Um exemplo de uma linguagem utilizada baseada em regras ´e o Snlog [6]. Esta utiliza predicados, tuplos, factos e regras. Os predicados correspondem a es-quemas para representar os dados, os tuplos s˜ao utilizados para a transmiss˜ao de dados entre os sensores, os factos s˜ao tuplos particulares que s˜ao instanciados durante o in´ıcio do sistema e as regras consistem em ativar os factos da linguagem [28]. As linguagens de programac¸˜ao indicadas anteriormente tˆem uma desvantagem relativamente `as linguagens do paradigma imperativo. Esta desvantagem deve-se ao facto de no paradigma declarativo n˜ao se conseguir controlar o comportamento do sistema, dificultando assim o processo de depurac¸˜ao das aplicac¸˜oes definidas neste paradigma.
O paradigma h´ıbrido pode combinar diversos tipos de paradigmas de programac¸˜ao. Temos como exemplo a linguagem Abstract Task Graph [4] que utiliza o paradigma de-clarativo e imperativo.
A linguagem que vai ser desenvolvida ´e do tipo imperativo baseada em eventos como j´a foi referido. Basear-se-´a em eventos para tomar ac¸˜oes. Em termos de compreens˜ao do programa e do seu controlo de fluxo a programac¸˜ao baseada em eventos ´e um paradigma f´acil de entender, em comparac¸˜ao com o paradigma orientado a regras, que torna compli-cado especificar as regras da rede e entender o controlo de fluxo dos programas definidos com esta linguagem.
Cap´ıtulo 2. Trabalho relacionado 10
2.3
Linguagem de programac¸˜ao Callas
A linguagem de programac¸˜ao Callas tem um objetivo semelhante ao objetivo da lingua-gem Macaw desenvolvida nesta dissertac¸˜ao. Esta lingualingua-gem foi desenvolvida com o in-tuito de facilitar o desenvolvimento de aplicac¸˜oes para redes de sensores.
A linguagem Callas ´e baseada em eventos e ´e compilada por um compilador “type-safe” e “subject reduction”, permitindo assim diminuir o n´umero de erros que possam existir durante a execuc¸˜ao da linguagem [26]. A grande diferenc¸a que esta linguagem tem em comparac¸˜ao com a desenvolvida nesta dissertac¸˜ao, ´e relativo ao tipo de comunicac¸˜ao que ´e permitida pela linguagem. A linguagem Callas n˜ao utiliza o conceito de macropro-gramac¸˜ao, permitindo ao programador n˜ao s´o definir o comportamento de cada sensor na rede, mas tamb´em o protocolo de rede que vai ser utilizado. Uma outra diferenc¸a que esta linguagem tem relativamente `a linguagem Macaw ´e que permite programac¸˜ao recursiva.
A linguagem Callas consegue determinar em tempo de compilac¸˜ao se existe algum problema no protocolo utilizado na comunicac¸˜ao entre os sensores, permitindo assim di-minuir alguns erros que possam existir. Um sensor de rede nesta linguagem ´e representado por um processo que est´a a correr no sensor, uma fila que cont´em os eventos que v˜ao ser executados no sensor, o programa que vai ser executado no sensor (sendo este guardado em mem´oria) e por fim, uma tabela com temporizadores para as chamadas de func¸˜oes. Devido ao tipo de comunicac¸˜ao desta linguagem, estes dados tˆem de ser definidos para todos os sensores da rede [26].
O compilador desta linguagem gera dois tipos de bytecode. Um tipo para os senso-res “sink” – estes sensosenso-res s˜ao ligados por exemplo a um computador permitindo obter e manipular dados do ambiente. O outro bytecode ´e criado para dispositivos do tipo “sam-plers”. Depois de este bytecode ser gerado, ´e transformado num ficheiro .jar ou .suite que pode ser executado nos sensores da rede. Este bytecode vai ser executado no sensor alvo utilizando o SunSpot. Assim que o SunSpot comec¸ar a sua execuc¸˜ao, a m´aquina virtual da linguagem Callas comec¸a a executar o bytecode gerado por parte do compilador [27].
2.4
Testes e depurac¸˜ao de aplicac¸˜oes
Os testes e a depurac¸˜ao de aplicac¸˜oes ´e uma ´area ainda muito pouco explorada na progra-mac¸˜ao em sensores. Algumas das soluc¸˜oes apresentadas no estado de arte das redes de sensores oferecem algumas ideias para testar aplicac¸˜oes de redes de sensores, mas estas s˜ao dependentes de uma arquitetura de sensores, o que limita bastante a utilizac¸˜ao destas soluc¸˜oes. Mesmo assim, nestes exemplos apresentados ´e mostrado ao programador um erro, mas n˜ao d˜ao nenhuma pista sobre a raz˜ao de o programa ter parado a sua execuc¸˜ao [28]. Atualmente o modo mais utilizado para testar o comportamento das aplicac¸˜oes numa rede de sensor ´e simular o comportamento da rede. Mas esta aproximac¸˜ao n˜ao ´e suficiente, pois alguns erros s´o s˜ao encontrados em casos espec´ıficos de utilizac¸˜ao. De resto, como
Cap´ıtulo 2. Trabalho relacionado 11
se constatou nos cap´ıtulos anteriores, as linguagens apresentadas est˜ao mais preocupadas na gest˜ao da rede e nos algoritmos a utilizar (por exemplo, difus˜ao de mensagens) do que nestes pormenores de garantia de qualidade.
Isto dificulta o trabalho dos programadores pois estes tˆem dificuldades em garantir que as aplicac¸˜oes que est˜ao a desenvolver tˆem o comportamento desejado, o que traz diversos problemas. Se o problema for identificado s´o quando a rede de sensores tiver sido constru´ıda, num local com pouco acesso, o deslocamento at´e ao local para a resoluc¸˜ao do problema pode apresentar custos muito elevados.
A linguagem que vai ser desenvolvida de modo a facilitar a depurac¸˜ao das aplicac¸˜oes apresenta um grafo, onde indica como o estado do hardware dos seus componentes se vai comportar ao longo da execuc¸˜ao do programa. Por exemplo, quando um evento ´e execu-tado num certo esexecu-tado, este grafo demonstra o que vai acontecer aos m´odulos de hardware a seguir ao evento ser executado. Isto facilita a identificac¸˜ao de qualquer problema que a aplicac¸˜ao possa ter em tempo de execuc¸˜ao. De seguida v˜ao ser apresentados alguns exemplos de linguagens e aplicac¸˜oes que pretendem facilitar o trabalho de depurac¸˜ao das aplicac¸˜oes.
2.4.1
NodeMD
NodeMD[21] ´e uma aplicac¸˜ao de deployment que permite analisar alguns problemas que podem acontecer durante a execuc¸˜ao de programas num sensor da rede. O objetivo desta aplicac¸˜ao ´e identificar o erro antes que este incapacite totalmente o sensor. Depois de os problemas serem identificados, esta aplicac¸˜ao elabora um diagn´ostico que permite aos programadores resolverem o problema encontrado, permitindo assim diminuir os custos relativos `a necessidade de ir ao local onde o sensor est´a colocado, para este ser subs-titu´ıdo. Os autores desta aplicac¸˜ao pretendem que esta analise e diagnostico afete o menos poss´ıvel o comportamento da rede de sensores.
Esta aplicac¸˜ao tem trˆes subsistemas diferentes [21]. O primeiro ´e relativo `a detecc¸˜ao de erros na execuc¸˜ao de um determinado sensor. Os erros identificados s˜ao: Stack Over-flow, DeadLock e LiveLock [21]. O algoritmo para verificar Stack Overflow consiste em comparar a pilha da Thread que est´a a ser executada atualmente com o Stack Pointer de-pois de um procedimento ser chamado [21]. Se o Stack Pointer exceder o tamanho de pilha atual isso vai causar Stack Overflow. DeadLock consiste em dois ou mais proces-sos que est˜ao `a espera um do outro para poder continuar a sua execuc¸˜ao, mas nenhum deles termina. Esta condic¸˜ao de DeadLock ´e muito semelhante ao LiveLock, s´o que no caso do ´ultimo os processos n˜ao est˜ao bloqueados. Cada um dos processos est´a a mudar de estado para deixar o outro que est´a `a espera avanc¸ar, mas ambos mudam ao mesmo tempo. Para determinar casos de DeadLock e LiveLock, foi desenvolvido um algoritmo que introduz checkpoints no c´odigo para determinar se as Threads do sistema est´a a ter o comportamento desejado [21].
Cap´ıtulo 2. Trabalho relacionado 12
O segundo subsistema, consiste em notificar ao programador qual a falta que acon-teceu durante a execuc¸˜ao do programa num determinado sensor da rede. O sum´ario que ´e desenvolvido e posteriormente enviado para o programador consiste num hist´orico de execuc¸˜ao dos eventos no sistema [21].
O terceiro subsistema, permite que os programadores consigam interagir diretamente com o n´o que teve a falta, permitindo assim que o programador consiga resolver o pro-blema. Os autores desta aplicac¸˜ao pretendem que quando exista uma falta no c´odigo poder atualizar o c´odigo do sensor que cont´em a falta [21].
2.4.2
Clairvoyant
Clairvoyant[32] ´e uma aplicac¸˜ao de depurac¸˜ao para redes de sensores. Este liga-se a um sensor da rede usando a conex˜ao wireless do dispositivo, e permite executar comandos de depurac¸˜ao standard. Al´em destes comandos standard tamb´em existem comandos que permitem n˜ao s´o testar o hardware do dispositivo, como por exemplo, o acesso ao LED do dispositivo. Podem tamb´em permitir, aceder ao comportamento total da rede de sensores. Esta aplicac¸˜ao pretende que a sua execuc¸˜ao n˜ao traga qualquer problema nem distorc¸˜ao do comportamento do sensor que vai ser testado [32]. Esta t´ecnica utilizada por o Clair-voyantconsiste em depurac¸˜ao remota, ou seja, permite testar dispositivos sem que estes estejam fisicamente conectados.
Esta plataforma tem as suas vantagens e desvantagens. A principal vantagem ´e que o c´odigo fonte a ser executado no sensor n˜ao precisa de ser alterado para que possa ser tes-tado. Uma desvantagem desta aplicac¸˜ao ´e o facto de este ter de ser instalado previamente no sensor. Este ocupa 32 KB da mem´oria do programa e 1 KB de mem´oria dos dados. Devido `a limitac¸˜ao de mem´oria que os sensores apresentam, se um programa necessitar de ocupar toda a mem´oria do sensor, este programa n˜ao vai poder ser testado [32].
Alguns dos comandos existentes no Clairvoyant permitem, adicionar breakpoint no c´odigo e eliminar o mesmo, produzir step no c´odigo para analisar instruc¸˜ao a instruc¸˜ao do c´odigo, entre outros. O comando stop permite que o sensor entre em modo de depurac¸˜ao, Al´em destes comandos para analisar o c´odigo do sensor existem certos comandos que permitem aceder ao hardware do sensor. Por exemplo, o comando interrupts identifica as interrupc¸˜oes que acontecem durante a execuc¸˜ao do c´odigo. Este comando permite, identificar condic¸˜oes de corrida que possam existir no c´odigo [32].
Devido `a grande facilidade de comunicac¸˜ao entre os sensores numa rede, ´e importante conseguir testar o comportamento da rede como um todo. E para poder realizar estes testes o Clairvoyant apresenta comandos para os efetuar. O comportamento destes testes ´e semelhante ao serem aplicados a um sensor individual, s´o que s˜ao aplicados `a rede toda [32].
Cap´ıtulo 2. Trabalho relacionado 13
2.4.3
TOSSIM
A ferramenta TOSSIM [23] permite simular o comportamento de redes de sensores que utilizem o sistema operativo TinyOS [22]. Este simulador tem um comportamento bas-tante fi´avel, quer para uma rede com poucos sensores, quer para uma rede com centenas de sensores. Como j´a vimos anteriormente, as redes de sensores tˆem caracter´ısticas ´unicas que trazem incerteza `a execuc¸˜ao de um programa e que podem levar ao mau funciona-mento das aplicac¸˜oes, tais como: factores ambientais extremos, problema de comunicac¸˜ao entre sensores, etc. Devido a isto, ´e muito importante que antes da rede de sensores seja colocado no seu local de ac¸˜ao esteja correta sem qualquer erro.
A simulac¸˜ao ´e uma forma de teste bastante usada para testar aplicac¸˜oes pois permite encontrar erros no comportamento da rede que vai ser simulada. No caso do TinyOS isto ´e importante pois utiliza linguagem baseada em eventos. A rede de sensores na plataforma TOSSIM ´e representado por um grafo, onde os n´os do grafo correspondem a um sensor e os v´ertices `a ligac¸˜ao entre os n´os da rede [23]. Devido `as caracter´ısticas do TinyOS, o si-mulador TOSSIM tem de ter quatro caracter´ısticas: escalabilidade, completude, fidelidade e bridging [23].
As redes de sensores constru´ıdas com o TinyOS s˜ao facilmente escal´aveis. Por isso, o simulador tem de conseguir simular uma grande quantidade de sensores na rede. Este as-peto traz escalabilidade ao simulador. A completude do simulador ´e necess´aria para poder simular o m´aximo de interac¸˜oes poss´ıveis entre os n´os da rede. A fidelidade do sistema de simulac¸˜ao ´e garantido se este conseguir simular sem qualquer erro o comportamento num n´o individual e entre n´os. A capacidade de bridging permite que os programadores consigam depurar o c´odigo implementado que vai ser executado nos sensores [23].
Este simulador permite simular, por exemplo, o hardware de um sensor na rede. Entre este hardware est´a o rel´ogio interno do sensor, a sequencia de inicio do sensor, entre outros. Permite tamb´em simular a comunicac¸˜ao entre os sensores da rede, definindo a efic´acia de transmiss˜ao dos dados entre os sensores da rede [23]. Esta caracter´ıstica ´e importante para testar a comunicac¸˜ao em ambientes mais complexos.
Esta plataforma tem a vantagem de permitir que outras aplicac¸˜oes se conectem a ela atrav´es do uso de socket TCP/IP. Isto permite que, uma aplicac¸˜ao de depura-c¸˜ao se possa ligar a este e possa testar o c´odigo que esteja a ser executado. Uma aplicac¸˜ao que faz uso destas funcionalidades ´e o TinyViz, esta ´e uma aplicac¸˜ao gr´afica que permite visuali-zar, analisar e controlar a execuc¸˜ao do simulador [23]. A desvantagem que este sistema apresenta ´e a suposic¸˜ao de que todos os n´os da rede est˜ao a executar o mesmo software.
2.5
Aplicac¸˜ao das redes de sensores
Esta secc¸˜ao ´e constitu´ıda por duas subsecc¸˜oes. Na primeira ´e feito um pequeno resumo dos diversos tipos de aplicac¸˜oes em que as redes de sensores podem ser aplicadas. Rela-tivamente `a segunda secc¸˜ao, s˜ao exemplificados exemplos pr´aticos de aplicac¸˜oes de redes de sensores.
2.5.1
Classificac¸˜ao da aplicabilidade de redes de sensores
As redes de sensores s˜ao aplicadas em diversas ´areas e existem muitos casos em que inves-tigadores desenvolveram linguagens de programac¸˜ao espec´ıficas para monitorizar certos aspetos. Devido `a grande variedade de ambientes onde as redes de sensores podem ser aplicadas, ´e necess´ario fazer uma avaliac¸˜ao dos tipos de requisitos que a rede de sensores vai precisar. Utilizando a figura 1 em [28], a aplicabilidade das redes de sensores pode ser classificada usando os seguintes aspectos: Objetivo da rede de sensores, padr˜ao de interac¸˜ao, mobilidade da rede, o espac¸o e o tempo.
O objetivo da rede ´e uma caracter´ıstica muito importante quando se quer aplicar uma rede de sensores num determinado ambiente. A rede pode ter como objetivo apenas obter os dados relativos ao ambiente em que est´a a ser aplicada. Uma rede que esteja a moni-torizar a meteorologia para que depois os meteor´ologos possam analisar os dados, ´e um exemplo de uma rede que tem este objetivo. Outro objetivo ´e obter os dados e tomar certas ac¸˜oes relativamente aos dados obtidos. Os sensores que est˜ao nos pr´edios a monitorizar fumos e poss´ıveis incˆendios, s˜ao um exemplo deste tipo de redes. Isto porque, depois de analisarem se existe a possibilidade de haver um incˆendio, os aspersores s˜ao ligados para o apagar [28].
O padr˜ao de interac¸˜ao de uma rede de sensores pode ser dividido em trˆes categorias: “um para muitos”, “muitos para muitos” e “muitos para um” [28]. A primeira categoria (“um para muitos”), ´e importante para ambientes em que seja necess´ario ter um sensor que envie certos comandos para os outros sensores da rede [28]. A categoria “muitos para muitos”, mais conhecida como macroprogramac¸˜ao, permite que todos os sensores na rede possam interagir entre si. Esta categoria, tem a vantagem de facilitar o trabalho dos programadores, pois podem definir o comportamento da rede como um todo em vez de o fazerem individualmente [28]. Por fim, “muitos para um” ´e muito importante em ambientes onde os sensores recebem dados do ambiente e enviam os dados para um sensor central. Este sensor posteriormente vai analisar os dados recebidos e tomar alguma ac¸˜ao relativamente a esses dados [28].
As redes de sensores podem ser est´aticas em que os sensores est˜ao est´aticos desde o momento em que a rede ´e colocada no ambiente. Esta modalidade ´e a mais utilizada
Cap´ıtulo 2. Trabalho relacionado 15
atualmente. As redes tamb´em podem ter alguns dos sensores da rede dinˆamicos, podendo estes sensores estar colocados em animais ou robots [24]. Os “mobile sink” podem ser ou est´aticas ou m´oveis. O papel mais importante destes sensores ´e a forma com os dados s˜ao obtidos. Os dados iram ser obtidos quando estes “mobile sink” se aproximam dos sensores [28]. Entre estas trˆes categorias, as redes de sensores est´aticas s˜ao as mais utilizadas. A sua utilizac¸˜ao prende-se por ser mais f´acil de ser aplicada no ambiente de utilizac¸˜ao. Sensores que sejam colocados em animais ou robots s˜ao claramente muito complicados de se controlar.
Como j´a foi referido anteriormente, as aplicac¸˜oes desenvolvidas para redes de sen-sores podem ser locais na rede, ou seja, podem envolver apenas alguns dos sensen-sores na rede. Para este caso pode-se utilizar algumas linguagens de programac¸˜ao, tais como: En-viroSuitee Logical Neighborhoods. Mas tamb´em podem envolver todos os sensores na rede.
As aplicac¸˜oes desenvolvidas para redes de sensores podem ser baseada em eventos onde os sensores ficam a aguardar que algum evento acontec¸a para poder tomar uma ac¸˜ao. ´E de realc¸ar que a linguagem desenvolvida nesta dissertac¸˜ao se encontra neste tipo de aplicabilidade. As aplicac¸˜oes tamb´em podem ter uma aplicac¸˜ao continua. Isto ´e, os sensores na rede v˜ao estar continuamente a processar dados, e se for o caso, executar ac¸˜oes relativas aos dados obtidos.
2.5.2
Exemplos pr´aticos da aplicabilidade das redes de sensores
Um grupo de investigadores aplicou um conjunto de sensores para avaliar o n´ıvel de deteriorac¸˜ao da torre Aquila em It´alia. Esta torre est´a localizada na entrada principal da cidade e devido ao constante fluxo de carros a entrar e sair da cidade, trouxe problemas para a estrutura desta torre. Para diminuir este problema foi aprovada a construc¸˜ao de um t´unel subterrˆaneo para diminuir o fluxo de carros. Ent˜ao este grupo de investigadores quis avaliar com uma rede de sensores qual o impacto na estrutura da torre deste t´unel [13].
Na floresta do Arizona estes sensores tamb´em tˆem um papel importante. Uma rede de sensores foi colocada numa regi˜ao remota que tem grandes dificuldades de acesso. Sendo assim, se ocorresse um incˆendio nessa ´area, esta iria arder durante horas at´e que fosse poss´ıvel identificar o incˆendio. Com a colocac¸˜ao de uma rede de sensores no local, assim que um sensor determinar um poss´ıvel fogo, comunica com os outros sensores da rede de modo a formar um per´ımetro `a volta desse local. Depois de este per´ımetro estar definido, envia um sinal via Internet para os bombeiros mais perto do local. Quando os bombeiros chegam ao local, injetam na rede agentes de procura para identificar se existe algu´em em perigo devido ao incˆendio. Os sensores voltam ao seu estado normal assim que o incˆendio ´e extinto, ou seja, ficam a monitorizar as vari´aveis do ambiente de modo a identificar se existe algum novo problema [15].
Cap´ıtulo 2. Trabalho relacionado 16
´e nos sensores que s˜ao acionados quando existe um fogo num edif´ıcio e comec¸a a apagar o incˆendio com ´agua. Com estes exemplos consegue-se perceber a versatilidade das redes de sensores e a sua importˆancia. Podem ajudar em muitos casos e resolver situac¸˜oes complicadas [20].
2.6
Considerac¸˜oes finais
Devido `a grande complexidade das redes de sensores, hoje em dia ´e cada vez mais impor-tante o desenvolvimento de linguagens de programac¸˜ao que facilitem o desenvolvimento de aplicac¸˜oes. Os custos relacionados com o desenvolvimento e colocac¸˜ao das redes nos ambientes alvo s˜ao muito elevados por isso este aspeto ´e muito importante.
Atualmente existem muitas aplicac¸˜oes que podem facilitar a depurac¸˜ao de aplicac¸˜oes desenvolvidas para redes de sensores. O aspeto negativo destas aplicac¸˜oes ´e que est˜ao desenvolvidas para uma ´unica arquitetura de sensores. Torna-se assim complicado, pois sempre que se queira desenvolver uma aplicac¸˜ao para um sensor diferente, tem de se co-nhecer a aplicac¸˜ao que ir´a ser necess´aria para depurac¸˜ao da aplicac¸˜ao. Se existir uma ´unica aplicac¸˜ao que seja gen´erica o suficiente para conseguir funcionar para todas as ar-quiteturas de sensores, ´e um aspeto positivo. Mas estes aspetos negativos n˜ao s˜ao s´o para aplicac¸˜oes de depurac¸˜ao de linguagens, mas tamb´em para as linguagens. As linguagens para sensores s˜ao desenvolvidas para um hardware espec´ıfico. Os programadores tˆem de ter conhecimento suficiente sobre o estado da arte das linguagens de programac¸˜ao, para que se for necess´ario alterar os dispositivos em que est˜ao a trabalhar estes saberem como os programar.
Cap´ıtulo 3
Linguagem de programac¸˜ao Macaw
O desenho de uma linguagem de programac¸˜ao ´e um processo desafiante. Em cada mo-mento debatemo-nos com quais as funcionalidades a incluir em func¸˜ao da expressividade que pretendemos, dos recursos de computac¸˜ao que est˜ao dispon´ıveis e quais as garantias que pretendemos que os programas satisfac¸am.
Ao termos a sintaxe definida foi necess´ario desenvolver a sua semˆantica operacional e o seu sistema de tipos.
O formato do bytecode e a linguagem interm´edia trouxeram novos problemas relati-vamente `a limitac¸˜ao de mem´oria que o hardware apresenta. Foi necess´ario perceber que informac¸˜ao do c´odigo fonte ´e que seria necess´ario utilizar para o bom funcionamento da M´aquina Virtual.
Este capitulo apresenta ao detalhe o processo de desenvolvimento da linguagem Ma-caw.
3.1
Sintaxe da linguagem
O desenho da sintaxe da linguagem teve de ter v´arios fatores em causa. Um deles foi relativamente ao tipo de hardware onde a linguagem vai ser utilizada. Devido aos diver-sos problemas que estes dispositivos apresentam, a linguagem teve de ter certos cuidados. N˜ao se podia utilizar instruc¸˜oes que pudessem vir a esgotar rapidamente a mem´oria do sensor. Isto faria com que a aplicabilidade da linguagem fosse bastante pequena. Uma outra funcionalidade que esta linguagem n˜ao poderia permitir ´e a programac¸˜ao recursiva pois, se isto fosse poss´ıvel, a mem´oria do sensor iria-se esgotar facilmente e ter´ıamos novamente o problema de mem´oria dos sensores. Como um dos objetivos da linguagem consiste em identificar alguns consumos energ´eticos estes dados est˜ao presentes na lin-guagem para fazer essa an´alise.
Um programa escrito em linguagem Macaw ´e constitu´ıda por dois ficheiros, um .ma-cawh e outro .macaw. O ficheiro .macawh, ´e utilizado para descrever o hardware dos sensores em que a linguagem vai ser aplicada. Esta definic¸˜ao de hardware consiste em
Cap´ıtulo 3. Linguagem de programac¸˜ao Macaw 18
definir os m´odulos de hardware do dispositivo que vai ser utilizado. Por exemplo, se o dispositivo que vai ser utilizado tem um m´odulo de GPRS e um m´odulo Solenoid e ambos v˜ao ser utilizados para a programac¸˜ao da rede, ent˜ao estes tˆem de ser definidos na secc¸˜ao “Hardware States”. Se fosse o caso de o m´odulo GPRS n˜ao ser utilizado, ent˜ao n˜ao seria necess´ario ser definido nesta secc¸˜ao. Associado `a definic¸˜ao de um m´odulo est´a consumo energ´etico, indicando o valor normal e o m´aximo que esse m´odulo ir´a consumir.
A segunda secc¸˜ao (“Boot”) ´e utilizada para definir quais os m´odulos que v˜ao estar ligados ou desligados quando a aplicac¸˜ao arrancar. Os m´odulos aqui indicados s˜ao aqueles que foram definidos na secc¸˜ao anterior.
A terceira e ´ultima secc¸˜ao indica quais os eventos e as func¸˜oes de hardware que v˜ao ser utilizadas. Um evento ocorre quando uma ac¸˜ao externa ´e executada. Por exemplo, se existe um evento chamado buttonPressed(), este vai ser acionado quando algu´em carregar no bot˜ao do sensor. Para estes eventos ´e necess´ario indicar a sua assintaura. Relativamente `as func¸˜oes de hardware, tal como os eventos, ´e necess´ario ser definido a sua assinatura. O seu desenvolvimento ´e produzido na m´aquina virtual da linguagem. Estas s˜ao as func¸˜oes nativas do hardware utilizado. Uma outra diferenc¸a relativamente a estas func¸˜oes nativas comparativamente aos eventos ´e que podem retornar valores. Quer para os eventos quer para as func¸˜oes de hardware ´e poss´ıvel definir cl´ausulas “when”, “exec” e “turns”. A cl´ausula “when” serve para determinar quando um certo evento ou func¸˜ao de hardware podem ser executadas, identificando o estado em que os m´odulos de hardware necessi-tam de estar para que este possa serem executados. A cl´ausula “exec”, ´e utilizada para determinar os consumos energ´eticos, o valor indicado consiste no consumo energ´etico do hardware ao executar o determinado evento ou func¸˜ao. A cl´ausula “turns”, identifica em que estado o hardware vai ficar depois de o evento ou a func¸˜ao de hardware ser exe-cutado. As cl´ausulas “when” e “turns” podem ser vistas como uma pr´e-condic¸˜ao e uma p´os-condic¸˜ao do m´etodo, respetivamente. Estas trˆes ´ultimas cl´ausulas (“when”, “exec” e “turns”) s˜ao opcionais. De realc¸ar que os eventos tˆem de ser definidos antes das func¸˜oes de hardware.
Este ficheiro permite que o programador, que v´a desenvolver o software das redes de sensores n˜ao necessite de ter o conhecimento total do hardware do sensor que vai ser utilizado. Tamb´em permite, que este ficheiro seja desenvolvido pela mesma pessoa que desenvolveu a M´aquina Virtual, permitindo assim garantir que este ficheiro ´e desenvol-vido de acordo com a especificac¸˜ao utilizada na M´aquina Virtual. A sintaxe detalhada para este ficheiro pode ser consultada na Figura A.1.
O ficheiro .macaw permite desenvolver o software que vai ser utilizado na rede de sensores. Inicialmente, ´e necess´ario indicar qual o ficheiro .macawh que vai ser utili-zado. Esta localizac¸˜ao ´e indicada na secc¸˜ao “hardware description”. Posteriormente a esta secc¸˜ao, ´e poss´ıvel indicar as vari´aveis globais necess´arias para o desenvolvimento do programa. A novidade em relac¸˜ao `as vari´aveis globais ´e o facto da inicializac¸˜ao de array
Cap´ıtulo 3. Linguagem de programac¸˜ao Macaw 19
poder ter “...”. Ao definir esta “string”, as restantes posic¸˜oes do array v˜ao ser preenchi-das autom´aticamente. Estas posic¸˜oes v˜ao ser preenchipreenchi-das com o valor definic¸˜ao para o tipo do array. Por exemplo, se um array for do tipo “int8” com 50 posic¸˜oes e apenas forem preenchidas 2 posic¸˜oes, as restantes posic¸˜oes v˜ao ser preenchidas com o valor 0. Os membros do programa s˜ao de dois tipos diferente, func¸˜oes ou “handler”. As func¸˜oes tˆem um comportamento esperado de uma func¸˜ao, enquanto que os “handler” s˜ao apenas chamados quando um evento ´e acionado. Os membros tˆem de ter o seu corpo bem de-finido. Inicialmente, ´e necess´ario indicar as vari´aveis locais do membro, seguindo-se as instruc¸˜oes e por fim depois de estas estarem definidas pode-se indicar o comando de re-torno. A definic¸˜ao de vari´aveis locais ´e feito exatamente da mesma forma que as vari´aveis globais.
As instruc¸˜oes que se podem utilizar s˜ao as atribuic¸˜oes de valores a vari´aveis, a cha-mada de func¸˜oes, o comando “attach” que permite fazer a ligac¸˜ao entre um evento e um “handler” do programa, ou seja, quando o evento for acionado o “handler” correspon-dente vai ser acionado, o comando “unfold” permite executar o seu corpo um n´umero determinado de vezes, o comando “if ” ´e um comando condicional que permite avaliar ex-press˜oes e por fim, o comando “ifStateContains” permite avaliar se o estado do hardware naquele ponto ´e verdadeiro ou falso.
As express˜oes que podem ser utilizadas s˜ao as que s˜ao utilizadas em todas as lingua-gens do tipo imperativo. Pode-se utilizar express˜oes relacionais, aditivas e multiplicativas. Relativamente aos tipos da linguagem, de realc¸ar que o array, apenas permite um inteiro de 8 bits para representar o seu tamanho, esta decis˜ao teve em base n˜ao s´o a mem´oria dispon´ıvel por parte dos dispositivos da rede, mas tamb´em por acharmos que para o tipo de hardware em que a linguagem vai ser executada um array com 128 posic¸˜oes ´e suficiente. Como tipos tamb´em temos os tipos constantes, estes s˜ao definidos apenas uma vez e o seu valor n˜ao pode ser alterado novamente ao longo do programa.
Os tipos primitivos “int8”, “int16” e “int32” s˜ao signed, ou seja, podem estar entre os valores indicados na tabela 3.1. O tipo “boolean” e o tipo “float” podem ter os valores esperados. A sintaxe detalhada para este ficheiro pode ser consultada na Figura A.2.
Uma das caracter´ısticas que se queria desta linguagem ´e que fosse simplista o su-ficiente para que qualquer pessoa com pouco conhecimento de programac¸˜ao a pudesse utilizar. E por isto mesmo, as instruc¸˜oes e caracter´ısticas da linguagem foram mantidas o mais simples poss´ıvel. Uma outra vantagem que esta linguagem apresenta ´e o facto de ser facilmente utilizada em v´arios tipos de sensores. Estas func¸˜oes s´o necessitam de estar definidas na M´aquina Virtual da linguagem e depois consiste apenas em chamar essas mesmas func¸˜oes.
Cap´ıtulo 3. Linguagem de programac¸˜ao Macaw 20
Tipo Valor M´ınimo Valor M´aximo
int8 -128 127
int16 -32 768 32 767
int32 -2 147 483 648 2 147 483 647 Tabela 3.1: Diferenc¸a de valores de inteiros
3.2
Semˆantica operacional
O desenho da semˆantica operacional da linguagem Macaw foi um aspeto necess´ario de modo a provar que o funcionamento da linguagem ´e correto.
A semˆantica operacional consiste em desenvolver provas de modo a validar o compor-tamento correto da linguagem. Estas provas podem ser desenvolvidas de uma forma in-formal utilizando c´odigo m´aquina por exemplo, mas tamb´em podem ser representados de uma forma formal utilizando uma semˆantica operacional ou interpretador da linguagem. Nestes modelos formais ´e definido um estado do programa, e as provas consistem em alterar esses estados tendo em conta alguns comandos da linguagem [14]. Por exemplo, a regra Assign-Simple-Global, consiste em alterar o estado do programa quando existe uma atribuic¸˜ao de valor a uma vari´avel global.
O primeiro passo para desenvolver uma semˆantica operacional da linguagem consiste em representar o que ´e um estado de execuc¸˜ao da linguagem. Este estado ´e definido utilizando a sintaxe de ambiente de execuc¸˜ao da linguage Macaw representada na figura B.1. Esta sintaxe ´e constitu´ıda por um dispositivo, contexto global do programa, pelo c´odigo do programa, por um contexto local, uma pilha de chamadas, uma pilha de eventos e por fim a tabela de despacho.
• O dispotivo ´e utilizado para representar um estado de execuc¸˜ao da linguagem Ma-caw;
• O contexto global (D) do programa consiste em todas as definic¸˜oes de vari´aveis globais do programa, sendo estas representadas pelo seu nome (x), a sua posic¸˜ao (i) e o seu valor (v);
• Os membros (T) correspondem a todos os membros definidos no programa. S˜ao representados pelo seu nome (y), por uma lista de vari´aveis (~x) e pelo corpo do membro (c);
• A pilha de chamadas (S), representa os membros que s˜ao chamados, este ´e represen-tado por v´arios c´odigos locais. O c´odigo local corresponde `a execuc¸˜ao de comandos do corpo do membro, este ´e constitu´ıdo pelo corpo do m´etodo (c) e pelo contexto local do membro (D);
Cap´ıtulo 3. Linguagem de programac¸˜ao Macaw 21
• A pilha de eventos (Q) vai conter os eventos que foram definidos no ficheiro .ma-cawh. Estes eventos s˜ao representados pelo seu nome (x) e por uma lista de valores (~v) referente aos tipos dos seus parˆametros;
• A tabela de despacho (H) liga os eventos com os seus “handler”, esta ligac¸˜ao ´e produzida entre o nome ´unico do evento (x) e o nome do “handler” (y) que vai ser executado quando o evento for acionado.
Tendo em conta o estado de execuc¸˜ao da linguagem Macaw, definiu-se o estado inicial da linguagem Macaw. Este estado est´a descrito na figura B.2.
O estado inicial da linguagem ´e definido com todas as vari´aveis globais do programa (D0), cont´em todos os membros definidos do programa (T0), inicialmente n˜ao tem
ne-nhum membro a ser executado, cont´em o evento inicial que vai iniciar o programa, este evento n˜ao tem qualquer parˆametro por isso a sua lista de valores est´a vazia e a tabela de despacho inicialmente faz a ligac¸˜ao entre o evento de arranque da aplicac¸˜ao e o “ handler” main.
A primeira regra (Bind), identifica a mudanc¸a de estado quando ocorre um comando “attach” durante a execuc¸˜ao de um membro. Quando este comando ´e executado vai ser introduzida uma ligac¸˜ao entre o evento x e o “handler” y na tabela de despacho. Este comando n˜ao altera nada no dom´ınio local do membro depois de ser executado.
A regra unfold-out, demonstra o comportamento do comando “unfold” quando a execu-c¸˜ao deste comando termina. Ao avaliar a express˜ao do comando “unfold”, se o resultado for zero, significa que o comando terminou a sua execuc¸˜ao e por isso mesmo o resto do c´odigo (c2) vai ser executado. Este comando “unfold” depois de ser executado n˜ao faz
qualquer outra alterac¸˜ao no estado da linguagem.
A regra unfold-in, prova o comportamento do comando “unfold” quando este est´a a ser executado. Se a express˜ao do comando quando for avaliada for maior que zero, isto significa que o comando ainda est´a a ser executado. O comportamento consiste em executar o corpo do “unfold” (c1) uma vez, e decrementar em uma unidade a express˜ao
do comando.
A quarta regra if-then-else-false, prova o comportamento do comando “if ” quando a sua express˜ao tem o resultado falso. A express˜ao do comando “if ” ao ser avaliada, se o seu resultado for falso, ent˜ao vai ser executado o c´odigo referente ao comando “else”. Sendo assim, c2 vai ser executado seguido de c3e do resto do corpo do membro.
A regra if-then-else-true, tem o mesmo objetivo de comprovar o comando “if ”, mas esta regra consiste no caso de a express˜ao ser avaliada como verdadeira. A diferenc¸a relativamente `a regra anterior, ´e que em vez de ser executado o c´odigo referente ao “else”, vai ser executado o c´odigo referente ao “then”. Sendo assim, a sequencia de execuc¸˜ao ir´a ser c1sendo posteriormente executado c3e o resto do membro.
Cap´ıtulo 3. Linguagem de programac¸˜ao Macaw 22
duas seguintes regras (IfStateContains-True e IfStateContains-False) tˆem o mesmo obje-tivo. A diferenc¸a consiste em que estas s˜ao utilizadas para comprovar o comportamento do comando “ifStateContains”.
A regra Call, prova o comportamento da linguagem quando existe uma chamada a um membro. Quando existe uma chamada a uma func¸˜ao no c´odigo que est´a a ser executado, o c´odigo local desse membro vai ser adicionado ao topo da pilha de chamadas, sendo esse membro o que ir´a ser executado. Este c´odigo local, vai ter o c´odigo do membro e o dom´ınio ir´a ter os valores atribu´ıdos na chamada do membro.
A regra Return, comprova o comportamento da linguagem no fim da execuc¸˜ao de um membro quando ´e encontrado um comando “return”. Ao ser encontrado este comando, o c´odigo local referente a esse membro vai ser retirado da pilha de chamadas, sendo executado o seguinte c´odigo local que est´a presente na pilha de chamadas.
A regra event, consiste em adicionar um evento `a pilha de eventos quando um evento ´e encontrado. Adicionado o seu identificador ´unico e os tipos dos seus parˆametros.
A regra Fire, prova o comportamento da linguagem quando um evento ´e acionado. Inicialmente o evento est´a na pilha de eventos, este ao ser acionado vai adicionar ao c´odigo local o corpo referente ao seu “handler” e o dom´ınio local vai conter os parˆametros do “handler”.
A regra Decl-Simple-Local, prova o comportamento da linguagem ao declarar uma vari´avel local. Ao declarar uma vari´avel, se esta pertencer ao dom´ınio local (D’) ent˜ao o seu nome e valor v˜ao ser adicionados ao dom´ınio local.
A regra seguinte (Assign-Simple-Local), tem como objetivo provar o comportamento da linguagem numa atribuic¸˜ao de valor a uma vari´avel local. A mudanc¸a de estados ´e semelhante `a regra anterior, ou seja, o nome e o valor da mesma v˜ao ser adicionados ao dom´ınio local do membro.
A regra Assign-Simple-Global, pretende comprovar o comportamento da linguagem, quando ´e atribu´ıdo um valor a uma vari´avel global. A diferenc¸a desta regra relativamente `a regra anterior, consiste em a vari´avel ter de pertencer ao contexto global e n˜ao ao contexto local do programa.
Por fim, a regra Assign-Array-Global, consiste em comprovar o comportamento de atribuir um valor a uma vari´avel do tipo array. Ao atribuir um valor a um array, se este pertencer ao dom´ınio global do programa e v2que indica a posic¸˜ao de atribuic¸˜ao do valor,
estiver correta, ent˜ao vai-se adicionar o novo valor v1ao array global.
Com estas provas consegue-se validar o bom comportamento da linguagem dimi-nuindo assim o n´umero de erros que a linguagem possa ter.
