SIRC 2012 XI SIMPÓSIO DE INFORMÁTICA DA UNIFRA

Transcrição

1 SIRC 2012 XI SIMPÓSIO DE INFORMÁTICA DA UNIFRA 23 a 25 de Outubro de 2012 Realização: Apoio: Patrocínio:

2 Coordenação Geral Tiago Rios da Rocha Comissão Organizadora Alessandro André Mainardi de Oliveira Alexandre de O. Zamberlan Ana Paula Canal Guilherme C. Kurtz Gustavo Cantarelli Henrique Gabriel Gularte Pereira Mirkos Ortiz Martins Reiner F. Perozzo Ricardo G. Martini Simone Regina Ceolin Sylvio Vieira Tiago Rios da Rocha Comissão Avaliadora Dr. Afonso Sales (UFRGS) Dr. Alvaro Miyazawa (University of York) Dr. Antonio Schneider Beck Filho (UFRGS) Dr. André Cordenonsi (UFSM) Ms. Célio Trois (UFSM) Dr. Edson Prestes (UFRGS) Dr. Eugenio Simonetto (UFSM) Dr. Felipe Meneguzzi (PUCRS) Dr. Giovani Librelotto (UFSM) Dra. Giliane Bernardi (UFSM) Ms. Guilherme Dhein (UFSM) Dr. José Eduardo Bágio (UFSM) Dra. Juliana Vizotto (UFSM) Dr. Leandro Indrusiak (University of York) Dr. Leonardo Freitas (University of Newcastle) Dr. Leonardo Brenner (Université de Reims Champagne-Ardene) Dra. Leila Ribeiro (UFRGS) Dra. Lizandra Manzoni Fontoura (UFSM) Dr. Luis Alvaro de Lima e Silva (UFSM) Dr. Luciano Ost (IRMM) Ms. Marcos Cassal (UFSM) Dr. Mateus Beck (UFSM) Dr. Osmar Marchi dos Santos (UFSM) Ms. Pryscilla Dora Selister (UFCG) Dr. Ricardo Czekster (PUCRS) Ms. Rogério Turchetti (UFSM) Dra. Thais Webber (PUCRS) Ms. Walter Priesnitz Filho (UFSM)

3 Análise do Gerenciamento de Transações Concorrentes no SGBD Firebird.com Daniel Pezzi da Cunha * * CCAET Universidade de Cruz Alta (UNICRUZ) Cruz Alta RS Brasil danielpezzi@gmail.com Abstract. The use of database organizations, especially those that handle large size information, has direct to new challenges and therefore the improvement of data management techniques. However, many database administrators are faced with complaints about the failures occurrence in operations and the low performance of databases. This paper outlines the results of study on the transactional handling DBMS Firebird and critical analysis of the impact attributions imposed on transactions concurrency situations. Resumo. O uso de banco de dados pelas organizações, especialmente aquelas que manipulam grandes volumes de informações, tem conduzido a novos desafios e, por conseguinte, ao aperfeiçoamento das técnicas de gerenciamento de dados. No entanto, muitos administradores de bancos de dados se deparam com reclamações acerca da ocorrência de falhas em operações e do baixo desempenho de bancos de dados. Neste artigo são expostos os resultados de uma pesquisa sobre o controle transacional do SGBD Firebird e análise crítica do impacto das atribuições impostas a transações mediante situações de concorrência. 1. Introdução O uso de banco de dados pelas organizações, especialmente aquelas que manipulam grandes volumes de informações, tem conduzido a novos desafios e, por conseguinte, ao aperfeiçoamento das técnicas de gerenciamento de dados (Silberschatz et al, 1999; Elmasri & Navathe, 2011). No entanto, muitos administradores de bancos de dados (DBA) recebem reclamações acerca da ocorrência de falhas em operações e, consequentemente, do baixo desempenho de bancos de dados. Muitas vezes persistem questionamentos quanto a capacidade de controle do DBA e os reflexos de configurações consideradas rígidas na eficácia geral de um Sistema Gerenciador de Banco de Dados (SGBD). A aplicação adequada do controle sobre transações em banco de dados é de suma importância, uma vez que possibilita a potencialização das ações ACID 1 comumente praticadas nas camadas de gerenciamento dos SGBD distribuídos (Ozsu & Valduriez, 1999). O conhecimento e controle por parte de um DBA pode trazer diversos benefícios como a manutenção da estabilidade dos sistemas de informação em 1 ACID: Atomicidade, Consistência, Isolamento e Durabilidade 3

4 detrimento de transações concorrentes e, sobretudo, na garantia da consistência dos dados. Por outro lado, pode conduzir a severas consequências em caso de uso incorreto ou inadequado. Neste artigo são expostos os resultados de uma pesquisa acerca do controle transacional do SGBD Firebird, Software Livre amplamente difundido em sistemas de informações corporativos. A pesquisa também envolveu o desenvolvimento de um aplicativo educacional, distribuído livremente, que pode ser adotado como ferramenta complementar no ensino superior, especialmente na disciplina de Banco de Dados. Em termos científicos foi realizada uma análise crítica do impacto das atribuições impostas a transações mediante situações de concorrência. 2. Controle de concorrência no Firebird O controle de concorrência no SGBD Firebird, segundo Firebird (2012) - Transaction Handling 2 - tem a finalidade de assegurar a coerência do banco de dados, baseando-se nas propriedades ACID, a partir da configuração de parâmetros, que afetam a simultaneidade das transações. Os quatro parâmetros existentes são: isolation level, lock resolution mode, access mode e table reservation. DevMedia (2006) complementa que a arquitetura do Firebird e Intebase é do tipo versioning, cuja abordagem obriga que qualquer operação em banco de dados, incluindo consultas, seja transacional. No Firebird adota-se a Multi Generational Architecture (MGA), que armazena as alterações diretamente no banco de dados, juntamente com informações para reverter ao estado original (backversions), dispensando log de transações. Com isso, versões temporárias de dados modificados são criadas e permanecem ativas, permitindo que fiquem acessíveis com seu conteúdo original a outras transações, de maneira consistente (Vinkenoog 2012). Os backversions são criados na execução de update ou delete. Um mesmo registro pode ter diferentes versões, sendo que cada nova versão contém um link apontando para a anterior, formando uma cadeia de versões. Em caso de rollback o começo se dará pela versão mais recente (Cantu, 2005). Como no Firebird o controle transacional é feito pela aplicação cliente, não há como iniciar ou encerrar uma transação a partir de triggers ou stored procedures. Na ocorrência de algum conflito transacional o Firebird gera deadlock, o qual pode ser identificado por uma aplicação cliente, que tomará as providências necessárias e notificar ao usuário da ocorrência de uma falha. 3. Estudo de caso A aplicação prática dos conceitos teóricos relativos a controle transacional foi realizada sobre a base de dados Matriculas, criada apenas para o propósito da realização de testes experimentais (de carga e de controle transacional). Com o propósito da realização de testes quantitativos na base de dados Matriculas foi desenvolvido, na linguagem Delphi, um protótipo intitulado Database Charge Test, o qual foi disponibilizado livremente para o propósito de ensino em 2 Transaction Handling está disponível em 4

5 A partir deste aplicativo foram realizadas variadas baterias de testes, dentre os quais a inclusão de 100 mil tuplas por tabela, com dados aleatórios, com emprego do Firebird 2.5 (32bits) e 2.0 (64bits) para Windows. Além do sistema Database Charge Teste, optou-se por utilizar a ferramenta IBExpert 3 (da HK-Software) para as configurações DDL na base de dados e a ferramenta gráfica de monitoramento chamada Sinática Monitor For Firebird 4 (da Sinática), que possibilitou o acompanhamento dinâmico das transações. Quanto aos computadores utilizados nos testes práticos, optou-se por um desktop típico de escritório, configurado com Windows XP 32bits, CPU Intel Celeron 1,8GHz e 2GB de memória e um laptop com Windows Seven 64bits, AMD Turion X2 DualCore Mobile 2,1 GHz e 4GB de Memória Principal. 4. Resultados das experimentações práticas Nas simulações práticas, o banco de dados foi colocado a prova com execução simultânea de múltiplos update e delete de usuários com papéis (roles) diferenciados. A configuração do banco de dados ocorreu em tempo de execução, por meio do Firebird ISQL Tool (console disponível junto à instalação do Firebird), mediante a execução intensa de transações a partir do Database Charge Test. A seguir são descritas as linhas de comando aplicadas a base de dados Matriculas e os respectivos resultados obtidos conforme cada tipo de controle transacional disponível no banco de dados analisado: Tentativa de dirty read Configuração da transação: set transaction read write isolation level read uncommitted; O modo read uncommitted enquadra-se no tipo chamado dirty read (ou leitura suja ), o qual permite que uma transação faça leituras de todas as modificações realizadas por outra transação, mesmo que estas não tenham sido confirmadas. No teste prático foi executada uma sequência de updates (t1) não confirmadas. Mesmo com o modo read uncommitted ativado não foi possível fazer leituras dirty read. Assim, foi necessário o término da transação (commit) para que o comando de leitura retornasse um resultado com os valores modificados por t1. Mesmo que, em teoria o Firebird ofereça Arquitetura Multigeracional, não suporta este nível de isolamento, restringindose ao protocolo conservador. Modo no wait Configuração da transação: set transaction read write isolation level read committed no record_version no wait; A função record_version é um sub-modo de read commited, onde a última versão confirmada de uma determinada tupla pode ser lida imediatamente. Na opção no 3 IBExpert é disponibilizada nas versões free, trial e customer em 4 Sinática Monitor é disponibilizada na versão trial em 5

6 record_version pode-se optar pelo tipo bloqueio no wait, o qual não esperará até que uma transação não confirmada alcance o status de concluída. Nos testes práticos, na tentativa de leitura de determinada tupla que estava com uma transação update não confirmada em andamento, o Firebird retornou imediatamente um erro do tipo deadlock, negando acesso ao conteúdo solicitado. No entanto, outro teste mostrou que não apenas a tupla em modificação é bloqueada, mas sim todos os demais registros da tabela, mesmo que estes não estejam sob efeito de qualquer transação. Configuração de lock timeout Ao se atribuir o modo wait para uma transação, esta não conseguirá obter resultados em consultas até que as transações update e delete tenham sido concluídas (committed) por outras transações. Configuração da transação: set transaction read write isolation level read committed no record_version wait lock timeout 10; Uma forma de evitar que uma consulta fique por muito tempo (talvez indeterminado) em modo de espera aguardando um commit de outra transação é pela atribuição de um timeout. Dessa forma, uma consulta ficará em modo de espera (wait) até um tempo, em segundos, determinado. No experimento prático foi definido um prazo de 10 segundos. Após a conclusão desse período, o Firebird retornou um erro, que pode ser mapeado e tratado pela interface. Modo snapshot Configuração da transação: set transaction read write isolation level snapshot table stability; O modo snapshot permite que uma transação obtenha uma imagem completa dos registros de uma base de dados e incapacita o acesso a possíveis modificações nos dados feitas por transações concorrentes. Este nível de isolamento tem aplicabilidade em relatórios onde se queira fazer avaliações repetitivas sobre os dados armazenados em um determinado instante de tempo. No experimento prático desta pesquisa também foi testada a configuração table stability, a qual, além da propriedade do snapshot citada, impede que outras transações realizem operações de escrita. Este nível de isolamento não é adequado para situações de uso habitual, mas sim em fase de prototipação de sistemas ou em curtos e isolados períodos de tempo, uma vez que causaria erros de escrita em cascata para usuários finais. Pré-alocação Configuração da transação: set transaction isolation level read committed reserving alunos for protected write; A condição de pré-alocação, atribuída por meio do modo reserving, possibilita a definição dos níveis de isolamento shared ou protected para tabelas em bancos de dados. No nível compartilhada (shared) uma ou mais tabelas (especificadas pelo usuário) podem ser compartilhadas entre transações. Já no nível protegida (protected), 6

7 são bloqueadas para outras transações. Em ambas é preciso definir o tipo de préalocação: escrita (write) ou leitura (read). O bloqueio de uma ou mais tabelas ocorre de maneira que somente a transação que o ativou possa executar determinadas operações. Nos testes práticos a tabela Alunos foi colocada em processo contínuo de múltiplas e diferenciadas modificações. Em determinado momento, com as operações update em andamento, foi atribuído o nível de isolamento protegido, o qual interrompeu momentaneamente as transações update. As operações foram automaticamente reativadas mediante o comando: set transaction isolation level read committed reserving alunos for shared write; 5. Conclusões Em muitas ocasiões as reclamações de lentidão com o Firebird estão relacionadas com o controle incorreto das transações (ou falta dele). No entanto, o mecanismo de gerenciamento de transações do SGBD Firebird oferece uma gama de funcionalidades importantes que podem oferecer um bom nível de controle de consistência se aplicado adequadamente. O Firebird emprega de forma padrão o nível de isolamento read committed wait, ou seja, caso uma transação ocorra enquanto existe uma modificação não confirmada, o mesmo irá aguardar até a ocorrência de um commit ou rollback. Em consequência, o usuário final poderá ficar por um longo período sem obter os dados solicitados por uma consulta. Nesse caso é de suma importância a implementação de um timeout em transações para evitar casos de inanição de aplicações. Dentre as constatações desta pesquisa, destaca-se quanto ao bloqueio causado pelo sub-modo record_version no wait, uma vez que não apenas a tupla em situação de modificação é bloqueada para consultas, mas sim todos os demais registros da tabela, mesmo que estes não estejam sob efeito de qualquer transação. A não espera até que uma transação não confirmada alcance o status de concluída é uma configuração benéfica para manter um bom nível de escalonamento. Entretanto, o bloqueio integral da tabela (constatado neste experimento) pode ser considerado um problema, pois impediria inúmeros acessos a itens de dados que não incorreriam na perda da garantida de manutenção das propriedades ACID do banco de dados. Por consequência, essa condição poderia ainda comprometer significativamente o funcionamento de um sistema de informação que produza múltiplas ações a partir de uma única solicitação de usuário. Outro ponto analisado foi a ativação do modo wait para uma transação. Isso pode ser de grande valia, principalmente para evitar o acesso a dados inválidos oriundos de modificações nos dados. Contudo, pode acarretar uma situação de inanição, mantendo uma transação ativa por um período de tempo indeterminado. Uma alternativa para minimizar seu efeito bloqueante é optar pela inclusão de um tempo de espera finito (timeout), assim garantiria uma melhor interação entre o banco de dados e a interface de um aplicativo. Quanto ao recurso snapshot, amplamente empregado por administradores de bancos de dados, é um instrumento útil para situações onde seja preciso a geração de relatórios parciais. Mas, caso seja constatado a existência de algum problema nos dados durante uma inspeção periódica, como por exemplo, a observação de que um produto a 7

8 venda esteja com validade vencida, o usuário não teria controle sobre possíveis modificações desde a geração da imagem da base de dados pelo snapshot até a constatação de erro nos dados. Nesse caso, seria oportuna a ativação conjunta do modo table stability, que causaria situações de deadlock devido ao bloqueio de modificações, mas que poderia evitar danos ainda maiores, como a compra desse produto em situação irregular por diversos consumidores. No quesito de teste de pré-alocação, constatou-se que o Firebird se comportou de maneira estável e confiável, garantindo um controle de concorrência satisfatório em uma condição de séries intensas de operações de escrita. Em termos práticos, pode-se afirmar que o emprego de pré-alocação em sistemas corporativos dinâmicos, como sites com inúmeros acessos a base de dados pode ser muito importante para se obter controle transacional. Cabe salientar que o uso desse tipo de ação precisa restringir-se a situações especiais, uma vez que pode acarretar em desfazimentos de transações em cascata. Por fim, conclui-se que o SGDB Firebird possibilita um bom controle transacional, atingindo as expectativas iniciais da pesquisa. Dispõe dos principais mecanismos necessários ao gerenciamento de operações, é estável e com critérios rígidos de manutenção da consistência. No entanto, seria conveniente o aprimoramento do seu módulo de controle de concorrência para torná-lo mais flexível, de modo que os bloqueios, que são abrangentes, se tornem mais restritos quanto a itens de dados, aumentando assim a granularidade da concorrência entre as transações nesse importante e difundido banco de dados. Referências Cantu, Carlos H. (2005). Firebird Essencial. Rio de Janeiro: Ciência Moderna, 1ª edição. Devmedia. (2006). Transações no Firebird & Interbase. DevMedia: Revista Clube Delphi, 42ª edição. Elmasri, Ramez; Navathe, Shamkant B. (2011). Sistemas de Banco de Dados. São Paulo: Pearson Addison Wesley, 6ª edição. Fernandes, Adriano dos Santos. (2011). ClubeDelphi 125: CODESIT. DevMedia: Revista Clube Delphi, 125ª edição. Firebird. (2012). Reference Manuals. Disponível em: < Acesso em 18 de abril de Holanda, Maristela; Brayner, Angelo; Fialho, Sergio. (2006). EIT - Escalonador Inteligente de Transações. XXI Simpósio Brasileiro de Banco de Dados, Florianópolis. Ozsu, M. T.; Valduriez, P. (1999). Principles of Distributed Database Systems. Prentice-Hall, 1ª edição. Silberschatz, Abrahan; Korth, Henry F.; Sudarshan, S. (1999). Sistemas de Banco de Dados. São Paulo: Makron Books, 3ª edição. Vinkenoog, Paul; et al. (2011). Firebird 2.5 Language Reference Update. Disponível em: < Acesso em 18 de abril de

9 Computação Consciente do Contexto: um estudo sobre técnicas de Computação Pervasiva aplicada ao desenvolvimento de um Controlador Lógico Programável Djalmo Etiene Cardinal, Patricia Mariotto Mozzaquatro, Rodrigo Luiz Antoniazzi 1 Universidade de Cruz Alta (UNICRUZ) Campus Universitário Dr. Ulysses Guimarães - Rodovia Municipal Jacob Della Méa, Km Parada Benito - CEP Cruz Alta/RS Brazil djalmoec@terra.com.br, patriciamozzaquatro@gmail.com, rodrigoantoniazzi@yahoo.com.br Abstract. There are many homes that have some kind of automation, and an environment totally controlled by their owners, where everyday tasks, and generate confusion and forgetfulness about their drives, can cause potential waste. The comfort, as well as the security of these environments often leaves something to be desired with existing projects and consequently exposes residents or workers to unnecessary risks. The Programmable Logic Controllers (PLC) systems integrating aware of the context can be used in solving these problems. The work proposed was the development of a programmable logic controller aware of the context that captures data from various sensors generating a unique information to the user. We used context sensors, a microcontroller with RISC architecture and organization as defined HARVARD, thus, allows collecting information captured by different sensors generating a fully integrated system. Resumo. Existem muitas residências que possuem uma espécie de automação, sendo um ambiente totalmente controlado por seus proprietários, onde as tarefas diárias, além de gerar confusões e esquecimentos quanto a seus acionamentos, podem acarretar possíveis desperdícios. O conforto, assim como a segurança destes ambientes muitas vezes deixa a desejar com os projetos existentes e, consequentemente expõe os moradores ou trabalhadores a riscos desnecessários. Os Controladores Lógicos Programáveis (CLP) integrando sistemas conscientes do contexto podem ser utilizados na resolução destes problemas. O trabalho de proposto apresentou o desenvolvimento de um controlador lógico programável consciente do contexto que captura dados de diversos sensores gerando uma única informação ao usuário. Foram utilizados sensores de contexto, um micro controlador com arquitetura RISC e organização definida como HARVARD, para assim, permitir a obtenção de informações capturadas pelos diferentes sensores gerando um sistema totalmente integrado. 1. Introdução O surgimento de novas tecnologias aumenta a complexidade dos ambientes e, neste sentido, os mesmos necessitam adaptar-se a uma computação altamente dinâmica, onde 9

10 o ambiente está em constante mudança em função da mobilidade do usuário. Assim, abriu-se espaço ao surgimento de um novo paradigma computacional: a computação pervasiva, disponibilizando acesso à computação de forma natural ou invisível (sem a necessidade de ações conscientes para essa finalidade), em todo lugar e tempo (SAHA, 2003). A computação pervasiva se propõe a dar uma visão do futuro onde serviços serão oferecidos para os usuários através de inúmeros dispositivos espalhados pelo ambiente. A criação de uma rede onde dispositivos se comunicam dando estados do contexto esta se tornando popular. Segundo (SAHA, 2003) um dos principais desafios da Computação Consciente do Contexto é interpretar a grande quantidade de informações disponíveis e conseguir determinar ações a partir da interpretação dessas informações integrando-as e, apresentando uma única resposta. Pode-se, além disso, combinar informações provenientes de diferentes fontes (sensores) e fundi-las em uma nova informação com mais significado agregado. Neste contexto, o desenvolvimento de um Controlador Lógico Programável consciente do contexto que captura dados de diversos sensores gerando uma única informação ao usuário poderá possibilitar a obtenção de informações capturadas pelos diferentes sensores gerando um sistema totalmente integrado. 2. Controlador Lógico Programável (CLP) Nos anos 60 e 70, clientes que tinham certo desejo por um automóvel em uma cor específica eram obrigados a esperar longos períodos, para serem atendidos pelo motivo de que os carros eram produzidos em safras pelas montadoras. O tempo do setup de uma linha de produção tinha um custo muito elevado porque as fábricas daquela época não haviam sido projetadas para serem flexíveis devido às limitações da tecnologia de automação (FAUSTINO, 2005). Diante desta limitação, em 1968, foram definidas várias especificações para o desenvolvimento do primeiro controlador programável: facilidade de programação e reprogramação, facilidade de manutenção e reparos, capacidade de operação em ambientes industriais. Segundo SILVEIRA et.al. (2002), no Brasil os CLPs se expandiram a partir dos anos 80 por causa da adoção da tecnologia usada nas matrizes das indústrias multinacionais. O mesmo autor complementa que na construção de um CLP é necessário ter uma estrutura básica para suas funcionalidades serem reconhecidas e aplicadas a um contexto especifico, onde são elas: 1-Necessitando de um fonte de alimentação onde converte a tensão da rede de 110 ou 220 V de corrente alternada denominada VCA em +5V, +12V ou +24V de corrente continua denominada VCC, para alimentação dos circuitos, entradas e saídas; 2- Unidade de processamento também conhecida de Central Processing Unit (CPU), onde pode se usar micro controladores ou microprocessadores; 3- Bateria para utilização do circuito, dando autonomia para ficar acionado sem a energia da rede; 4- Memória do programa supervisor onde é responsável pelo gerenciamento do CLP, não podendo ser modificado pelo usuário e fica normalmente em memórias do tipo Programable read-only memory (PROM), Erasable Programmable read-only memory (EPROM) e Electrically Erasable Programmble Read-only Memory (EEPROM); 5- Memória para o usuário constituída pela memória Random Access Memory (RAM) ou EEPROM. 10

11 2.1. Microprocessador, Sensores e Atuadores Os micros controladores são chips inteligentes, que tem um processador, pinos de entradas/saídas e memória. Programando o micro controlador tem-se o controle de suas saídas/entradas. O que diferencia os diversos modelos de micro controladores é a quantidade de memória interna tanto para dados ou programa, velocidade do seu processamento, quantidades de pinos de entradas e saídas, alimentação, periféricos que pode se utilizar (PEREIRA, 2010). A série dos micro controladores PIC18 é derivada da série PIC17. Tanto os PIC18 quanto os PIC17 são micro controladores que residem no fato de utilizarem uma organização interna conhecida como Harvard. Onde caracteriza se por utilizar barramentos distintos para acesso à memória de programa e a memória de dados (PEREIRA, 2010). O funcionamento de um sensor é realizado sob a atuação de uma grandeza física que altera as propriedades do dispositivo, como uma resistência, capacitância ou a indutância. Este gera informações de acordo com essas alterações que serão levadas ao CLP para tratá-las (NATALE, 2003). O sensor de presença é um comando inteligente que se destina ao acionamento de cargas temporizadas, a função do sensor é fazer detecções de fontes de calor como pessoas e carros, através de um sensor infravermelho, acionando a carga e desligando-a após a ausência, de acordo com o tempo programa no sistema do sensor (ALIEVI, 2008). Os atuadores têm por função converter os sinais elétricos provenientes das saídas do CLP em uma condição física, normalmente ligando ou desligando algum elemento. Um exemplo básico de seu funcionamento é o controle do acionamento de uma bobina contatora a qual comandará o acionamento de um motor, através de uma saída do CLP (FRANCHI et.al., 2008). Os contatores/relés são normalmente equipados com três, quatro ou cinco contatos, podendo ser de força, auxiliares ou mistos, além disso, em muitos modelos de contatores ainda é possível acrescentar blocos de contatos auxiliares aumentando o número de contatos auxiliares disponíveis (FRANCHI et.al., 2008) Protocolo de Comunicação Modbus A interface escolhida para o desenvolvimento deste projeto é o padrão RS-232, Modbus é um protocolo de comunicação de dados utilizado em sistemas de automação industrial. Geralmente seu meio de comunicação é pela porta serial, mas hoje pode ser implementado também por meio de rede ethernet, onde seu paradigma é baseado em mestre-escravo (ALIEVI, 2008). A comunicação Modbus pode ser realizada de duas formas: Remote Terminal Unit (RTU) e American Standard Code for Information Interchange (ASCII). Os dois modos de requisição ou resposta possuem um formato de pacote específico, que é para requisição ou para resposta. Cada pacote é composto de seis campos que são representados por dados binários, no modo RTU, e por caracteres, no modo ASCII. Estes campos são definidos conforme a Tabela 1. Tabela 1. Campos representados por dados binários Início Endereço Função Indica o começo do pacote; Indica qual dispositivo receberá ou enviará o pacote. A faixa válida de endereços dos dispositivos varia de 0 a 247, sendo o endereço 0 (zero) utilizado para mensagens que são enviadas para todos os escravos; Objetivo do pacote; 11

12 Dados Controle Fim Campo onde os dados serão alocados. Ele tem o conteúdo de acordo com o campo Função do pacote; Responsável pela detecção de erros no pacote, conhecido como Cyclic Redundancy Check (CRC). Indica o fim do pacote; O protocolo Modbus possui algumas funções que dependem do dispositivo que implementa o protocolo. As funções possuem diferentes objetivos, como a verificação da comunicação, visualização da quantidade de eventos, leitura e escrita de registradores específicos ou um grupo, dentre outras, sendo as mais utilizadas as funções de escrita e de leitura. 3. Desenvolvimento do sistema O desenvolvimento do software supervisório que faz a aquisição dos dados para melhor leitura do ambiente, foi desenvolvido na linguagem JAVA, pertencente a empresa Oracle, a ferramenta para a programação foi a IDE Netbeans, verão 7.1, onde é um ambiente de desenvolvimento integrado de código fonte aberto e gratuito para desenvolvedores de software. A ferramenta não é específica para a linguagem de programação Java, mas sim suporta também C/C++, PHP, Groovy, Android (NETBEANS, 2012). O software projetado necessitou de uma porta serial no micro computador que foi instalado, para fazer a comunicação direta com o CLP. Os comandos dados pelo sistema supervisor foram solicitados pelo usuário, pois o sistema não possui nenhuma iniciativa própria para execução de tarefas, apenas realiza perguntas para o CLP sobre o ambiente em questão. O software desenvolvido tem suas funções bem acessíveis, para rápida visualização e execução, conforme ilustrado na Figura 1, do mesmo recebendo as informações enviadas do CLP. Figura 1. Sistema supervisório em conexão com o CLP 12

13 4. Validação e testes O sistema desenvolvido pôde ser testado visando analisar o comportamento do programa que está embarcado no micro controlador e do software supervisor. O software e o hardware foram testados em nível de unidade, de integração e de validação. Para a realização dos testes foram utilizados os métodos de caixa branca e caixa preta. No método de caixa branca se testa o funcionamento interno, usando nível de unidade e integração. No teste caixa preta foi validada a interface do sistema em nível de integração e validação tentando atender a acessibilidade ao usuário final do sistema em questão. Figura 2. Grafico comparativo de mensagens de solicitações e respostas do CLP Na Figura 2, fez-se o comparativo entre os sete testes utilizando as quantidades de mensagens de solicitação de informação e a resposta e o número de retornos que o equipamento fornece. Observou-se que começa a ter diferença entre os valores de solicitação e resposta, a partir do teste número três. Salienta-se que no teste de número sete, usando o cabo de 45 metros, obteve-se uma perda de informações (foi solicitado 678 vezes para o CLP a resposta das informações no ambiente, mas apenas foi retornado 480 vezes). Desta forma, pode-se constatar pelo gráfico gerado que o sistema desenvolvido permitiu atingir um bom resultado, sem muita perda de dados, com o teste de número seis, onde utilizou-se 20 metros de cabo para comunicação serial. 5. Conclusão Os sistemas de automação residencial necessitam ser seguros, confiáveis e principalmente possuírem um baixo custo de instalação. Assim sendo, cada projeto deve realizar a melhor combinação destas características, para que haja maior conforto e economia para o usuário. Em relação ao sistema de supervisão do CLP, instalado na estação de trabalho, totalmente desenvolvida com a plataforma Java Enterprise Edition, mostrou se bastante estável, produtiva, eficiente e confiável para amostragem das informações contidas no protocolo e executando funções implementadas. 13

14 Com o desenvolvimento deste trabalho foi possível perceber que aplicações residenciais de controle podem ser realizadas utilizando-se componentes de baixo custo e protocolos flexíveis, gratuitos, onde podem se comunicar com outros tipos de equipamentos se padronizados as comunicações. Isso aumentaria a popularização de casa inteligente. Mas para que esta popularização se dê de forma correta, é necessário investimento na criação de equipamentos simples e seguros e na padronização de estruturas de rede, todos falando a mesma linguagem. 6. Referências Alievi, C. A. Automação Residencial com Utilização de Controlador Lógico Programável. Monografia de Graduação em Ciência da Computação, Centro Universitário Feevale, Faustino, M. R. Norma IEC : Aspectos Históricos, Técnicos e um exemplo de aplicação, Dissertação de Mestrado em Engenharia de Energia e Automação Elétricas, Universidade de São Paulo, São Paulo, Franchi, C. M. Camargo, V. L. A. de. Controladores Lógicos Programáveis Sistemas Discretos. 1ª Ed., São Paulo: Editora Érica Ltda, Natale, F. Automação Industrial. São Paulo: Editora Érica, Netbeans. Datasheet, mar Disponível em: < Acesso em: 17 jul Pereira, F. Microcontrolador PIC 18 Detalhado: Hardware e Software. São Paulo: Editora Érica Ltda, Saha, D. Mukherjee, A. Pervasive Computing: a paradigm for the 21st Century, IEEE Computer, New York, v. 36, n.3, Mar Silveira, P. R. da, Santos, W. E. dos. Automação e Controle Discreto. São Paulo, Editora Érica,

15 Algoritmos Genéticos como Solução para o Problema da Mochila Múltipla 0-1 Thiego Yukiu Maeda, Rodrigo Luiz Antoniazzi 2 1 Ciência da Computação Universidade de Cruz Alta (UNICRUZ) Rodovia Municipal Jacob Della Méa, Km Cruz Alta RS Brazil 2 Departamento de Ciência da Computação Universidade de Cruz Alta (UNICRUZ) Cruz Alta, RS Brasil. tyukiu@hotmail.com, rodrigoantoniazzi@yahoo.com.br Abstract. The Knapsack Problem is characterized as an NP-hard problem and finding an optimal solution for a large input size is considered an intractable problem. However, an instance of this problem has not received due attention, called the 0-1 Multiple Knapsack Problem (MKP). The MKP is metaphorically characterized in a situation that must be put in different bags, objects of different weights and values, you must fill these backpacks with the highest value possible, respecting the maximum weight of each one. The aim of this paper is to suggest a viable solution in polynomial time and optimized for the 0-1 Multiple Knapsack Problem using Genetic Algorithms as a solution. Resumo. O Problema da Mochila se caracteriza como um problema NP- Difícil e encontrar uma solução ótima para um tamanho de entrada grande é considerado um problema intratável. Entretanto, uma instância desse problema não recebeu a devida atenção, o chamado Problema da Mochila Múltipla 0-1 (PMM). O PMM é metaforicamente caracterizado em uma situação que é preciso colocar em várias mochilas, objetos de pesos e valores diferentes, deve-se preencher essas mochilas com o maior valor possível, respeitando o peso máximo de cada uma. O objetivo desse trabalho é o de sugerir uma solução viável em tempo polinomial e otimizada para o Problema da Mochila Múltipla 0-1, usando Algoritmos Genéticos como solução. 1. Introdução Atualmente são inúmeros os problemas que podem ser considerados como computacionalmente intratáveis, como por exemplo, problemas de roteamento, de empacotamento, de alocação, entre outros [Goldbarg 2000]. De acordo com Toscani (2002) problemas intratáveis não podem ser resolvidos com algoritmos determinísticos em tempo polinomial. Isso significa que resolver um problema intratável pelo tradicional método de busca exaustiva (ou força bruta), onde todas as soluções possíveis são analisadas, acarreta em um tempo de computação que, para entradas suficientemente grandes, levaria séculos para gerar o resultado, como pode ser visto em [Garey 1979 and Papadimitriou 1994]. 15

16 Existem formas alternativas para se buscar uma solução viável a estes problemas em tempo polinomial. Uma possível solução é o uso de algoritmos aproximativos [Cormen 2002], que se constituem em algoritmos que encontram soluções próximas da solução ótima, já que muitas aplicações não requerem uma solução exata [Toscani 2002]. Outra alternativa para buscar soluções a problemas intratáveis é o uso de métodos heurísticos. De acordo com [Toscani 2002] existem vários exemplos de métodos heurísticos, entretanto os mais expressivos são: Algoritmos Genéticos, que são problemas interpretados de forma análoga ao código genético de seres vivos e então processos naturais de reprodução e melhoria de genes são utilizados; Simulated Annealing, que se baseia em processos termodinâmicos envolvidos no resfriamento de metais, onde a temperatura do metal fundido precisa ser controlada e gradualmente reduzida de acordo com um roteiro de resfriamento; Redes Neurais, que por sua vez utiliza a mesma abordagem utilizada por neurônios naturais para resolver problemas, ou seja, aprendizagem através de exemplos; e GRASP, baseado em outras abordagens, como por exemplo, método guloso agregado a características randômicas para solucionar seus problemas. Um problema de grande interesse é o denominado Problema da Mochila (knapsack problem) [Garey 1979]. O problema da Mochila se caracteriza pelo estreito relacionamento com um grande número de outros modelos de programação. Metaforicamente pode-se entendê-lo como o desafio de encher uma mochila sem ultrapassar um determinado limite de peso, otimizando o valor do produto carregado [Goldbarg 2000]. Existe uma série de problemas correlatos para o problema da mochila, que comprova as várias aplicações do modelo e permite uma visão de sua importância. Segundo [Goldbarg 2000], uma dessas variações é um caso especial quando os custos possuem o mesmo valor dos pesos, assim define-se o Subset-Sum Problem (SSP), formulado por Christofides (1979). A Mochila 0-1 Multidimensional (PK-n- Dimensional) é outra variação do problema, onde para cada objeto carregado na mochila seja exigido um pagamento e uma limitação no capital disponível. De acordo com Goldbarg (2000) outra variação do problema é a Mochila Múltipla 0-1 (PKM), definida por trabalhar não apenas com uma única mochila. Existem n mochilas a serem carregadas, cada uma dessas mochilas com uma capacidade de peso diferente. 2. Algoritmos Genéticos Os Algoritmos Genéticos foram desenvolvidos nos meados dos anos 60 por vários cientistas, entretanto John Holland foi quem iniciou os primeiros trabalhos nessa área [Golbarg 2000]. Holland (1975) estudou formalmente a evolução das espécies e propôs um modelo heurístico computacional que quando implementado poderia oferecer boas soluções para problemas extremamente difíceis. Holland apresenta os algoritmos genéticos como uma metáfora para os processos evolutivos, de forma que ele pudesse estudar a adaptação e a evolução no mundo real [Linden 2008]. Nos algoritmos genéticos populações de indivíduos são criadas e submetidas aos operadores genéticos: seleção, recombinação ou crossover e mutação. Estes operadores utilizam uma caracterização da qualidade de cada indivíduo como solução do problema 16

17 em questão. Entretanto é importante que fique claro que a evolução natural não é um processo dirigido à obtenção da solução ótima, e sim que o processo simplesmente consiste em fazer competir uma serie de indivíduos e pelo processo de sobrevivência do mais apto, os melhores indivíduos tendem a sobreviver [Linden 2008]. 3. Problema da Mochila Multipla 0-1 O Problema da Mochila pertencente a classe de problemas NP-Difíceis. Ele foi inicialmente reportado por Dantzig, em 1957 [Goldbarg 2000]. Teoricamente pode-se entender o problema como o desafio de preencher uma mochila com objetos de diferentes valores e pesos, sem ultrapassar o limite de peso da mochila e assim alcançando sua meta de otimizar o valor dos respectivos objetos. No caso do Problema da Mochila Múltipla 0-1 que consiste em n mochilas, cada uma com um peso específico b i, i=1,..., n. Onde, se n=1, a mochila múltipla se reduzirá ao problema da mochila. Os pesos e os valores de cada item são os mesmo para todas as mochilas, sendo necessário incluir uma restrição que evite a inclusão de um mesmo produto em mais de uma mochila [Goldbarg 2000]. 4. Metodologia O algoritmo desenvolvido foi dividido em dois módulos. Num desses módulos, consta a implementação do cromossomo, ou seja, dentro dele esta os métodos de operadores genéticos, isto é, o operador de crossover e o operador de mutação, esse módulo também contem a função de avaliação. O outro módulo vai conter o mecanismo de controle do algoritmo genético, ou seja, o método de inicialização da população, método de seleção e o módulo da população. Seu comportamento segue da seguinte maneira: o número de mochilas é estipulado no início da implementação, juntamente com a capacidade máxima de cada mochila. A quantia de itens também pré-determinado é de 30 itens, os seus respectivos seus pesos e valores também foram determinados no início do algoritmo. Após a inclusão dos dados, se dá inicio a geração da primeira população, a qual será de forma aleatória, ou seja, a escolha de qual item irá participar da mochila será randômica. Escolhido os itens que irão participar do cromossomo em questão, haverá a soma total de seu valor e peso. Esse passo se repetirá pelo número da população. A partir desse ponto todos os métodos envolvidos serão aplicados novamente até o número de gerações serem concluídos. Com a primeira população pronta o próximo passo é a função de avaliação de cada cromossomo, com essa nota serão escolhidos pelo método da roleta viciada os cromossomos que irão participar dos operadores genéticos (crossover e mutação). Os cromossomos que sofrerão a aplicação dos operadores genéticos serão avaliados novamente. Em seguida será aplicado o elitismo onde vai comparar com a primeira população e a população atual e determinar quem vai fazer parte da nova população, por fim, será verificado se a condição de parada foi satisfeito. A saída será sob a forma de um arquivo texto que serão as possíveis soluções do problema, ou seja, irá conter quais objetos irão preencher o espaço na determinada mochila. Com os dados de saída prontos, eles serão analisados e comparados, para poder validar sua eficiência. 17

18 5. Resultados Inicialmente foi necessário aplicar alguns testes para determinar a probabilidade de crossover, probabilidade de mutação e sua probabilidade de elitismo, na procura de parâmetros onde seu retorno fosse os melhores desempenhos para as populações. Nos testes iniciais de acordo com Linden (2008), foi utilizado uma taxa de crossover de 75%, para a mutação foi usada uma taxa de 1% o qual também foi utilizada para o elitismo. Nos testes subseqüentes foi possível notar que se aumentar a taxa de crossover para 90% obteremos uma alta nos resultados. É notável também que o aumento da taxa de mutação gera resultados menos satisfatórios, uma vez que a probabilidade de mutação escolhe os genes de forma aleatória, tornando as soluções randômicas levando a indivíduos menos aptos. Com isso a mutação assumiu uma taxa de 5%. Um fator importante também é sobre o modulo da população, ou seja, o elitismo, pois um leve aumento em sua taxa levou os cromossomos a convergirem para ótimos locais, onde com isso facilitava a criação de super cromossomos, logo seu surgimento era cada vez mais frequente, eliminando a diversidade da população. Para evitar esse problema permaneceu a taxa de 1% para o elitismo. Após concluir a escolha das probabilidades de crossover, mutação e elitismo, foi possível iniciar os testes, onde eles são diferenciados pelo número de cromossomos e pelo número de gerações. Primeiramente, foi indicado que os valores e pesos dos itens em questão seriam gerados randomicamente, porém, para ser leal e expressar da melhor forma os resultados, os valores (benefícios) e pesos de cada item foi pré-determinado, com isso os pesos totalizavam 617 e os valores totalizavam 619. Segundo Kellerer (2004), dessa forma se podem comparar os resultados obtidos pelas respectivas execuções mantendo um padrão nos benefício adquiridos. Na Tabela 1 foi realizado um teste onde se tem 5 mochilas com uma população de 100 indivíduos e a quantidade de gerações é alterada num intervalo de 100, 1000 e 10000, em seguida mostra o valor que cada mochila obteve e o tempo em que ela levou para gerar. Consequentemente, quanto maior o número de gerações maior será o tempo de execução, contudo, esse tempo é razoável se levar em conta a quantidade de itens e indivíduos. Tabela 1. Resultados gerados de cinco mochilas com 90% de crossover e com população de 100 cromossomos e 100 a gerações. Teste Gerações População Moc. A Moc. B Valor Adquirido Moc. C Moc. D Moc. E Tempo de Execução A s B s C s 18

19 Figura 1. Gráfico de execução de cinco mochilas com 90% de crossover e com população de 100 cromossomos e 100 a gerações Como demonstra o gráfico juntamente com a Tabela 1 se pode verificar que os resultados obtidos pelo teste C que possui gerações teve bons resultados e, com isso é possível notar que o aumento no numero de gerações altera de forma drástica os benefícios dos testes, superando aqueles onde o numero de gerações é menor, sem sofrer um aumento muito grande no tempo de sua execução. 6. Conclusão Constatou-se, a grande importância das técnicas de metaheurísticas, mais especificamente os algoritmos genéticos. Os algoritmos genéticos, conforme Linden (2008), são considerados uma técnica de busca global, visto que não usam apenas dados locais, com isso, não necessariamente ficam presos em máximos locais, tornando o algoritmo genético, uma técnica apropriada para funções multimodais e de perfis complexos. Resultando em ótimas técnicas, para confrontar problemas de busca com espaços de soluções intratavelmente grandes e que não podem ser resolvidos por técnicas tradicionais. Usando 90% para o operador de crossover, 5% para o operador de mutação e 1% para o elitismo, é possível analisar que ao manter uma taxa alta para o operador de crossover e taxas menores para os operadores de mutação e elitismo, obtêm-se bons resultados. Para a quantidade da população e da quantidade de gerações, houve uma 19

20 pequena diferença, onde alcançamos bons resultados quando é maximizada a quantidade de população, entretanto o tempo que leva para ser executado é alto. Porém, isso não ocorre quando se aumenta a quantidade de gerações, que em certos momentos é bem superior. Fica fácil de analisar que quanto maior for o número da população melhores serão os resultados, porém seu tempo sofre alterações a cada vez que é acrescentado mais cromossomos. A busca de uma melhor solução por algoritmos genéticos com uma análise sobre os resultados encontrados mostrou-se eficiente em encontrar boas alternativas de caminhos sobre o problema analisado. Logo, conclui-se que a Metaheurística Algoritmos Genéticos é viável para a solução do Problema da Mochila Múltipla 0-1. Referências Cormen, Thomas H. et al. (2002) Algoritmos: teoria e prática, Tradução da segunda edição Souza, V. D. Rio de Janeiro: Ed. Campus. Garey, M. R. and Johnson, D. S. (1979) Computers and Intractability; a Guide to the Theory of Np-Completeness, W. H. Freeman & Co. Goldbarg, Marco Cesar. (2000) Otimização Combinatória e Programação Linear: Modelos e Algoritmos, Rio de Janeiro: Campus. Kellerer, Hans; PFERSCHY, Ulrich; PISINGER, David. (2004) Knapsack Problems, Germany: Heidelberg. Linden, Ricardo. (2008) Algoritmos Genéticos: Uma importante ferramenta da inteligência computacional, Segunda edição. Rio de Janeiro: Brasport. Papadimitriou, Christos M. (1994) Computational complexity, Addison-Wesley Publishing Company Inc. Toscani, Laira V; Veloso, Paulo A. S. (2002) Complexidade de Algoritmos, Porto Alegre: Instituto de Informática da UFRGS: Editora Sagra Luzzatto. 20

21 Jogos Educativos: estimulação do raciocínio por meio de um dispositivo móvel Leander Cordeiro de Oliveira 1, Andreia Rosangela Kessler Muhlbeier 2, Patricia Mariotto Mozzaquatro 1, Rodrigo Luiz Antoniazzi 1 1 Universidade de Cruz Alta (UNICRUZ) Campus Universitário Dr. Ulysses Guimarães - Rodovia Municipal Jacob Della Méa, Km Parada Benito - CEP Cruz Alta/RS Brazil 2 Programa de Pós Graduação de Informática (PPGI) Universidade Federal de Santa Maria (UFSM) Av. Roraima, 1000 Santa Maria RS Brazil {leander_dewon, andreiamuhlbeier, rodrigoantoniazzi}@yahoo.com.br, patriciamozzaquatro@gmail.com Abstract. This article presents the development of an application that aims to stimulate logical reasoning. It was developed with the help of software Hot Potatoes, considering their access through the concepts of M-Learning. The playful perspective allied to mobility is efficient and makes it considerably easier to use. Resumo. Este artigo apresenta o desenvolvimento de um aplicativo que visa estimular o raciocínio lógico. Desenvolveu-se com o auxílio do software Hot Potatoes, considerando seu acesso por meio dos conceitos de M-Learning. A perspectiva lúdica aliada à mobilidade é eficiente e torna a utilização consideravelmente mais facilitada. 1. Introdução Os aplicativos educacionais aparecem no atual contexto como um recurso didático que contém características podendo trazer uma série de benefícios para as práticas de ensino e aprendizagem. Neste sentido, como tornar o computador um instrumento mediador no processo de ensino/aprendizagem? No presente artigo, foi demonstrado o desenvolvimento e a aplicação do jogo educativo enigma. Os tópicos explorados serão os seguintes: A seção 2 apresenta um estudo sobre Mobile Learning. A seção 3 é dedicada aos Jogos Educacionais. A seção 4 apresenta as ferramentas para construção dos jogos educacionais. O Jogo enigma é apresentado na seção 5. Os resultados e discussões são apresentados na seção 6. E por fim, a seção 8 conclui o artigo, seguida de suas referências. 2. Mobile Learning Vivenciam-se atualmente dificuldades relacionadas à mobilidade geográfica do usuário, o que se torna um empecilho de acesso no processo contínuo de ensino/aprendizagem, devido a necessidade do usuário em utilizar seu computador ou notebook de maneira estática. 21

22 Considerando tais fatos e a caracterização da computação móvel por meio do processamento computacional aliado a mobilidade, exposto por (Augustin et al., 2004), surge um novo paradigma, a Mobile Learning (M-Learning), unificando os conceitos de E-Learning e computação móvel, proporcionando ao usuário novas perspectivas em relação à liberdade de locomoção e deslocamento. O chamado Mobile Learning ou M-Learning, por trazer tamanha facilidade e benefícios ao usuário, está no foco de pesquisadores como parte de um modelo de aprendizado integrado, caracterizado pelo uso de dispositivos de comunicação sem fio, de forma transparente e com alto grau de mobilidade (Syvänen et al., 2003). Desse modo, foi desenvolvido o aplicativo enigma, integrado a computação móvel, com o intuito de facilitar o acesso a conteúdos que trabalham o raciocínio lógico de usuários em diferentes áreas de interesse. 3. Jogos Educacionais Os Jogos Educacionais ainda encontram algumas dificuldades na sua utilização, tanto em sua construção como software, quanto na inserção destes no dia a dia. Os mesmos têm vários pontos positivos, tais como: a facilidade de ensinar em vários níveis e áreas da educação, bem como definiu (Mitchell e Savill-Smith, 2004) quando disseram que os jogos colocam o aluno no papel de tomador de decisão e o expõe a níveis crescentes de desafios para possibilitar uma aprendizagem através da tentativa e erro. O usuário desenvolve com agilidade suas habilidades cognitivas, e segundo (Gros, 2003), promovem o desenvolvimento intelectual. A fim de vencer os desafios, o jogador precisa elaborar estratégias e entender como os diferentes elementos do jogo se relacionam. 4. Ferramentas para construir jogos educacionais Uma das características do computador é o fato dele não possuir apenas uma forma de uso, e sim inúmeras possibilidades, por meio de softwares ou materiais elaborados pelo próprio educador, auxiliando na problematização, que desafia e motiva à aprendizagem. Conforme Haetinger: Para o uso das novas tecnologias aplicadas à educação, deve-se considerar uma nova postura, tanto do professor como dos alunos. O aluno, através do uso dessas ferramentas, compromete-se muito mais com o seu aprendizado (o que não acontecia no ensino tradicional) (Haetinger, 2003). As ferramentas tecnológicas associadas ao desenvolvimento de jogos educativos promovem o trabalho colaborativo no contexto educacional. Como exemplo de ferramenta neste trabalho, destaca-se o software Hot Potatoes, um conjunto de cinco ferramentas de autoria, desenvolvidas pela equipe da University of Victoria CALL Laboratory Research and Development, que possibilitam a elaboração de cinco tipos básicos de exercícios interativos, utilizando páginas Web para aplicações voltadas ao uso educacional. A interatividade dos exercícios é obtida pelo uso de JavaScript. As ferramentas admitem caracteres acentuados, o que possibilita a criação de exercícios em qualquer 22

23 língua baseada no conjunto de caracteres do alfabeto romano, incluindo o francês, o alemão e outras línguas européias. O Hot Potatoes possibilita a elaboração de cinco tipos básicos de exercícios interativos usando páginas da Web: Quiz (Módulo que realiza testes de múltipla escola e resposta simples), Jmix (Sopa de palavras), JCross (Palavras cruzadas) JMatch (Exercícios de correspondências) e JClose (Exercícios de preenchimento de espaço). Existem três passos fundamentais para elaborar um exercício: A introdução dos dados (perguntas, respostas, etc.), A configuração do aspecto final (preparação dos nomes dos botões, as instruções e outras características de suas páginas Web) e a elaboração das páginas Web (organizar seus exercícios em páginas HTML). 5. Jogo Enigma O jogo educacional enigma integrou treze problemas de raciocínio lógico inspirados na série de jogos Professor Layton, jogo de enigmas da plataforma Nintendo DS. As atividades propostas envolveram interação do usuário por meio de questões textuais respondidas em tempo determinado. A aplicação pode ser acessada por diversos modelos de dispositivos móveis. Conforme observado na Figura 1, o usuário tem acesso à página inicial que apresenta o jogo com o botão Iniciar. Figura 1. Tela inicial da ferramenta Em cada uma das atividades o software apresenta botões de ajuda que disponibilizam dicas para a resolução das questões. Vale lembrar que quando uma dica for acessada a pontuação, que é gerada para cada enigma, é reduzida. Ainda existe o botão Soletrar que soletra a resposta, fazendo assim a pontuação diminuir conforme as letras são reveladas. Estuda-se agora a possibilidade de exclusão deste botão de soletração, considerando que o botão de ajuda é suficiente nas dicas para a resolução. Uma sucinta explicação da resolução somente é apresentada ao usuário mediante o acerto da questão, ainda, se o limite de tempo não for alcançado a questão não poderá ser respondida. Para o acesso ao próximo desafio o botão Próximo está disponível em todas as atividades e pode ser usado a qualquer momento. A Figura 2 apresenta a 23

24 atividade Descubra o Dia, a mesma objetiva trabalhar a matemática aplicada ao raciocínio lógico e a interpretação de textos. A Figura 3 apresenta uma equação matemática na qual o usuário deverá utilizar todos os algarismos de 1 a 9 sem repeti-los para completar a equação. Na imagem pode ser vista uma pequena janela de ajuda que dá dicas de resolução ao usuário. Figura 2. Atividade Descubra o dia Figura 3. Atividade Complete a equação 6. Resultados e Discussão O A aplicação desenvolvida foi validada por onze acadêmicos do curso de Graduação em Ciência da Computação por meio de seus próprios dispositivos. Alguns dos utilizados foram o Sony Ericsson Xperia x10 Mini Pró com Android 2.1, o Nokia C3-00 com Symbian S40 através do navegador Opera Mini, o iphone 3GS com sistema operacional ios4.2, dentre outros. Na sequência, foi aplicado um questionário com intuito de avaliar diversos pontos relacionados a aplicação, tais como: usabilidade, acessibilidade e conteúdo pedagógico. Os resultados quantitativos decorrem da compilação do formulário aplicado. Para a elaboração e disponibilização do questionário foi utilizada a ferramenta on-line Makesurvey1, que possibilita a criação de questionários on-line com questões em vários formatos e o acesso adaptado através para dispositivos móveis. Na Figura 4, observa-se que a maioria dos entrevistados (73%) consideraram o tempo de resposta e a velocidade de execução aceitável. Acredita-se que a discordância dos 38% deve-se ao fator de acesso através de dispositivos móveis. 1 Disponível em 24

25 Figura 4. O tempo de resposta Figura 5. Usabilidade Na Figura 5, questionou-se os usuários quanto as ferramentas do sistema se atendem ao objetivo proposto. Constatou-se positivamente (73%). As instruções apresentadas durante a execução das atividades, conforme ilustrado na Figura 6, constataram que (64%), concordam que o software disponibiliza as informações necessárias, tais como: ajuda, dicas, feedback da resposta, entre outros. Figura 6. As instruções apresentadas Figura 7. Interação com o sistema Relacionando o nível da dificuldade na interação com o software Figura 7, 37% respondeu que a dificuldade encontrada foi média, 36% (alta) e 27% (baixa). Acreditase que a dificuldade encontrada deve-se a dificuldade dos enigmas, o tempo disponibilizado para sua resolução e ainda ao fato dos usuários não estarem muito familiarizados a acessar esse tipo de ferramenta através de dispositivos portáteis. Com telas reduzidas e botões adaptados. Pela abordagem do desenvolvimento de uma aplicação para dispositivos móveis, foram questionados os recursos de texto, imagens e cores. Na Figura 8, constatou-se que estes foram considerados facilitadores na interação com o a ferramenta (82%). Salientase que, conforme os testes realizados pelos desenvolvedores e usuários, o aplicativo pode ser executado em diversos modelos de dispositivos móveis. 25

26 Figura 8. O tamanho da fonte, imagens e cores apresentadas facilitam a leitura? 7. Conclusão Jogos educacionais e ferramentas interativas bem projetadas podem ser criados e utilizados para unir práticas educativas com recursos multimídia, em ambientes lúdicos, a fim de estimular e enriquecer as atividades de ensino/aprendizagem em diversos momentos de descontração dos usuários. Além disso, ao longo de todo o processo de desenvolvimento desse trabalho, percebeu-se a existência de um espaço para desencadear outras pesquisas nessa área, tais como: a inclusão de objetos de aprendizagem e jogos educacionais. Ao concluir esta pesquisa, observa-se que o aplicativo abrange usuários de diferentes níveis de conhecimento (ao longo de todo o processo de desenvolvimento desse artigo, a existência de espaço para desencadear outras pesquisas nessa área tais como a inclusão de objetos de aprendizagem e jogos educacionais (fundamental, médio e superior). 8. Referências Augustin, I. et al. (2004). ISAM, joining context-awareness and mobility to building pervasive applications. Mobile Computing Handbook. Ed. Florida. Gros, Begoña. (2003). The impact of digital games in education. First Monday, v. 8, n. 7. Disponível em: < 7/xyzgros/index.html>. Acesso em: Jul Haetinger, Max Günther. (2003). Informática na Educação: Um Olhar Criativo, Coleção Criar. vol. 02 Instituto Criar Ltda. Mitchell, Alice; Savill-smith, Carol. (2004). The use of computer and video games for learning: A review of the literature. Londres: Learning and Skills Development Agency (LSDA). Disponível em: <htttp:// Acesso em: Jul Syvänen, A.; Ahonen, M.; Jäppinen, A.; Pehkonen, M.; Vainio, T. (2003). Accessibility And Mobile Learning. In: IFIP ETRAIN CONFERENCE IN PORI, Finlândia. 26

27 Uma Arquitetura Móvel e Ubíqua para Acesso ao Registro Eletrônico de Saúde do Paciente Leandro Ferreira Paz 1, Rafael Boufleur 1, Juliano Gomes Weber 1, Rogério S. de M. Martins 1, Vinicius Maran 1, Alencar Machado 2 1 Departamento de Ciências Exatas e Engenharias Universidade do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ) Caixa Postal Santa Rosa RS Brasil 2 Campus Tecnológico de Alegrete Universidade Federal do Pampa (UNIPAMPA) Av. Tiarajú, 810 Bairro Ibirapuitã Alegrete RS {leandro.paz,rafael.boufleur,jgw,rogerio.martins,vinicius.maran}@uniju i.edu.br, alencarmachado@unipampa.edu.br Abstract. The access to clinical information of patients in hospitals focuses on workstations, which complicates the work of healthcare professionals, as demand for information requires time and attention. With the advent of Information Technology, areas such as Ubiquitous Computing, demonstrates a fundamental transformation in innovation with incentives for health, with goals to achieve agility of processes, information availability by increasing the quality and productivity of services. This article proposes an architecture that enables mobile and ubiquitous access to Electronic Health Record (EHR) of the patient. Resumo. O acesso às informações clínicas de pacientes em hospitais concentra-se em estações de trabalho, o que dificulta o trabalho dos profissionais de saúde, pois a procura pela informação demanda tempo e atenção. Com o advento da Tecnologia da Informação, áreas como a Computação Ubíqua, demonstra uma transformação fundamental na inovação com incentivos para área da saúde, com objetivos de atingir agilidade dos processos, disponibilidade da informação e aumentando a qualidade e produtividade dos serviços. Este artigo propõe uma arquitetura móvel e ubíqua que possibilita o acesso ao Registro Eletrônico de Saúde (RES) do paciente. 1. Introdução As informações clínicas de pacientes registradas por profissionais de saúde são extremamente importantes e devem ser constituídas do histórico de saúde do enfermo. Elas servem também como documento legalizado dos atos médicos, bem como fonte de pesquisa, ensino e gerenciamento dos serviços à saúde [Filho; Xavier; Adriano, 2001]. Com o advento da tecnologia, os sistemas de informações hospitalares foram desenvolvidos para área administrativa médica, mas com o tempo a Tecnologia da Informação foi adequada também para guardar eletronicamente os registros clínicos do paciente. Desta forma, o acesso e a disponibilidade do Registro Eletrônico de Saúde (RES) do paciente é restrito à estações de trabalho, os desktops. Isto gera uma dificuldade em ter a informação no momento que o profissional necessita. Segundo 27

28 Filho, Xavier e Adriano (2001) informações administrativas podem ser coletadas retrospectivamente, mas as informações sobre o tratamento do paciente devem ser oportunas e disponíveis no ponto ou hora do cuidado. Diante do exposto, o uso da Computação Ubíqua vem para melhorar esta situação. Com a interoperabilidade dos sistemas, a disponibilidade da informação, facilita e diminui o tempo de acesso ao RES dos pacientes, sem que o usuário detenha toda sua atenção à usabilidade da aplicação, é a proposta de melhoria dos serviços da saúde. Uma das principais características da Computação Ubíqua é a sensibilidade ao contexto. A aplicação sensível ao contexto coleta elementos do cenário e a partir deste ponto diversas adaptações podem ser realizadas. Essas modificações auxiliam na realização das tarefas do usuário, pois não há necessidade dele preocupar-se em como utilizar o sistema totalmente, apenas com sua finalidade [Souza, 2010]. De acordo com Chen (2002), contexto computacional pode ser definido como: (i) físico; (ii) do usuário ou do tempo; (iii) emocional, que projeta dados que ajudem na realização de tarefas. O contexto do usuário é adaptar o perfil dele com a finalidade de suas ações, ou seja, moldar a aplicação de acordo com as suas preferências, tornando essas mudanças algo imperceptível para o usuário [Machado e Augustin, 2011]. De acordo com Dey [2001], contexto é qualquer informação que pode ser usado para caracterizar a situação de uma entidade. Uma entidade é uma pessoa, lugar ou objeto que considerado relevante para a interação entre um usuário e uma aplicação. Este artigo propõe uma arquitetura de um sistema móvel executado em um dispositivo rodando Android que, utilizando conceitos de Computação Ubíqua, tem o objetivo de diminuir o tempo que um médico leva para obter do prontuário do paciente os dados relevantes à sua especialidade a fim de agilizar o diagnóstico. Para ressaltar os dados relevantes à especialidade do médico em questão, utiliza a informação da sua especialidade para mudar o fundo da cor do texto, dando destaque a palavras que estejam associadas à especialidade cadastrada para o médico usuário do sistema. O restante do artigo está organizado como segue. A seção 2 apresenta a aplicabilidade da ferramenta proposta. A seção 3 descreve a arquitetura do sistema. A sensibilidade ao contexto é descrita na seção 4. Seção 5, resultados e discussões. Por fim, a seção 6 apresenta conclusões. 2. Aplicabilidade da Ferramenta Proposta O software proposto consiste na utilização por profissionais clínicos dentro de um ambiente hospitalar. O sistema é instalado num dispositivo móvel que é conectado numa rede sem fio disponibilizada pelo hospital. Num sistema ubíquo, a mobilidade é fundamental [Augustin; Yamin; Geyer, 2005], com esse intuito a arquitetura proposta nesse artigo, os usuários obterão às informações de saúde dos pacientes de modo rápido e acessível através da aplicação móvel. A sensibilidade ao contexto no sistema é tratada na especialidade do profissional. Ou seja, a aplicação ajuda no diagnóstico das doenças e prevenção destacando na interface do aplicativo palavras que sejam relacionadas com a especialidade do médico. Outro ponto importante da Computação Ubíqua é a interoperabilidade, a qual foi garantida com a adoção de um padrão de troca de 28

29 mensagens clínicas, o Health Level Seven (HL7) [HL7, 2011]. Desta forma, as informações médicas do aplicativo podem ser trocadas entre bases de dados heterogêneas ou outras aplicações que utilizam este tipo de padrão. Com relação ao uso de etiquetas bidimensionais, elas compõem um dos elementos chave de um sistema ubíquo, a identificação [Ley, 2007, p.64]. Além disso, o usuário deixa de trabalhar de forma estática e passa a agir dinamicamente com o espaço. 3. Arquitetura do Sistema A aplicação foi desenvolvida na linguagem de programação Java com Software Development Kit (SDK) para Android 2.2. O banco de dados no dispositivo foi criado no SQLite, nativo do sistema operacional. Para leitura do código de barras bidimensional, o QRCode, será utilizado o aplicativo Barcode Scanner. A arquitetura do sistema, conforme Figura 1, é composta pela aplicação móvel proposta rodando em um celular com sistema operacional Android. A base de dados que contém o RES do paciente se encontra instalada no SQLite de cada dispositivo. Todos os celulares estão conectados na rede sem fio do ambiente hospitalar onde podem trocar informações médicas entre si ou com outras bases de dados através do protocolo de troca de mensagens médicas, o HL7. As informações antes de serem exibidas nas interfaces da aplicação como: Exams, Medical Procedures, Diagnosis, Allergies e Chronic Diseases são contextualizadas de forma a destacar na tela palavras que sejam relevantes para o profissional clínico, de acordo com sua especialidade. AMBIENTEHOSPITALAR (WI-FI) (WI-FI) (WI-FI) (HL7) (HL7) (HL7) (ACCESS POINT) RES NO DISPOSITIVO TELA EXAMS TELA M. PROCEDURES (RES) CONTEXTUALIZAÇÃO DA INFORMAÇÃO (RES) TELA DIAGNOSIS TELA ALLERGIES Figura 1. Arquitetura do sistema. TELA CHRONIC DISEASES 29