Utilizando Engenharia Semiótica para a Construção de uma Ferramenta de Simulação para Redes de Sensores Sem Fio

ISSN 0103-9741 Monografias em Ciˆ encia da Computac¸ ˜ ao no06/11 Utilizando Engenharia Semi´ otica na Construc¸ ˜ ao de uma Ferramenta de Simulac¸ ˜ ao para RSSF Adriano Branco Jos´ e Antˆ onio Motta Clarisse Sieckenius de Souza Departamento de Inform´ atica PONTIF´ ICIA UNIVERSIDADE CAT ´ OLICA DO RIO DE JANEIRO RUA MARQU ˆ ES DE S ˜ AO VICENTE, 225 - CEP 22451-900 RIO DE JANEIRO - BRASIL Monografias em Ciˆ encia da Computac¸ ˜ ao, No. 06/11 ISSN: 0103-9741 Editor: Prof. Carlos Jos´ e Pereira de Lucena Agosto, 2011 Utilizando Engenharia Semi´ otica na Construc¸ ˜ ao de uma Ferramenta de Simulac¸ ˜ ao para RSSF Adriano Branco Jos´ e Antˆ onio Motta Clarisse Sieckenius de Souza {abranco , jmotta , clarisse}@inf.puc-rio.br Resumo. A construc¸˜ ao de uma aplicac¸˜ ao na ´ area de Redes de Sensores sem Fio (RSSF) exige do desenvolvedor uma vis˜ ao completa do projeto, incluindo ambiente e detalhes de hardware. Consideramos que essa vis˜ ao possa ser passada atrav´ es de um tutorial que apresente alguns conceitos de RSSF apoiado por uma ferramenta de simulac¸˜ ao. Nosso objetivo ´ e aplicar os conceitos da Engenharia Semi´ otica na definic¸˜ ao de uma ferramenta de simulac¸˜ ao para RSSF e avaliar o uso do AgentSheets para a construc¸˜ ao deste simulador. Este documento apresenta os conceitos utilizados na construc¸˜ ao da ferramenta, detalha o processo da definic¸˜ ao do simulador e termina com uma conclus˜ ao sobre todo o processo de desenvolvimento e o simulador constru´ ıdo. Palavras-chave: Engenharia Semi´ otica, AgentSheets, Redes de Sensores sem Fio Abstract. Building WSN application requires complete view of the project from the developer, including environment and hardware details. We think this view can be understood through the use of a tutorial which presents some WSN concepts supported by a simulation tool. Our goal is to use some Semiotic Engineering concepts in order to build a simulator for WSN and evaluate the use of AgentSheets as a tool to build this simulator. This report presents the concepts in the tool development, details on design decisions about the tool and ends with a conclusion about the whole process and the simulator developed. Keywords: Semiotic Engineering, AgentSheets, Wireless Sensor Network Respons´ avel por publicac¸ ˜ oes: Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentac¸ ˜ ao e Informac¸ ˜ ao PUC-Rio Departamento de Inform´ atica Rua Marquˆ es de S˜ ao Vicente, 225 - G´ avea 22451-900 Rio de Janeiro RJ Brasil Tel. +55 21 3527-1516 Fax: +55 21 3527-1530 E-mail: [email protected] Web site: http://bib-di.inf.puc-rio.br/techreports/ ii Sum´ ario 1 Introduc¸ ˜ ao 1 2 Conceitos B´ asicos 1 2.1 Engenharia Semi´ otica .............................. 1 2.2 Redes de sensores sem fio . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Intenc¸ ˜ ao de comunicac¸ ˜ ao 4 3.1 Mensagem de metacomunicac¸ ˜ aoInicial .................... 4 3.2 Processo de detalhamento da meta-mensagem . . . . . . . . . . . . . . . . 5 3.3 Interfaceproposta ................................ 7 4 Implementac¸ ˜ ao 14 4.1 Recursos do AgentSheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Vers˜ aoimplementada .............................. 15 5 Avaliac¸ ˜ ao do trabalho 15 5.1 Consequˆ encias da dificuldade de implementac¸ ˜ ao............... 16 5.2 Avaliac¸ ˜ ao ..................................... 17 6 Conclus˜ ao e trabalhos futuros 18 Referˆ encias 20 1 Introduc¸ ˜ ao A construc¸˜ ao de uma aplicac¸˜ ao na ´ area de Redes de Sensores sem Fio (RSSF) exige do desenvolvedor uma vis˜ ao completa do projeto, incluindo a distribuic¸˜ ao f´ ısica dos n´ os sensores, os recursos de hardware dispon´ ıveis e a programac¸˜ ao da rede como um todo [1]. Uma ferramenta de aprendizado que utilize uma linguagem visual para transmitir os conceitos de RSSF poderia permitir uma melhor compreens˜ ao do que ocorre numa rede sem a necessidade de se conhecer profundamente a teoria. Uma plataforma de desenvolvimento que permite a criac¸˜ ao de uma ferramenta deste tipo ´ e o AgentSheets [2]. O AgentSheets ´ e uma ferramenta que utiliza uma linguagem visual de f´ acil interac¸˜ ao e que foi feita para ensino b´ asico de computac¸˜ ao. Nessa ferramenta os usu´ arios podem criar pequenos jogos ou simulac¸ ˜ oes sem a necessidade de se utilizar uma linguagem de programac¸˜ ao textual. A programac¸˜ ao da ferramenta de aux´ ılio no ensino de RSSF seria feita atrav´ es da criac¸˜ ao de alguns componentes b´ asicos para permitir que o usu´ ario da ferramenta possa, atrav´ es da interface do AgentSheets, executar, modificar ou criar novas simulac¸ ˜ oes de RSSF. Inicialmente, a simulac¸˜ ao ser´ a utilizada, por um instrutor, como ferramenta num tutorial para apresentac¸˜ ao do conceito de RSSF e, em seguida, dever´ a ser utilizada pelos alunos para fixar os conceitos aprendidos. Os objetivos principais deste trabalho s˜ ao aplicar conceitos da engenharia semi´ otica [3] para especificar uma aplicac¸˜ ao e tamb´ em avaliar a capacidade do AgentSheets em auxiliar um professor de Redes de Sensores sem Fio a ensinar os conceitos da ´ area. O aplicativo ser´ a utilizado na construc¸˜ ao de um simulador de uma rede de sensores sem fio onde professores e alunos poder˜ ao interagir com o simulador e observar o comportamento de uma RSSF constru´ ıda por eles mesmos. Para a construc¸˜ ao do simulador, comec¸amos criando uma mensagem de metacomunicac¸˜ ao que nos guiou durante o processo de desenvolvimento. Depois, realizamos um estudo sobre o AgentSheets identificando algumas caracter´ ısticas que poderiam nos auxiliar ou atrapalhar no processo de desenvolvimento. A partir disso, incrementamos alguns trechos da metamensagem com detalhamento de alguns signos que foram usados na aplicac¸˜ ao. Por fim, no processo de implementac¸˜ ao tentamos representar os principais signos identificados na nossa mensagem de metacomunicac¸˜ ao. Na pr´ oxima sec¸˜ ao (2) apresentamos alguns conceitos b´ asicos que apoiam o nosso trabalho, em seguida, na sec¸˜ ao 3, apresentamos em detalhes a nossa intenc¸˜ ao de comunicac¸˜ ao atrav´ es das mensagens de metacomunicac¸˜ ao. Na sec¸˜ ao 4 apresentamos a descric¸˜ ao da nossa implementac¸˜ ao no AgentSheets e em seguida, na sec¸˜ ao 5 fazemos a nossa avaliac¸˜ ao. Finalmente, na sec¸ ˜ ao 6, apresentamos as nossas considerac¸ ˜ oes finais. 2 Conceitos B´ asicos 2.1 Engenharia Semi ´ otica A Engenharia Semi´ otica ´ e uma teoria baseada na vis˜ ao de que a interac¸˜ ao humanocomputador ´ e um caso particular de comunicac¸˜ ao entre pessoas mediada por um computador. Esta comunicac¸˜ ao ´ e realizada em dois n´ ıveis: um ´ e a comunicac¸˜ ao direta entre o usu´ ario e o sistema e o outro ´ e o processo de metacomunica¸c˜ao que acontece entre o usu´ ario e o designer usando o sistema como meio. ´ E atrav´ es da metacomunicac¸˜ ao que o designer explicita a sua vis˜ ao sobre a tarefa que o usu´ ario deve realizar e tudo que influencia na 1 execuc¸˜ ao desta tarefa (como o perfil do usu´ ario e suas preferˆ encias). O conte´ udo dessa da mensagem de metacomunicac¸˜ ao pode ser caracterizado pelo seguinte template [4]: “Eis a minha vis˜ao de quem vocˆe ´e, o que aprendi que vocˆe deseja ou precisa fazer, de que formas preferenciais e por quˆe. Este ´e o sistema que consequentemente elaborei para vocˆe, e esta ´e a forma como vocˆe pode ou deve us´a-lo para realizar um conjunto de objetivos que se enquadram nesta vis˜ao.” Depois que o designer concebe sua vis˜ ao sobre quem ´ e o usu´ ario e suas necessidades, ele deve codific´ a-la atrav´ es de palavras, gr´ aficos, comportamentos do sistema, ajuda online etc. De acordo com a Semi´ otica, todos esses elementos que podem ser utilizados s˜ ao signos. A Engenharia Semi´ otica faz uso principalmente da semi´ otica peirceana que diz que todo signo ´ e algo que representa alguma coisa para algu´ em [5]. Peirce classificou os signos em v´ arias categorias, mas as principais para a Engenharia Sem´ ı´ otica s˜ ao: •´ıcone: pode ser associado ao objeto que representa atrav´ es das caracter´ ısticas que podem ser identificadas atrav´ es dos sentidos (vis˜ ao, audic¸˜ ao etc). •´ındice: pode ser associado ao objeto que por uma relac¸˜ ao de causa ou co-ocorrˆ encia. O conhecimento para se identificar um ´ ındice, normalmente, vem atrav´ es da heranc¸a cultural do indiv´ ıduo. •s´ımbolo: a relac¸˜ ao entre o signo e o objeto se d´ a atrav´ es de alguma norma pr´ eestabelecida. Al´ em das categorias de signos criada por Peirce, a Engenharia Semi´ otica criou a sua pr´ opria classificac¸˜ ao dos signos em func¸˜ ao do que eles expressam na interface de um sistema: •signos est´aticos: signos que expressam um estado do sistema e cujo significado pode ser entendido sem a necessidade de se interagir com o sistema. •signos dinˆamicos: signos que expressam o comportamento do sistema e cujo significado s´ o pode ser compreendido no decorrer da interac¸˜ ao com o sistema. •signos metalingu´ısticos: signos fazem referˆ encia a outros signos da interface (est´ aticos, dinˆ amicos ou metalingu´ ısticos). A metamensagem ´ e utilizada por alguns m´ etodos da Engenharia Semi´ otica que avaliam a qualidade da metacomunicac¸˜ ao de sistemas analisando os signos da interface, como o M´ etodo de Inspec¸˜ ao Semi´ otica [6] e o M´ etodo de Avaliac¸˜ ao de Comunicabilidade [7]. 2.2 Redes de sensores sem fio 2.2.1 Tecnologia Uma rede de sensores ´ e um grupo de pequenos sistemas autˆ onomos denominados de N´ os Sensores (sensor nodes). Estes n´ os cooperam para resolver pelo menos um problema comum. Geralmente suas func¸ ˜ oes incluem algum tipo de percepc¸ ˜ ao de parˆ ametros f´ ısicos [8]. 2 Um N´ o Sensor sem Fio (WSN - Wireless Sensor Network) ´ e um sistema que tem capacidade de comunicac¸˜ ao, computac¸˜ ao, sensoriamento e armazenagem. Esses n´ os miniaturizados operam com restric¸ ˜ oes severas em termos de recursos dispon´ ıveis, como a energia da bateria, mem´ oria RAM, largura de banda de comunicac¸˜ ao dispon´ ıvel e poder de processamento. A figura 1 mostra um diagrama esquem´ atico dos componentes de um n´ o sensor. Cada n´ o´ e composto por um micro-controlador, fonte de alimentac¸˜ ao, transceptor de R´ adio Frequˆ encia (RF), mem´ oria externa e sensores. Figura 1: M´odulos de um N´o Sensor Centenas de milhares desses n´ os sensores s˜ ao implantados numa larga variedade de aplicac¸ ˜ oes, que v˜ ao desde campos vulcˆ anicos at´ e monitoramento ambiental. Esses n´ os sensores podem se comunicar uns com os outros numa rede ad-hoc usando caminhos de comunicac¸˜ ao multi-hop, assim formando uma rede de sensores (WSN). Em v´ arios tipos de aplicac¸ ˜ oes, ap´ os a implantac¸˜ ao, os n´ os sensores s˜ ao de dif´ ıcil acesso. Por esse motivo essas redes devem ser autˆ onomas e apresentar longa durac¸˜ ao. Quase sempre os n´ os sensores precisam sobreviver ` as duras condic¸ ˜ oes ambientais e conservar o m´ aximo de energia poss´ ıvel. O trabalho de desenvolvimento de aplicac¸ ˜ oes para RSSF ´ e impactado pelos mesmos desafios encontrados no desenvolvimento de aplicac¸ ˜ oes para sistemas distribu´ ıdos que utilizam plataformas tradicionais. Por´ em, alguns desses desafios s˜ ao aumentados pela escassez de recursos computacionais dos motes, pelo modelo de programac¸˜ ao tipicamente adotado que ´ e orientado a eventos e pela tecnologia de comunicac¸˜ ao sem fio com caracter´ ısticas de redes ad-hoc. A vis˜ ao geral de um projeto em RSSF torna-se complexa a partir da forte dependˆ encia entre a definic¸˜ ao do tipo de dispositivo, a topologia da rede e a complexidade do programa executado em cada dispositivo. Por exemplo, uma aplicac¸˜ ao com centenas de n´ os tende a minimizar o custo utilizando dispositivos mais simples, que por consequˆ encia disp˜ oem poucos recursos de hardware e limitando o tamanho e complexidade do programa a ser executado. Um outro exemplo ´ e uma aplicac¸˜ ao que necessita operar por um longo tempo e os dispositivos n˜ ao s˜ ao de f´ acil acesso, nesse caso o programa a ser executado deve minimizar ao extremo o uso dos recursos utilizados, economizando, dessa forma, o consumo de energia. 2.2.2 Vis˜ ao de um projeto em RSSF Uma caracter´ ıstica importante no projeto de RSSF ´ e a forte dependˆ encia entre o projeto f´ ısico e o projeto de sistema computac¸˜ ao [1]. A maioria dos projetos de sistemas de computac¸˜ ao s˜ ao feitos para plataformas de execuc¸˜ ao padronizadas e normalmente o am3 biente f´ ısico n˜ ao interfere de forma significante na soluc¸˜ ao final. Em um projeto de RSSF essa dependˆ encia ´ e fundamental para a soluc¸˜ ao conjunta final. O exemplo principal ´ e a pr´ opria func¸˜ ao da RSSF que, normalmente, trabalha com sensoriamento de grandezas f´ ısicas do ambiente como medic¸˜ ao de temperatura e luminosidade. Um outro exemplo t´ ıpico dessa dependˆ encia ´ e o caso em que o protocolo de comunicac¸˜ ao de dados deve minimizar o uso do r´ adio para economizar energia e consequentemente prolongar o tempo de vida da rede. A situac¸˜ ao muito comum e facilitadora de softwares que disponibilizam v´ arias funcionalidades tamb´ em n˜ ao ´ e uma boa estrat´ egia em RSSF. Muitas vezes as limitac¸ ˜ oes de mem´ oria e processamento permitem que s´ o se carreguem no dispositivo a parte do software estritamente necess´ aria. Por exemplo, n˜ ao podemos carregar uma biblioteca completa para todos tipos sensores, deve-se carregar somente os componentes para os sensores que est˜ ao fisicamente ligados no dispositivo. De forma geral o projeto de software deve considerar os tipos de sensores utilizados, a disposic¸˜ ao dos n´ os na rede, a capacidade de alimentac¸˜ ao e as limitac¸ ˜ oes de recursos computacionais como mem´ oria e processamento. Por isso entendemos que a melhor forma de introduzir o conceito de RSSF ´ e permitir ao aluno compreender a diferenc¸a entre o ambiente, o projeto da rede e as funcionalidades executas nos dispositivos. 3 Intenc¸ ˜ ao de comunicac¸ ˜ ao Nesta sec¸˜ ao apresentamos o resultado para o nossa intenc¸˜ ao de comunicac¸˜ ao. Obtemos o resultado aplicando o template de metacomunicac¸˜ ao da Engenharia Semi´ otica e em seguida detalhando a meta-mensagem obtida. 3.1 Mensagem de metacomunicac¸ ˜ ao Inicial Baseado na nossa intenc¸˜ ao, definimos como mensagem de metacomunicac¸˜ ao inicial o seguinte texto: “Vocˆe ´e um professor especialista em redes de sensores sem fio (RSSF) e d´a aulas h´a muito tempo. Seus alunos s˜ao universit´arios que tˆem conhecimento sobre inform´atica, mas n˜ao sabem nada sobre RSSF. Vocˆe percebeu que uma caracter´ıstica t´ıpica dos projetos em RSSF ´e a necessidade de compreens˜ao dos conceitos envolvidos em todo processo de um projeto, n˜ao se limitando a vis˜ao t´ıpica de programa¸c˜ao de um aplicativo. Vocˆe est´a buscando uma forma que seja eficaz de ensinar dois desses conceitos importantes: o da defini¸c˜ao do ambiente simulado e da defini¸c˜ao da rede de sensores. Sua ideia ´e utilizar uma ferramenta de simula¸c˜ao em um tutorial. Essa ferramenta usa uma linguagem visual que auxilia o aprendizado, pois ela pode comunicar ideias sem a necessidade de j´a saber os detalhes do que est´a ocorrendo. Para lhe ajudar, estou disponibilizando um simulador de RSSF que desenvolvi no AgentSheets que ´e uma ferramenta para simula¸c˜oes simples. Eu criei um conjunto de componentes que podem ser utilizados para construir o ambiente, montar a rede de sensores e criar est´ımulos nessa rede. Esses componentes est˜ao no contexto de medi¸c˜ao de temperatura, sendo que os conceitos utilizados s˜ao os mesmos para outros contextos de utiliza¸c˜ao. Vocˆe e seus alunos poder˜ao montar simula¸c˜oes simplesmente combinando alguns dos componentes disponibilizados e cada simula¸c˜ao permitir´a acompanhar quais s˜ao as consequˆencias da organiza¸c˜ao dos componentes. Durante uma simula¸c˜ao ser´a poss´ıvel observar as varia¸c˜oes de temperatura. Tamb´em ser´a poss´ıvel observar situa¸c˜oes de 4 alarme em cada sensor e visualizar o resultado dos c´alculos peri´odicos definidos para cada grupo de sensor. A ideia ´e que observando e interagindo com a simula¸c˜ao, os alunos possam consolidar certas conceitos relacionados a RSSF.” 3.2 Processo de detalhamento da meta-mensagem Para podermos definir quais ser˜ ao as principais id´ eias que queremos expressar atrav´ es do simulador e quais os signos que utilizaremos para nos comunicarmos com os usu´ arios, quebramos a metamensagem em alguns trechos que consideramos poderem ser utilizados como uma esp´ ecie de lista informal de requisitos funcionais que o sistema deve atender. Isso n˜ ao quer dizer que o restante da metamensagem foi ignorada. Pelo contr´ ario, ela foi ´ util para nos guiar na escolha de signos adequados tendo em vista os usu´ arios que ir˜ ao utilizar o simulador. O resultado deste processo ser´ a uma proposta de interface que deve levar em conta todas as considerac¸ ˜ oes feitas nesta sec¸˜ ao. A seguir, est˜ ao listados os segmentos da metamensagem utilizados e o detalhamento dos signos. 3.2.1 Segmento 1 “Eu criei um conjunto de componentes que podem ser utilizados para construir o ambiente(1), montar a rede de sensores(2) e criar est´ımulos(3) nessa rede.” Signos (1): •Valor da temperatura ambiente - Campo para digitar o valor, pois como os nossos usu´ arios entendem de computac¸˜ ao eles reconhecem um campo para digitar valores. Signos (2): •Agrupamentos de sensores - Representado por uma cor diferente para cada grupo, pois a diferenciac¸˜ ao de cor explicita a variedade. •Sensor - Representado pela imagem de um pequeno equipamento com antena. Quando o sensor estiver associado a um grupo, ele deve possuir algum ind´ ıcio disso, como possuir a cor do grupo ao qual est´ a associado. •Ativar uma ou m´ ultiplas operac¸ ˜ oes de sensor em andamento - Checkbox para ativac¸˜ ao/desativac¸˜ ao, pois como os nossos usu´ arios entendem de computac¸˜ ao eles reconhecem um Checkbox. •Parˆ ametros das operac¸ ˜ oes –Selec¸˜ ao da func¸˜ ao - Drop-down Box com as opc¸ ˜ oes “Alarme”, “M´ edia”, “Soma”, “M´ aximo” e “M´ ınimo”. Como os nossos usu´ arios entendem de computac¸˜ ao eles reconhecem um Drop-down Box. –Limite para alarme e Per´ ıodo de atualizac¸˜ ao da monitorac¸˜ ao - Campo para digitar o valor desses parˆ ametros, pois como os nossos usu´ arios entendem de computac¸˜ ao eles reconhecem um campo para digitar valores. Signos (3): •Gerador de calor - Representado pela imagem de uma chama, pois ´ e comum a ideia de fogo como gerador de calor. 5 Figura 11: Sele¸c˜ao das opera¸c˜oes da rede Figura 12: Sele¸c˜ao dos tipo de c´alculo da opera¸c˜ao Figura 13: Defini¸c˜ao do intervalo de opera¸c˜ao 12 Figura 14: Parˆametros adicionais Figura 15: Visualizando a mudan¸ca de temperatura Figura 16: Aproximando a chama de um sensor de alarme 13 Figura 17: Apresenta¸c˜ao dos resultados dos c´alculos 4 Implementac¸ ˜ ao Nessa sec¸˜ ao vamos apresentar os principais pontos da nossa implementac¸˜ ao. Comec¸amos com as facilidades e limitac¸ ˜ oes do AgentSheets para a implementac¸˜ ao dos nossos signos. Em seguida apresentamos a soluc¸˜ ao implementada. 4.1 Recursos do AgentSheets De forma geral o AgentSheets foi um facilitador para a implementac¸ ˜ ao da nossa ferramenta. Um dos principais motivos da facilitac¸˜ ao ´ e o fato do AgentSheets ser uma ferramenta para implementac¸˜ ao de pequenas simulac¸ ˜ oes interativas. Isso contribui positivamente, nossa aplicac¸˜ ao ´ e essencialmente uma simulac¸˜ ao. Outro motivo ´ e que o AgentSheets ´ e baseado no conceito de agentes que podem interagir numa ´ area de trabalho. A nossa ferramenta utiliza um conceito semelhante para os componentes que constituem um projeto em RSSF. E, finalmente, o AgentSheets disponibiliza algumas facilidades para implementar ac¸ ˜ oes e reac¸ ˜ oes simples como troca de imagens, movimentos, acionamentos (mouse e teclado), variac¸ ˜ oes de cores, e sons b´ asicos Apesar das facilidades do AgentSheets, nos deparamos com diversas restric¸ ˜ oes que dificultaram a implementac¸˜ ao de alguns signos, a seguir relacionamos algumas dessas restric¸ ˜ oes. •Galeria ´ unica de agentes - Os agentes adicionais de suporte (agentes que n˜ ao devem ser utilizados pelo usu´ ario do simulador) ficam dispon´ ıveis para o usu´ ario da ferramenta. Se o usu´ ario mexer com esses agentes, o simulador pode ter um comportamento inesperado. •Edic¸˜ ao em todo worksheet - O usu´ ario consegue editar toda a ´ area de trabalho, incluindo a ´ area de controle que n˜ ao deve ser alterada, correndo o risco de corromper todo o simulador. •Nenhuma facilidade para controles de entrada de dados e gerac¸˜ ao de texto - N˜ ao h´ a suporte para entrada e apresentac¸˜ ao de valores e textos •O tamanho dos agentes ´ e´ unico para todos os componentes - Todos os itens na interface devem ter o mesmo tamanho e resoluc¸˜ ao. •Agentes n˜ ao s˜ ao indiv´ ıduos - N˜ ao existe um suporte nativo para o programa identificar um agente espec´ ıfico no worksheet. 14 •N˜ ao h´ a suporte para comunicac¸˜ ao parametrizada entre agentes - Um agente pode disparar m´ etodos em outros agentes, mas de forma broadcast sem nenhum filtro ou parˆ ametro. Como soluc¸˜ ao de contorno ` as limitac¸ ˜ oes acima, tivemos que: •Criar identificadores para cada agente - Definimos um forma de criar identificadores individuais baseados na posic¸˜ ao relativa dos agentes ou na ordem de criac¸˜ ao na worksheet. •Criar vari´ aveis globais para intercomunicac¸ ˜ ao entre agentes - Utilizamos vari´ aveis globais para intercomunicac¸˜ ao entre agentes. •Criar eventos (m´ etodos) de controle entre agentes - Definimos um conjunto de m´ etodos, que combinados com as vari´ aveis globais, pudessem resolver alguns problemas de intercomunicac¸˜ ao entre indiv´ ıduos. •Criar um agente que centralizasse algumas atividades de controle. •Criar um agente improvisado para exibir valores num´ ericos. •Criar um agente improvisado para aumentar e diminuir valores em substituic¸˜ ao ao controle de entrada de dados pelo teclado. •Criar um agente improvisado para “checkbox”. 4.2 Vers˜ ao implementada Na figura 18 apresentamos a vers˜ ao atual da interface implementada no AgentSheets. Esta vers˜ ao reflete as dificuldades encontradas para representar alguns signos definidos na sec¸˜ ao 3.3. Em seguida, descrevemos como ficou a operac¸ ˜ ao de alguns controles da interface. Descric¸˜ ao dos controles utilizados: Exibi¸c˜ao de valor - Montamos uma complicada combinac¸˜ ao entre tipo de agente e posic¸˜ ao do agente para representar um valor num´ erico de uma vari´ avel global. Checkbox - Reflete o funcionamento convencional de um controle checkbox. Entrada de valores - N˜ ao conseguimos criar um campo edit´ avel para que o usu´ ario pudesse digitar o valor desejado. A nossa implementac¸˜ ao prevˆ e que o usu´ ario selecione um controle com o ponteiro do mouse e em seguida com as teclas de setas do teclado incremente ou decremente o valor exibido. Aloca¸c˜ao, movimenta¸c˜ao e remo¸c˜ao de componentes - Mantivemos os mesmos controle do AgentSheets. 5 Avaliac¸ ˜ ao do trabalho Vamos separar nossa avaliac¸ ˜ ao em em duas partes, primeiro apresentaremos as consequˆ encias das dificuldades encontradas na implementac¸˜ ao e em seguida resumimos a nossa avaliac¸˜ ao. 15 Figura 18: Interface implementada no AgentSheets 5.1 Consequˆ encias da dificuldade de implementac¸ ˜ ao Podemos dividir o impacto da dificuldade de implementac¸˜ ao em dois grupos. O primeiro grupo identifica alguns pontos diretamente relacionados com a atividade de implementac¸˜ ao. O segundo grupo lista os principais impactos na comunicac¸˜ ao desejada. 5.1.1 Consequˆ encias na implementac¸ ˜ ao •Interface de desenvolvimento do AgentSheets n˜ ao d´ a nenhum suporte para programac¸˜ ao avanc¸ada e mais complexa. •Especificac¸˜ ao manual de todas vari´ aveis e m´ etodos - Para manter a consistˆ encia e evitar erros foi necess´ ario manter um controle externo ao AgentSheets de todas vari´ aveis e m´ etodos criados. •Controles de manipulac¸˜ ao e entrada de dados n˜ ao compat´ ıvel com a definic¸˜ ao dos signos - A nossa implementac¸˜ ao para os controles de interface n˜ ao conseguiu atender aos requisitos da especificac¸˜ ao. •Tamanho ´ unico para todos agentes dificulta a representac¸˜ ao dos signos - A restric¸˜ ao do tamanho dos agentes n˜ ao permitiu representar adequadamente v´ arios signos. •Layout da interface n˜ ao segue o desenho planejado - Como consequˆ encia geral a interface implementada n˜ ao reflete a interface especificada. 5.1.2 Consequˆ encias na comunicac¸ ˜ ao Descrevemos as consequˆ encias na comunicac¸˜ ao de alguns problemas na implementac¸˜ ao do simulador atrav´ es das mensagens equivocadas que podem ser transmitidas ao usu´ ario atrav´ es da metacomunicac¸˜ ao, que foi o que regeu todo o trabalho realizado. 16 •Ferramenta de edic¸˜ ao ´ e global e galeria ´ unica de agentes –“Vocˆ e pode reconfigurar todos os aspectos do simulador, incluindo o painel de controle.” •Agrupamento dos elementos no painel de controle –“Para o simulador, n˜ ao h´ a diferenc¸as entre as vari´ aveis de ambiente (como a temperatura ambiente) e os parˆ ametros das operac¸ ˜ oes da rede.” •Resultados das operac¸ ˜ oes s˜ ao sempre num´ ericos –“Como o ‘0’ e ‘1’ para alarmes pode parecer estranho, criei um est´ ımulo visual para que vocˆ e saiba quando o alarme estiver ligado.” –“Atenc¸˜ ao, pois a qualquer momento, o alarme pode ser disparado.” •Os parˆ ametros de todas as operac¸ ˜ oes s˜ ao os mesmos –“Vocˆ e pode configurar uma temperatura que ir´ a disparar o alarme em qualquer tipo de operac¸˜ ao.” –“Qualquer operac¸˜ ao pode disparar um alarme.” 5.2 Avaliac¸ ˜ ao Nossa avaliac¸˜ ao est´ a dividida em duas partes. Na primeira consideramos o processo de definic¸˜ ao da ferramenta utilizando conceitos da Engenharia Semi´ otica. Na segunda parte avaliamos a utilizac¸˜ ao do AgentSheets como plataforma de desenvolvimento para a nossa ferramenta de simulac¸˜ ao. 5.2.1 Utilizac¸ ˜ ao da Engenharia Semi ´ otica A utilizac¸˜ ao de conceitos da Engenharia Semi´ otica contribuiu positivamente na definic¸˜ ao da nossa ferramenta. A utilizac¸˜ ao do template de metacomunicac¸˜ ao e o devido detalhamento da metamensagem em signos foi fundamental para um bom desenho de interface. O exec´ ıcio de verificar se um signo realmente comunicava a nossa intenc¸ ˜ ao original tamb´ em foi muito importante no processo de refinamento da definic¸˜ ao dos signos e da definic¸˜ ao da interface. Com isso foi poss´ ıvel verificar alguns itens que normalmente passariam desapercebidos num processo convencional de especificac¸˜ ao. Por ´ ultimo ressaltamos que a definic¸˜ ao original do nosso problema foi melhorada ap´ os o processo de definic¸˜ ao da nossa intenc¸˜ ao de comunicac¸˜ ao. 5.2.2 Implementac¸ ˜ ao no AgentSheets A limitac¸˜ ao de recursos no AgentSheets para o que quer´ ıamos fazer resultou em: •Problemas na comunicac¸˜ ao –A implementac¸˜ ao do simulador no AgentSheets criou novas mensagens que, n˜ ao s´ o n˜ ao foram previstas na criac¸˜ ao da proposta da interface, como tamb´ em, n˜ ao deviam existir. Por exemplo: a mensagem que diz que o usu´ ario pode editar o painel de controle do simulador. 17 –A dificuldade de se implementar uma metalinguagem no AgentSheets empobreceu as possibilidades de comunicac¸ ˜ ao com o usu´ ario. Os recursos de galeria, edic¸˜ ao e configurac¸˜ ao n˜ ao puderam ser refletidos na interface da mesma forma que ´ e disponibilizado para o desenvolvedor. •Aumento no esforc¸o de implementac¸˜ ao –Falta de recursos para operac¸ ˜ oes mais complexas - Alguns signos que dependiam de operac¸ ˜ oes mais complexas n˜ ao puderam ser representados, por exemplo a comunicac¸˜ ao entre agentes espec´ ıficos ou parametrizac¸˜ ao individual de um agente ap´ os a inserc¸˜ ao na worksheet. –Falta de suporte de validac¸˜ ao de c´ odigo - N˜ ao existe nenhuma facilidade para validac¸˜ ao das vari´ aveis locais, vari´ aveis globais e dos m´ etodos entre agentes. –Falta de suporte para depurac¸˜ ao - N˜ ao exite nenhum suporte auxiliar para depurac¸˜ ao do c´ odigo durante execuc¸˜ ao. Existe somente a possibilidade de visualizar e alterar o conte´ udo das vari´ aveis globais e de um agente selecionado. –Esforc¸o grande para resolver problemas simples - N˜ ao existem alguns signos normalmente disponibilizados em sistemas de interfaces. ´ E necess´ ario grande esforc¸o de desenvolvimento das soluc¸ ˜ oes de contorno que representem esses signos. Por exemplo, n˜ ao existe facilidades para representac¸˜ ao num´ erica ou entrada de dados durante a execuc¸˜ ao da simulac¸˜ ao. 6 Conclus˜ ao e trabalhos futuros Neste trabalho avaliamos a aplicac¸˜ ao de conceitos da Engenharia Semi´ otica na definic¸˜ ao de uma ferramenta de simulac¸˜ ao. Adicionalmente avaliamos o AgentSheets como plataforma para desenvolvimento dessa ferramenta. A utilizac¸˜ ao do template de metacomunicac¸˜ ao e a respectiva definic¸˜ ao dos signos serviram como base para a definic¸˜ ao da ferramenta. A definic¸˜ ao da interface baseada nesses signos possibilitou um processo de autoavaliac¸˜ ao constante que foi fundamental para o refinamento do desenho final. Identificamos algumas vantagens e desvantagens em relac¸˜ ao a utilizac¸˜ ao do AgentSheets como plataforma de desenvolvimento. A principal vantagem est´ a associada ao modelo de programac¸˜ ao do AgentSheets, esse modelo facilita a implementac¸˜ ao de aplicac¸ ˜ oes para pequenos jogos e simulac¸˜ ao. Por outro lado n˜ ao foi poss´ ıvel usar o modelo de programac¸˜ ao do AgentSheets como uma metalinguagem, dificultando dessa forma a disponibilizac¸˜ ao para o usu´ ario de recursos importantes que est˜ ao dispon´ ıveis para o desenvolvedor. O AgentSheets tamb´ em n˜ ao oferece recursos t´ ıpicos de outros modelos de programac¸˜ ao que auxiliem na tarefa de configurac¸˜ ao e programac¸˜ ao. Seria interessante aplicar o M´ etodo de Avaliac¸˜ ao de Comunicabilidade para ver como o usu´ ario recebe nossa mensagem e comparar esse resultado com a metamensagem que criamos. Por´ em, podemos nos adiantar e levantar a hip´ otese de que n´ os n˜ ao conseguimos atingir com total sucesso nossa meta de criar um simulador que auxilie no ensino de conceitos de RSSF, devido aos v´ arios problemas de comunicabilidade que surgiram durante a implementac¸˜ ao e foram descritos anteriormente. Sendo assim, a princ´ ıpio, podemos dizer que o AgentSheets n˜ ao demonstrou ser a ferramenta mais adequada para a construc¸˜ ao de um simulador dado o contexto que regeu este trabalho. Como trabalho futuro, em cima da soluc¸˜ ao atual, podemos investir mais tempo para refinar a implementac¸˜ ao e ficar mais pr´ oxima da Interface Proposta. 18 Uma outra linha que pode ser seguida ´ e a avaliac¸˜ ao do comportamento de outros modelos de programac¸˜ ao utilizando o processo baseado em Metamensagem e Signos da Engenharia Semi´ otica. Isto ´ e, especificar uma aplicac¸˜ ao utilizando o processo de definic¸˜ ao da Engenharia Semi´ otica e avaliar os pontos positivos e negativos ao implementarmos essa aplicac¸˜ ao com diferentes modelos de programac¸˜ ao. 19 Referˆ encias [1] MOTTOLA, L.; PICCO, G. P.. Programming wireless sensor networks: Fundamental concepts and state-of-the-art. Tech. rep., University of Trento, 2010. [2] REPENNING, A.; IOANNIDOU, A.. Agent-based end-user development. Commun. ACM, 47:43–46, September 2004. [3] DE SOUZA, C. S.. Semiotic engineering: bringing designers and users together at interaction time. Interacting with Computers, 17(3):317 – 341, 2005. Special Theme - Papers from Members of the Editorial Boards. [4] SOUZA, C. S. D.. The Semiotic Engineering of Human-Computer Interaction (Acting with Technology). The MIT Press, 2005. [5] PEIRCE, C.. The essential Peirce: Selected Philosophical Writings, volumen 2, 18931913. Indiana University Press, Bloomington, IN, 1998. [6] DE SOUZA, C. S.; LEIT ˜ AO, C. F.; PRATES, R. O. ; DA SILVA, E. J.. The semiotic inspection method. In: PROCEEDINGS OF VII BRAZILIAN SYMPOSIUM ON HUMAN FACTORS IN COMPUTING SYSTEMS, IHC ’06, p. 148–157, New York, NY, USA, 2006. ACM. [7] PRATES, R. O.; DE SOUZA, C. S. ; BARBOSA, S. D. J.. Methods and tools: a method for evaluating the communicability of user interfaces. interactions, 7:31–38, January 2000. [8] SOHRABY, K.; MINOLI, D. ; ZNATI, T.. Wireless Sensor Networks: Technology, Protocols, and Applications. Wiley-Interscience, 2007. [9] FERREIRA, J.; BARR, P. ; NOBLE, J.. The semiotics of user interface redesign. In: PROCEEDINGS OF THE SIXTH AUSTRALASIAN CONFERENCE ON USER INTERFACE - VOLUME 40, AUIC ’05, p. 47–53, Darlinghurst, Australia, Australia, 2005. Australian Computer Society, Inc. 20